ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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.


Topics - Josh @ Dreamland

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
121
Announcements / Metaphase
« on: April 01, 2010, 09:27:54 PM »
April Fool's has finally passed, with only moderate ripple effects, I might add.

A lot of insanely awesome stuff is going on right now, a lot of which I'll keep a surprise, but I'm happy to report that Ism can now successfully pass me resource data via the DLL. We are still missing a few things that R3 had support for, which I am trying to scramble up support for. Expect a testing phase commencing tomorrow. This should not overflow into the following day.

What that test will actually look like depends on a number of factors. Right now, I'm too excited to sleep. So the project has me for a while.

LGM has a bug, seemingly only on Windows, that we'll need to isolate and resolve. Isn't a very obtrusive bug and doesn't really fall on me, so.

Other things that need done with LGM include re-implementing the syntax check button now that ENIGMA's a DLL, and configuring it to inform me of changes in the C++ resource to avoid wasting an additional second during compile.

I think I may also implement the new instance system before I begin the test phase.

Also, keep this phase relatively quiet: I'm considering making it community-members only. Two reasons for this:
1) A huge part of the point of this is to alleviate stress caused by the release having a fatal flaw that has been overlooked.
2) I want the testing phase to be a small sample of people who can actually tell me what isn't working, or what's missing.

This testing phase will hopefully be both an opportunity to debug and to request small functions, maybe systems. While you test, I will be implementing sounds. Do not expect them from day 1.

In fact, since at this point I'm getting things that were done already in R3 working, expect the entire project to be a miserable piece of failure, and then be enamored by all the wonderful things it turns out that it can do.

Of course, if it doesn't do a particular wonderful thing, such as R3.0's inability to use non-numeral-prefixed constants (such as .5), and R2's lack of comments, DO REPORT THAT.

Again, though, keep it low for now. Release should be ready by the end of tomorrow. We'll see about getting something from Luda in that. I can't stress enough not to count on all the systems that will be in R4 to be that way immediately; many of them still need integration that is better done during the testing phase. Don't expect the bitmask system yet; Luda said he'd try to have the rectangle part of his design ready, though. Also, I'm looking at backgrounds and tiles right now, frowning. So, we'll see what this gets us.

122
Announcements / New Interests
« on: April 01, 2010, 12:48:16 PM »
As you can plainly see, the interests of this community have changed from software and game development to unicorns. As such, the ENIGMA project has been discontinued, effective immediately. For the third year in a row.

Okay, enough of that now. On to serious matters.

Upon further consideration, it has appeared to me that C++ just isn't right for ENIGMA; despite my best efforts, I don't think I can pull off all the things Game Maker does without a better system. Specifically, one with such goodies as dependent typing and a good garbage collector, so users can use ds_list_create and just forget they did so without worry, and so late at night when it's hard to keep track of what I'm doing, I'll be fine. I won't have to fear that I've made a mistake in my coding; something else will let me know or just take care of it for me. We all want that, right? Switching to a better language could definitely improve development speed, in that respect.

Besides, it's time to give the project's organization some serious rethinking. POD has become, though efficient, too confusing when looking at the bigger picture: we're better off calling things by reference. Doing so makes sense, and will help the garbage collector and any debugging implementations as well.

I was looking at C# or Java, maybe even with some Haskell. All of those languages are gaining popularity quite quickly; chances are they'll work on all the platforms we want ENIGMA to compile for within the next ten years. Those languages don't each offer all of the features I mentioned above, but they'll make mine and users' lives easier.

Think about it:  With their garbage collectors and referencing systems working for us, you can just create a ds_list, forget about it, and in a few steps, it'll just be gone! To ensure that users don't accidentally reuse a destroyed list, the integer-id (probably between 0 and 20) will cease to exist along with it, meaning you can no longer set any variables to it. So, if you said, for example:

a = ds_list_create();
ds_list_...

