Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Josh @ Dreamland

Announcements / Yet Another Renaissance
« on: September 13, 2012, 09:34:27 AM »
I'm posting an announcement because people are really bad at finding buried topics on SMF. With JDI done and (mostly) working (I need to work out a problem on 32-bit machines), I am posting several proposals in the appropriate forum section.

One of them I posted early for the lulz. One of them's an old topic that still hasn't been dealt with; now might be a good time.

Dealing with nested statements: Named loops or numbered breaks?
Loading and unloading resources by name
Sprite sheets
Overworld resource
Definitions Resource
Preprocessors: {{}}
Arrays: [[1,2],[3,4]]
Static Sprites
Reintroduction of build mode

I don't have the time to post all these proposals at once. Check this topic frequently for more. (Or actually visit the Suggestions and Proposals board and see the list for yourself.)

Proposals / Resource group load/save functions
« on: September 13, 2012, 09:30:51 AM »
The idea is simple in concept. GM/ENIGMA users often group objects which are related spatially or temporally in the resource tree. GM games are notorious for their huge RAM consumption, and ENIGMA games can only be so much better while operating in an arbitrary CPU/RAM use constraint. So, how do we propose a solution?

Simple. Allow selecting whether resource tree groups are preloaded or not, and give a method called resource_group_load("The name of the tree item").

Basically, the resource group "Player" and "Enemies" — and don't lie, you've used groups by this name! — will be loaded up front, as will the resource group "Terrain" in simple games, or "Overworld 1" in more complicated games. When you need resources from the second overworld, you call resource_group_unload("Overworld 1"); resource_group_load("Overworld 2");.

Now, if you're afraid that will mean in-game load time, well, your fears are justified for extremely large games. But think of it this way—all that loading would be done at the same pace up front otherwise. You've just broken it into manageable segments at worst; no one is forcing you to call the unload() function.

To solidify the proposal, I am suggesting the following methods:
Code: (EDL) [Select]
/** Load groups of resources with the given name in the resource tree into memory.
    The group id can be from any resource folder; all matching groups will be loaded.
    To narrow the ID, the forward slash "/" can be used to denote nested groups.
    Hence, the string "Overworld 1" will load all resources found in any group called
    Overworld 1, while the string "Enemies/Overworld 1" will load only such a group
    contained in a group called Enemies.
    If a resource in the group is already loaded, no action is taken for it.
    The function returns only when all resources in the group are loaded.
    At that time, the function returns the number of matching groups loaded. */

void resource_group_load(string group_id);

/** Unload groups of resources with the given name in the resource tree from memory.
    The resource matching dynamic is identical to that of resource_group_load.
    Returns the number of groups unloaded. */

void resource_group_unload(string group_id);

/** Load groups of resources with the given name in the resource tree into memory.
    Very similar to resource_group_load, except it performs all loading operations in a
    new thread, returning immediately. */

void resource_group_load_thread(string group_id);

Perhaps later we will want to offer functions which narrow the search to individual resource tree items.

Along with tree storage, I would like to offer a function to fetch the ID of a resource by its name, and vice-versa, then allow loading or unloading an individual resource manually by ID. Those will follow later, and are not really the concern of this proposal.

What I need from Java: A way to mark groups as preloaded.

Proposals / Re: Named loops vs numbered breaks
« on: September 12, 2012, 05:20:44 PM »
It is the same as break, so why use it?

Proposals / Re: Named loops vs numbered breaks
« on: September 11, 2012, 02:13:23 PM »
That is what continue loop; would do. Same as continue 2;.

Proposals / Re: Named loops vs numbered breaks
« on: September 11, 2012, 07:51:59 AM »
That's pretty ugly, and it doesn't match other languages, so newcomers couldn't really guess it.  If we're going to have them learn something new, it should be that the number after break is the total number of loops to exit, not the additional number.

People are really used to named loops, too. We'll let the userbase decide.

Proposals / Re: Named loops vs numbered breaks
« on: September 10, 2012, 11:35:23 PM »
While "both" was originally a joke, I actually think I might do it. My main aversion to it was that it would make goto labels ambiguous, but in the end, (1) do we really want goto, and (2) why can't a loop name also be a label?

