ENIGMA examples - Games

Post made November 10, 2010, 08:38:19 am was deleted at the author's request.

[TheExDeus]

I did a little test with grids to compare speeds. With 8x8 grid the game in GM runs with 1-2fps, but the same example in Enigma runs with 16fps. Now when I just change "var" with "int" everywhere, then its goes up to 22fps. The biggest bottleneck is to draw a transformed sprite (which is the line connecting points). Don't know if those could get faster, but it would be better to use primitives or something of the like to draw the grid anyway. I added the examples as attachments. There is one thing I noticed thou. Something didn't work right with scripts. I made a script scr_grid_add_wave to move the grid nodes. In GM it works fine, but in Enigma this part "if (nx*nx+ny*ny<radius*radius){" is always "if (0<0){" for some reason, and so it doesn't work. When I copied the script code to the step even and just changed arguments with their values then it works fine. Something to look into..

[Josh @ Dreamland]

I can't think of any reason "if (nx*nx+ny*ny<radius*radius){" would behave that way. If you like, you can look at IDE_EDIT_objectfunctionality.h and find how the faulty code is exported. If you see something wrong with it, tell me and I'll probably be able to diagnose the problem.

[TheExDeus]

I can't think of any reason "if (nx*nx+ny*ny<radius*radius){" would behave that way. If you like, you can look at IDE_EDIT_objectfunctionality.h and find how the faulty code is exported. If you see something wrong with it, tell me and I'll probably be able to diagnose the problem.

I checked and it parses at that point correctly. The problem was with with() statement and arguments. The beginning of the code looked like this:

Code: [Select]

with (obj_controller){
int i,c, radius, xx, yy, nx, ny, dir,col, nid;
xx=argument0;
yy=argument1;
radius=argument2;And it parsed like this:

Code: [Select]

  with(obj_controller)
  {
    int i, c, radius, xx, yy, nx, ny, dir, col, nid;
    xx = enigma::varaccess_argument0(int(self));
    yy = enigma::varaccess_argument1(int(self));
    radius = enigma::varaccess_argument2(int(self));As you can see it tries to get variables argument0, argument1 and 2 from obj_controller. As those variables don't exist it returns 0 for some reason (even thou it should return an error no?).
When I change it to this:

Code: [Select]

int i,c, radius, xx, yy, nx, ny, dir,col, nid;
xx=argument0;
yy=argument1;
radius=argument2;
with (obj_controller){It parses correctly.
So basically, arguments don't work inside with() statements. Also other.argument0 doesn't work either, it also returns 0.

edit: Also, a script is generated for all objects that uses it? Isn't that more bad than just creating one and making all objects use it?

[Josh @ Dreamland]

Hahahaha. Yes, since ENIGMA is the one that declares arguments, I should have had it add them to its list of script locals when parsing them. Silly mistake on my part; nothing to fret about.

[TheExDeus]

Here is another grid test people can test their speed on. This uses primitives, which I think is the fastest way to draw the grid. With sprites I had min 17, max 22 fps, with lines min 29, max 40 and with primitive I had min 34 and max 55fps. Now the objects are the bottleneck, because of the calculations I put them trough the fps drops to 52-55 even when no grid is drawn. And these numbers are actually very good, compared to GM which didn't exceed 1-2fps in any of these tests. It even had only 5-6fps when the grid wasn't drawing.

I did fail to change the line width. I know that glLineWidth(width); should work, but I tried it in different contexts (in the begin function, in end function and in the add_vertex function, as well as making it a separate function altogether (draw_primitive_set_line_width()) and it didn't work.

Anyway, I am ready and willing to add some new things to Enigma. I know that development takes time and all, but I really like rushing the more the better. Like it took me 1 evening to add all draw_background functions and another for all draw_text functions (thou they needed to be optimized, which also took another evening). So I believe that we could replicate GM's functionality in very short amount of time. I am not sure about the internals, but I believe most of the hard things are already done. And I am willing to create functions for the mechanisms already in place. For example, if I could get all of the point data for paths I could be able to make most, if not all, path functions.

[Josh @ Dreamland]

Now you're seeing the project like I do.

Most of the hard things are done. Roughly five remain. These are the three I can most readily remember:
1) Proper template instantiation for accurate type resolution on template parameter typed members (Working on this one right now).
2) Switch statement optimization/implementation (I need to be able to get the integer value of constants).
3) Proper argument type resolution (This may never actually happen).

From there, we have other some milestones that I will more than likely be the one to do:
1) Proper local modularization (See Ism's alarm code; I described to her how to do once what the compiler would soon be streamlining).
2) Comment based output sectioning for compiler feedback parsing (Meaning if GCC errors from the user's object headers, I just read up to the nearest comment to find out what object/script the error was in).
3) Depth. I told everyone how to do this, but I know I'll be the one to do it when I feel like it. It's not difficult at all.
4) Design mode (Build Mode from R3). You've probably never heard of it, but it was ENIGMA's trump card (I'm sort of working on it now).

Additionally, r9k is working on a polygon collision engine, and Ism is doing what I was hoping someone would do, being to take my collision_bbox_rect and do some bbox-based collision functions to get the system up and running in general.

Once that's done, though, I can pretty much stamp a big "DONE" on ENIGMA as far as being a competent development application goes, because the rest of the GM library is trivia and nonsense.


And, eh, move your draw_primitive_set_line_width(20); above your draw_primitive_begin().
Also, I was thinking about adding an option for scripts (embed in all, use with(), automatic). For now, I embed them all because memory is cheap, but not so much the extra time to dereference a non-this. (ENIGMA's with is actually pretty damn efficient, but...)

[TheExDeus]

Glad to hear its so close.

I too don't think you can make argument type resolution, as script arguments in GM can not only be a number or a string, but it can be both (in one place you add a number, the next place that argument is a string, and the script is made to account for that). I don't usually code like that, so argument type resolution would work in my case, but I am not sure if that actually makes any difference in speed. And yes, I am sure what I said didn't make much sense.

I am aware of Design Mode. I am actually here for a while now. I am registered in April 2008. I remember some screens of it a while back.

And yes, I now tried adding draw_primitive_set_line_width before _begin and it works. I was 150% sure that I did try that before thou... weird.

And how tha hell you got that sweet division in your post.
edit: Found it.