But then just stopped using "a"'s list for a while (like if you had it in an alarm that was taking a really long time to execute and so probably never would), list 1 would be freed. So what would happen if you were to pass "1" to ds_list_find again? That's the beauty: You can't! When list "1" is freed, so is the constant "1" from the game. That means that from now on, you can't use "1" anywhere in your code, and ENIGMA will make sure that you don't accidentally add anything to obtain "1". Also, make sure not to divide by it, as doing so may cause an error (don't worry though, each of these languages has great exception handling).

This can be accomplished by keeping everything stored as pointers, especially constants. Instead of "1" just being an integer in memory, it will be an integer pointing to an integer, and then another integer to verify that our integer points to an integer. Simple, yes? Efficient, too: modern processors are making it so no one will even notice the effects of doing so.

I haven't seen any Java games for Wii, yet, but maybe they could be played through the Wii's browser. On the other hand, I have seen one C# program for the Wii, and I'm sure it has reached shelves of hard-core gaming fanatics everywhere; just look at it. Although I don't think development with C# for non-Windows systems will be supported by Microsoft, they have agreed not to sue for it.

Because of that, C# is looking like a really good option. Plus, using C# would give us access to Microsoft's powerful .NET framework on Windows, which end users would simply have to download. It's only a few hundred megabytes. The Mono team has been working very hard to get that framework running on other operating systems, too; it should be mostly supported.

I can't wait to hear your comments on this. I feel we'll need a new logo to go along with it, possible something with gears and happy faces.

XOXOXOXO
<3<3<3
something about unicorns

123
Proposals / Instance System 3
« on: March 31, 2010, 12:38:30 AM »
R4's new instance system is going to require a slight amount of -further- rethinking.

Over R3's system, the new system is intended to implement a few things that probably should have been done from square one, honestly. The highlights of these are as follows.

For the first revision, a few half-contemplated changes were implemented:
  • Depth was accounted for by mapping/listing draw events by depth, then in a second, subset container by ID.
  • Events were added to their own lists, one for each event classification.
  • An option was added to determine the return type of instance_* functions.

The implications and philosophies of each are this:
Depth: This was a reasonably poor idea, though it seemed like the best thing to do at the time. The newer system was floating about in my head, but I rejected it for the time due to lack of apparent need.
Events: Storing events in their own linked lists allows for iteration and execution that will not slow down based on a number of empty particles. Tests on Game Maker seem to indicate that it does the same thing. Overall, one of Mark's better ideas, IMO.
Option: In theory, this will allow for constant-time member access with return values from the instance_* functions. Note that instance_nearest and the like will still require O(N) iteration (details outlined in newer proposals below).


Further thought, especially on how to handle GM inheritance, was given since, leading to further ideas:
  • Depth should be determined not by the order of instances in the main map, but rather by the order of pointers in the draw event queue.
  • Instances will instead (of being sorted by depth) be stored in separate arrays by object_index. This array will be static, so defrag-IDs will be your friend.

The former revision will free organization method for the latter.
This will vastly improve performance of, for example, instance_nearest(x,y,object0), since only one list will need iterated for object0. The entirety can still be iterated at little cost. What's more, heredity can be achieved using this method by having each object, on instantiation, add itself to all concerned lists.

For example, a call to instance_nearest(x,y,someparent) will iterate the list of objects having ID "someparent," which will contain a pointer to all children of "someparent" as well.

I can only imagine this is what Game Maker does. However, if you think you have an instance where this method (referencing all children in a list of the parent) would break some form of compatibility with GM, please verify it and inform me.


Potential problems with any of the above:

- A problem could result from treating too many scenarios as pointers instead of GM-IDs. The most obvious of thees is in room-given instance IDs. Many room create codes reference other objects in the room by integer-index ID. Failing to store the IDs and to offer a look-up by them could break that system. As such, it should certainly be kept as an option and defaulted to false.

- A problem could result from storing by object_index: redundancy in iterating all objects as a whole. For this reason, a separate container may be needed to store a continuous list.

124
Announcements / Update
« on: March 29, 2010, 10:48:55 PM »
Ism is presently dealing with "real-life" things. She'll be around; hopefully enough so to wrap this up quickly.