It would be simple to just warn on break 1;. Did I mention I'm adding warnings?

Issues Help Desk / Re: Seg Fault once LGM opens ENIGMA
« on: September 10, 2012, 06:42:12 PM »
Did some basic testing. No segfault when reading that engine file on 64 bit, but I notice an increased number of error messages printed—about three times as many as on the 64-bit equivalents of Windows and Linux.

That said, the issue could very well be with the preprocessor. It might be best if you could check out JDI and run the test manually, so we know for sure that the problem is with JDI. If you stop in on the IRC, I'll be happy to walk you through it. Otherwise, hold tight until I can get a 32bit VM at my disposal (I don't have the resources where I am now).

Issues Help Desk / Re: Seg Fault once LGM opens ENIGMA
« on: September 09, 2012, 08:26:04 PM »
Assuming your binaries are all up-to-date, I'm not sure why this would happen. Ubuntu 12.04 is pretty uniform, even five months later. It seems odd to me that it has worked for everyone out of the box on 12.04, but isn't working on yours. To be on the safe side, could you run gcc -E -DJUST_DEFINE_IT_RUN -I. SHELLmain.cpp -o enigma_engine_segv.cpp from ENIGMAsystem/SHELL and upload the generated enigma_engine_segv.cpp somewhere? The segfault seems related to the new parser, but no one else has reported it.

Are you on 32 bit, perhaps? To my knowledge, all of our testers thus far have been on 64. It would help me diagnose the problem better if I knew that.

Proposals / Named loops vs numbered breaks
« on: September 08, 2012, 04:47:37 PM »
Code: (EDL) [Select]
for (int i = 0; i < 10; ++i) {
  for (int j = 0; j < 10; ++j) {
    if (target[i][j])
      break; // FUCK!

Named Loops:
Code: (EDL) [Select]
  for (int j = 0; j < 10; ++j) {
    if (target[i][j])

Numbered breaks:
Code: (EDL) [Select]
for (int i = 0; i < 10; ++i) {
  for (int j = 0; j < 10; ++j) {
    if (target[i][j])
      break 2; // (Y)

Announcements / Re: What needs said
« on: September 03, 2012, 01:55:28 PM »
JavaScript was the very language I had in mind. We already have a JS engine started, and it of course supports execute_string. ;)

Announcements / Re: What needs said
« on: September 02, 2012, 09:07:33 AM »
I'm bumping this, because I'm starting to think that people don't view the front page and therefore cannot see this post.
I'll post a new newspost later regarding progress on the operation. Edit: Actually, maybe I'll just post it here.

I have basically completed getting JDI working on the major platforms (Linux, Windows, Mac OS). The parser completes with less than 300 errors on Linux; I can't give a good estimate on Mac/Windows because I am not the one who tests it on those platforms. While 300 errors may seem like a lot, it really isn't a big deal, because JDI easily recovers from them and continues reading definitions. That's a good behavior to have in a parser whose only objective is to inform on the basics.

Right now I am further reducing that error count and finishing up the parts of JDI upon which ENIGMA's new EDL parser will depend. ENIGMA will, in principle, be able to invoke JDI methods to handle a good amount of EDL parsing. This means that I only have one parser to maintain rather than two; if one is right, both are right. It also means that ENIGMA's lexicography will match that of G++, so we shouldn't have any inconsistencies except due to utter negligence.

I'm going to knock off a few more errors and then begin the new parser methods to build ASTs of entire codes. Since the system will operate with JDI as a basis, you will be able to render your code as an SVG to diagnose any misinterpretations (and, of course, to show it off to your friends ;)).

Anyway, I'll report back on how that goes when I'm actually starting the EDL parser. Ciao.

Update: On Linux, I have it down to 215 lines of errors; of those, there are 86 separate errors (problems in the parse process), caused by 21 unique issues with the parser. That last figure, 21, is the number you need to be concerned with. For now, I'm going to leave it, unless correcting the bug that seems to involve the preprocessor is necessary. The preprocessed Windows engine only throws 187 total lines of errors, which means to me that either Windows is much more parser-friendly, or there is a bug with JDI's preprocessor.

Announcements / Re: k done
« on: September 01, 2012, 04:17:09 PM »
... I think she's dead.

Announcements / What needs said
« on: August 08, 2012, 01:21:01 PM »
Okay, I think it's about time to answer the obvious question: Why are you so interested in a new parser?

The C parser needed fixed to get the project working again on Linux, due to changed headers. I decided that it would be a good time to do some re-thinking of the parser system in general.

A lot has changed since the project began, and not just with my views on what ENIGMA should be. I wanted ENIGMA to be free, fast, capable, and cross-platform from the start. In the time since then, Yoyo has set similar goals. They have proven to—as far as commercial organizations go—not be very capable of attaining those goals. However, one of the achievements they have made is getting Game Maker to work on every platform ENIGMA does. In fact, they've gone a step further and made it easy to get GM working on those platforms; presently, ENIGMA takes some finagling. In addition to working on those platforms, GM can export to JavaScript. This changes the rules of the game in itself.

With that turn of events, it is time to take Rusky's advice from two years ago. Well, not all of it. Some of it still makes me want to puke (and he no longer defends it, either). Unfortunately, I went ahead and threw the baby out with the bathwater on that one.

While originally, the plan for ENIGMA was to leave the bulk of interpretation to the host language (ie, C++), doing so has closed the doors to a number of language features.

I have designed JDI in such a way that ENIGMA will be able to reuse the vast majority of its code (in addition to using all of it to being the C++ backend).

What that means is the availability of this feature set:
  •   A unified language and corresponding AST whose backend language does not matter.
    • Ability to export to any language from the backend.
    • Ability to accept definitions from any language capable of reflection (and C++) as the frontend.
  •   Ability to declare getters and setters on certain variables
    • The possibility of adding quad trees to collision systems by placing setters on x and y.
    • The ability to assign a getter for variables such as bbox_left, object_count, etc.
  •   Ability to replace operators with methods
    • No more div/mod class. Simple to cast division operands to double.
    • Simple to implement boolean xor, ^^.
  •   Ability to determine the type of any expression used in code.
    • Full control of instance or class access through the dot operator.
    • Ability to decide whether or not to cast operands to division (eg, determine whether the class has a division operator overloaded).
    • Ability to regulate the ternary operator to ensure against ambiguity (eg, var a = string_mode? "" : 0;).
  • Ability to resolve overloads of functions
    • Ability to use a more efficient overload for varargs functions.
    • Ability to pass additional arguments to certain functions.
      • Ability to pass information about the current instance and other instance to functions implicitly.
        • Replacement system for the central iterator system, which is founded on globals.
        • Ability to call instance modifying functions from threads.
Maybe you can see how I'm excited about the prospect. If not, questions here.

Announcements / Re: k done
« on: July 28, 2012, 01:34:58 AM »
I have JDI compiling and working (zero errors, zero warnings) on Windows with the following headers:

Code: (C++) [Select]
#include <GL/gl.h>
#include <GL/glu.h>

#include <stdio.h> //printf, NULL
#include <stdlib.h> //malloc
#include <time.h> //clock

#include <stdio.h>
#include <stdlib.h>

#include <errno.h>
#include <float.h>
#include <iso646.h>
#include <math.h>
#include <locale.h>
#include <stdarg.h>
#include <wchar.h>
#include <stdint.h>
#include <string.h>
#include <stdbool.h>
#include <stddef.h>
#include <malloc.h>

#include <stdint.h>
#include <time.h>

#include <fcntl.h>
#include <sys/types.h>
#include <signal.h>
#include <setjmp.h>
#include <inttypes.h>

// Once affected by lack of '?' operator token
#include <ctype.h>
#include <wctype.h>
#include <limits.h>
#include <assert.h>

#include <windows.h>

// Once affected by lack of support for public/private/protected, and by lack of support for constructors.
#include <pthread.h>

#include <sys/stat.h>
#include <sys/time.h>

#include <fenv.h>
#include <tgmath.h>
#include <complex.h>

I'll probably commit what I have shortly, assuming nothing segfaults and dies in ENIGMA (Which I'm already sure that it will).

General ENIGMA / Re: Recodes
« on: July 26, 2012, 08:44:39 PM »
What Ism said.