I've implemented the tier system, reducing the compile time to about four seconds on this computer, which apparently is about average in comparison to some of other ENIGMA members' computers, assuming those are what you'd call "good". Basically, it's what you'd get out of a GM game, except the compile's a one-time deal and accounts for 95% of the time at least.

So yeah, ENIGMA's up to speed. Much better than R3's 30 second compile jobs.

Eh...
ENIGMA is a DLL now. The ENIGMA plug-in fails to pass it the resources, though, due to some major JNA failure. Ism has successfully segfaulted Java on multiple occasions today.

I'm not sure what I will do tomorrow, other than go to school, which will be weird since it's Spring Break for high school but not college. I'll try to get something in this household running Linux again and make sure the engine works for it, too. Oh, by the way, I'm making sure that the new tiering system comes with even better organization than in the repo. It's going to be a fun time committing all these moves and deletes. -.-"

I prepared a small todo list of revisions for the engine. Really, I need Ism to get JNA working so I can test the damn compiler part already. >_<

If anyone has the patients of a saint and the Java skills of, er,... a patient gopher, I could use a hand. :P

Ciao for now; going to do any homework I may still be putting off.

125
Proposals / Tierable Systems
« on: March 28, 2010, 10:16:04 PM »
Some people don't want a huge-ass graphics system or collisions system. Different systems can require more variables to operate than others. Switching out systems means incorporating different variables.

Solution:

Code: [Select]
struct parent_basic {
  const unsigned id;
  const int object_index;
  parent_basic(): id(0), object_index(noone) {}
  parent_basic(unsigned x, int y): id(x), object_index(y) {};
};

In the local directory of each graphics system:
Code: [Select]
struct inherit_graphics_GL : parent_basic  {
  int sprite_index;
  int image_index;
  inherit_graphics_GL() {}
  inherit_graphics_GL(int x, int y) parent_basic(x,y) {}
};

Of the collision system, which we assume to require graphics system:
Code: [Select]
struct inherit_collisions_colligma : inherit_graphics_GL   {
  int mask_index;
  inherit_collisions_colligma() {}
  inherit_collisions_colligma(int x, int y) inherit_graphics_GL(x,y) {}
};



Then finally, in the IDE Editable headers in which code is stored:

struct parent_locals :
Code: [Select]
#if USE_GRAPHICS
  #if USE_COLLIGMA
    #define high_tier inherit_collisions_colligma
  #else
    #define high_tier inherit_graphics_GL
  #endif
#else
  #define high_tier parent_basic
#endif

struct parent_locals: high_tier
{
  var health;
  var lives;
  var otherworthlessthings;
  //...
  parent_locals() {}
  parent_locals(unsigned my_id, int my_object_index): high_tier(my_id,my_object_index) {}
};


This is being implemented for testing *now.*

Note: I left out X and Y for brevity. They will be assumed to be needed before collisions but after graphics.

126
Proposals / Collaboration by Timestamps
« on: March 26, 2010, 09:50:48 PM »
Serp remarks that GM is unsuitable for collaboration due to resources all being in one file.

I think a nice fix for this would be to store a time of creation (milliseconds-since-Jan-1970 style) as well as a time of last modification and time of last splice in with every resource.

LGM could then offer a splice function that would check each of the three things, like so:
If the resource exists in A (true, we're iterating)
{
  If it doesn't in B (!B)
  {
    Keep A
  }
  else, it does exist in B (B)
  {
    If the time stamps of creation are the same (A.created == B.created)
    {
      If the time stamp of modification of A matches the time stamp of last splice of A (A.modified == A.spliced)
      {
        If the time stamp of modification of B does NOT match the timestamp of splice of B (B.modified != B.spliced)
          Assume B is newer, and copy B to A
        Else
          Continue to the next resource; they should be the same.
      }
      else
      {
        If the time stamp of modification of B matches the timestamp of splice of B (B.modified == B.spliced)
          Assume A is newer; keep it
        Else (B.modified != B.spliced and A.modified != A.spliced)
          I have no idea what to do here. Ask the user, show a Diff somehow. This is what requires work.
      }
    }
    else, they are different resources entirely (A.created != B.created)
    {
      If the names are the same, both users may have been thinking the same thing (A.name == B.name)
        If on prompt for action the user says to skip it
          Continue to next resource
      Increment the id of B to the next available resource ID.
    }
  }
}

127
Proposals / execute_string via Google V8
« on: March 26, 2010, 09:25:32 PM »
GML's consistency with C++ is nothing compared to that with JavaScript. I could add a newline after everything and not have to worry about adding semicolons. Hell, I could put everything in parentheses, too; I wouldn't even need a lexer. V8 is amazingly fast, and it compiles the JS Just-in-Time.

I believe I mentioned earlier that JavaScript even has a with().

I'm vaguely familiar with the workings of V8, and it would not be difficult to use some basic accessors to simulate odd effects of GML, such as speed/direction - hspeed/vspeed correlations.

Functions are also amazingly simple to add to either language across V8.

128
Proposals / Debug mode: Tracking array bounds on scalars
« on: March 26, 2010, 09:20:20 PM »
Var makes it so users don't have to worry about their array bounds. Scalars allocated in bulk do not.

The idea of present is abstract and unresearched. Basically, we create a structure to proxy for each scalar*, such as int* or double*. A second proxy (or perhaps just the class of the first) will be used with calls to new[], having that operator overloaded.

So, in int_allocator::operator new[] (size_t sz), we do something like this:
value = new int[sz+1];
*value++ = sz;

Treating the struct as an int* will work just like a regular int*, but more operators could be overloaded to ensure correct performance.
#define is also an option; this is just a debug mode.

Upon access via the other class, int_proxy, the allocator class will be decremented and dereferenced for a bounds check.

129
Proposals / Rules
« on: March 26, 2010, 09:11:27 PM »
The rest of the forum's rules apply here, too. Go figure.

Anyway, the rules here vary according to the mood of the moderators. Your topic may be praised one day and locked the next on the grounds that it is "stupid."

This forum was made mostly as a notepad that I don't have to leave open all the bloody time. Bonus: Other people can read, comment, build onto, and suggest, not only on my ideas, but on each others'.

That said, no "stupid" ideas. But do feel free to make suggestions.

Your suggestions are subject to being flamed to hell before ever being considered. Being flamed to hell does not mean that your suggestion has not nor will not be considered.

I still encourage such suggestions, however. Especially the useful ones.
This IS a place for debate.

Something about tacos.

130
Announcements / Collisions
« on: March 26, 2010, 05:05:17 PM »
Luda is back!

He offered to take up collisions again today, which is good news for the project. Luda wrote the original system used in R3, which I implemented rather poorly (no collision event), but it has since been over a year and it is safe to say we're both "on top of shit."

He apparently has hatched a plan for improving collisions to operate in O(n*log n) rather than O(n**2) like most systems. I'm not sure what time GM operates in, but frankly, who gives a crap; Luda's were faster than Mark's last time. (At least, as far as I can tell. I thought Mark was supposed to be an expert on collisions?)

Anyway, I'm personally tickled pink. Luda learned not long after making the original system that he could improve it by using integers instead of bytes (somehow that wasn't common knowledge at the time, now it's so obvious...), and with his new Quad Tree idea, we should be cooking with gas.

Also, I'd like to remind everyone that DLLs are also part of the equation now. These systems are the two things that everyone concurred are all that's left to set ENIGMA and GM apart. Let's hope we don't blow this, eh?

131
Announcements / Summary
« on: March 25, 2010, 10:11:28 PM »
Perfect summary of the project today as I tested serp's optimization fix (which was quite full of linker errors):

Game Maker

Can't do anything fast.

ENIGMA

Can't do anything right.


So.

...Fix'd


Today's lessons: Always remember to use unsigned chars when the situation calls for them, and don't be afraid to use an equation that makes sense when calculating framerate. Even when Linux won't let you use clock().
...I'll probably end up externalizing a function that uses clock() on Windows and gettimeofday() on Linux.


Technical blah:
They're actually geometric curves and trig: GM's nightmare, really. I used 20 lines each curve.

Draw
Code: [Select]
draw_set_color(merge_color(c_red,c_yellow,.3));
draw_set_blend_mode(bm_add);

for (i=0; i<cc; i+=1) {
 draw_set_alpha(min(.1,alpha[i]));
 for (ii=0; ii<ic; ii+=1) {
    draw_line(xo[i]+lengthdir_x(ii,ang[i]),yo[i]+lengthdir_y(ii,ang[i]),xo[i]+lengthdir_x(ic-ii,ang[i]+90),yo[i]+lengthdir_y(ic-ii,ang[i]+90));
  }
  yo[i] -= vs[i];
  ang[i] += rot[i];
  alpha[i] -= .001;
  if (alpha[i] < 0)
  cci = i;
}
room_caption = "Number of particles: " + string(cc) + "  FPS: " + string(fps) + "  ... Sad, really.";

Step
Code: [Select]
repeat (2)
{
  xo[cci] = mouse_x - 16 + random(32);
  yo[cci] = mouse_y - 16 + random(32);
  ang[cci] = random(90);
  alpha[cci] = .12;
  rot[cci] = random(10) - 5;
  vs[cci] = .5 + random(2);
  cci += 1;
  if (cci > cc)
    cc = cci;
}

Create
Code: [Select]
cc = 20;
cci = cc;
ic = 20;

for (i=0; i<cc; i+=1)
{
  xo[i] = mouse_x - 16 + random(32);
  yo[i] = mouse_y - 16 + random(32);
  ang[i] = random(90);
  alpha[i] = .12;
  rot[i] = random(10) - 5;
  vs[i] = .5 + random(1);
}


LGM can't actually pass that to ENIGMA yet, so I copy-pasted the code manually. Crude but effective.
The difference between ENIGMA's and GM's was (in addition to the caption) the repeat() value, which was 8 in ENIGMA.

I allocated like, 60 values more than I seemed to ever need, but you never know.

Anyway, thanks much to serp, who is the reason the game is like 288 KB. As opposed to like 420, which it has been before. He's probably also the reason it runs smoothly, and is certainly the problem I ran into five linker errors copy-pasting code. <3

132
Announcements / Another quickie
« on: March 23, 2010, 07:27:24 AM »
Boy metaphase is taking a long time (For those who are expecting it, hehe).

Anyway, another tidbit worth noting: "Local" typing, as in, "local struct a;" will be possible only if users ensure that said typing is done in the first event parsed. The create event is a safe bet.

Types are remarkable in that they cannot be assumed; that's why I needed a C parser in the first place.

So, I can do "local struct," which wasn't part of the original plan, but it's not going to be as convenient as "local int" or the like, simply because I can't treat something as a type before I know for sure that it is.



I've started documenting the systems that those implementing new libraries will need an understanding of. Aragon has been working on Wii things and has agreed to get started on some draw functions for ENIGMA. What's interesting is that he wanted to get started right away, so he checked out the SVN and started looking through it without docs. ;_;

What's even more interesting is that he commented on how well-organized it was, which is indeed what I was going for, but I didn't think anyone would just figure the whole thing out without bitching about documentation. Makes me wonder why I'm writing it sometimes.

Also, retep998 has volunteered to help with the collisions. I hope the undertaking will go a little more smoothly with more people on them than just me. He'll be starting that when R4 enters a stable test phase.



Ism and I talked for a bit, and now she is working on a set of classes in C and in Java that will allow the two to share resources. Getting a C DLL to call Java functions isn't going to happen, but I can probably communicate some simple instructions by returning an array of them.

Also, we used to use std-out to communicate from ENIGMA to LGM, such as info about what was taking place in the compiler. Well, now we can't, so hopefully we can create a reliable new mechanism for this. (It's a shame, too; she spent a fair deal of time threading that damn output window, and now it's useless...)

On the bright side, though we were originally afraid we'd have to add something to the path folder, we've found workarounds for that, too.



My current difficulty is figuring out a way to simplify installing a compiler for users. Problem is, Vista is incompatible with a release of MinGW for XP and the like, and I hate to think about Win7. The MinGW team has their own automated installer that downloads the correct version; maybe we can use that. The only problem that creates is locating the compiler after it installs it.... It doesn't add anything to the path variable, and the typical GM user doesn't even know what that means. ;_;

Suggestions/comments welcome. Criticism will be bashed thoroughly and considered later.

133
Off-Topic / Essay
« on: March 17, 2010, 06:11:31 PM »
I'll be essaying for the next day and a half or so.

Didn't think it was worth a news post.

Ism got DLL's working in Java. She's now looking in to how resources can be passed via function calls. Shouldn't be hard to get ENIGMA DLL-ized from there.

134
Announcements / Another choice.
« on: March 12, 2010, 09:45:55 AM »
In R3, you were allowed to say "int a;" in a code piece to declare "a" as C++'s fastest type. To declare it as a local variable to the object, however, I made you say "localv int a;". Well, that system was brutally easy to implement. However, it's not so convenient to type.

When I started the project, I was enamored by how similar C++ and GML were. I saw "var" as a data type; GM's only data type.  It was only logical that var should be a class.

However, long, long ago, NoodleNog suggested that to declare script-local variables, of type "int" for example, you should use "var int" rather than just "int." This makes it a bit of a hassle to declare script-locals, but then actual object-local variables are simply declared as "int."

He was presenting this to me as I suggested ambiguating the word "local" to use. Locals would be declared one-time, preferably in create events but technically in any event, as "local int a;".

My first choice was actually to have Ism add an event for such declarations; in this event, you would have only your locals declared. It seems rather unprofessional in retrospect, but would technically be as easy as adding semicolons and copying over the code to the front of the structure. :P It would make my life easier, but it would leave a bad feeling in my stomach and would cause Ism a good amount of work, possibly delaying the project further.

I was going to just go with the first option (which I will cast a vote on this time), but I figured I'd give you all a chance to toss it around and/or shoot flames at it first.

To clarify, no outcome of this poll will affect backwards-compatibility with Game Maker. This is purely an extension of the language. Undeclared variables will be treated as local vars. "localv var" and "local var" are meaningless.

Anyway, same drill as last time.
Peace.

135
Announcements / I hate the last ten days before a release.
« on: March 11, 2010, 08:52:16 AM »
Consistently, the last ten days before a release grow to twenty and then maybe thirty due to lack of coordination. It's a wonder I managed to hit within 15 hours of R3's deadline, honestly.

Standings:
As has been reported, the C parser is done. There's been no reason to modify it so far, and I'm hoping never to run into such a reason.
A great deal of the other two parsers is done; more than 75% of each.
I'm to the point where I would like to start testing everything working together before progressing on either parser, however, we have a problem with that.

LateralGM has three members.
Ism's on spring break, spending time with people somewhere. I don't want to ruin it for her; she could probably use the vacation after the earthquake following the release of GM8 (which honestly, I wasn't expecting at all; don't know if she was or not).
Quadduc is apparently working on other (somewhat cooler, admittedly) projects.
Clam is pretending to go to college (Really, he's running a social experiment to see what the worst thing he can wake up to is after passing out drunk).

The good news is, Ism intends to help during boring times of spring break, and to actually come back afterward.  :v:

As for me, my college courses are on spring break as well. High school ones aren't, so I have to show up to them for two hours a day anyway. What's annoying, though, is being unable to hook ENIGMA up to LGM without Ism; there's just been too much change... And it's so close to just being done...

Presently, Ism is trying to get a simple DLL working from Java. I'm hoping JNA will allow ENIGMA to ask LGM for resource information instead of relying on it to be sent... We'll see how it turns out. The last phase could be messy.

I guess I'll continue to work half-blindly on my parser... I do wish for the batch passing of scripts to it, but whatever. There's also a timing issue with serp. He's done some impressive work on ENIGMA's library while I was working on those parsers. They're on GIT, which I hate working with. I don't know when to check out, is the problem. Having a revision system is supposed to fix that, I thought. ;_; 'S what we get for having two of them.

I'm running a couple checks for old mistakes that I corrected long ago but never released a patch for. Heh, what a ride. It's nice to be this close again.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »