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.
166
Announcements / Progress Report
« on: March 10, 2009, 06:57:53 pm »
A2h just reminded me to the fact that I never tell you people anything. I guess I'm only really good at creating mob mentalities, as far as public relations go.
Anyway, progress. Um... Whew...
I guess I'll name stuff off as it comes to me.
get_string()
get_color()
show_menu()
show_menu_ext()
show_menu_ext_nl()
clipboard_get_text()
clipboard_set_text()
clipboard_has_text()
draw_sprite_part() works now. I'll probably go over them all again and replace things.
I also never mentioned the new version works on Linux, so I guess that'd be noteworthy...
Oh right, last version didn't have game_end(), so that's in now...
Also, a lot of key systems have been and are being redone, new version allows some neater things:
1) Heredity, at your option. To my dearest cynics: it's not as easy as putting :public parentobject after the child object's name; please wake up and smell the coffee.
2) Annoying variables don't have to be there; I'm implementing a system to let you get rid of the ones no one ever uses. (And perhaps some of the ingrown ones like hspeed and vspeed-- though to remove one is to screw the link between them and direction and speed)
3) You can now replace instance ids returned by instance functions with pointers. This will have a screwy effect on room systems if you remove ID completely. Still working out some bugs.
4) I recoded the syntax checker and intend to redo a couple pieces of the parser for efficiency and further extendability; this will allow C++ users to define functions in C++ as well as structures, so you don't have to use ds_stack garbage all the time. (Not that those are implemented yet anyway)
5) A long time ago now I added a system to let you change compiler flags. This lets you strip the outputted exe, and have the compiler run optimizations on it.
6) Compile takes less than a third the time it did before, and will probably end up taking even less as more systems are redone externally.
7) Scripts and variable access have both been rethought. The new system incorporates "other", and is even more efficient than the last one. Instead of dynamically casting objects myself, I'm going to have the compiler add some functions to the class responsible for such conversions. This means slightly less ugly output code, number one, but more importantly, it means only the variable you need is given attention. It'll use an array for best efficiency of lookup time; this will cost a byte for each object for each variable accessed by means of (a).b.
There's probably more, but I'm working on a new C file parser so I can stop going through my headers manually collecting function names. Now this'll do it for me, which will put more information at the hands of the compiler.
So yeah, I have work to do, as always. To be honest, I have no idea when I'm going to release it. I've fixed all the bugs I heard about since R3, so I guess I could make a stub of a release after I wrap some more of this up, but... I guess I'll decide later. If you gripe enough, I'll prolly release it.
Oh, and we're adding the rest of the resources to the format. They're not hard to pull off. Except maybe time lines. I'm too lazy to do more code resources <_<"
...Fine, I'll do them. Leave me alone, I have work to do.
Oh right, show_menu_ext is new. I'll show ext_nl, see if you get the picture.
That exact code produces this:
Also, here are the Linux shots:
Anyway, progress. Um... Whew...
I guess I'll name stuff off as it comes to me.
get_string()
get_color()
show_menu()
show_menu_ext()
show_menu_ext_nl()
clipboard_get_text()
clipboard_set_text()
clipboard_has_text()
draw_sprite_part() works now. I'll probably go over them all again and replace things.
I also never mentioned the new version works on Linux, so I guess that'd be noteworthy...
Oh right, last version didn't have game_end(), so that's in now...
Also, a lot of key systems have been and are being redone, new version allows some neater things:
1) Heredity, at your option. To my dearest cynics: it's not as easy as putting :public parentobject after the child object's name; please wake up and smell the coffee.
2) Annoying variables don't have to be there; I'm implementing a system to let you get rid of the ones no one ever uses. (And perhaps some of the ingrown ones like hspeed and vspeed-- though to remove one is to screw the link between them and direction and speed)
3) You can now replace instance ids returned by instance functions with pointers. This will have a screwy effect on room systems if you remove ID completely. Still working out some bugs.
4) I recoded the syntax checker and intend to redo a couple pieces of the parser for efficiency and further extendability; this will allow C++ users to define functions in C++ as well as structures, so you don't have to use ds_stack garbage all the time. (Not that those are implemented yet anyway)
5) A long time ago now I added a system to let you change compiler flags. This lets you strip the outputted exe, and have the compiler run optimizations on it.
6) Compile takes less than a third the time it did before, and will probably end up taking even less as more systems are redone externally.
7) Scripts and variable access have both been rethought. The new system incorporates "other", and is even more efficient than the last one. Instead of dynamically casting objects myself, I'm going to have the compiler add some functions to the class responsible for such conversions. This means slightly less ugly output code, number one, but more importantly, it means only the variable you need is given attention. It'll use an array for best efficiency of lookup time; this will cost a byte for each object for each variable accessed by means of (a).b.
There's probably more, but I'm working on a new C file parser so I can stop going through my headers manually collecting function names. Now this'll do it for me, which will put more information at the hands of the compiler.
So yeah, I have work to do, as always. To be honest, I have no idea when I'm going to release it. I've fixed all the bugs I heard about since R3, so I guess I could make a stub of a release after I wrap some more of this up, but... I guess I'll decide later. If you gripe enough, I'll prolly release it.
Oh, and we're adding the rest of the resources to the format. They're not hard to pull off. Except maybe time lines. I'm too lazy to do more code resources <_<"
...Fine, I'll do them. Leave me alone, I have work to do.
Oh right, show_menu_ext is new. I'll show ext_nl, see if you get the picture.
Code: [Select]
show_menu_ext_nl(m.x,m.y,"
Item 1
Item 2
Item 3
-
[]unchecked
[*]checked
()unradiod
(*)radiod
-
/Disabled
/Censored by Catholic Church
-
>Submenu
Submenu Item ZOMG
And another
What do we have here?
>Another SUBMENU
Goodness gracious
>More?
Yes there is!
<How about that?
<
<First level again
-
>One more submenu
With some more fixins
-
Like that separator
/and this disabled thing");That exact code produces this:
Also, here are the Linux shots:
167
Issues Help Desk / Hijacked Topic
« on: February 03, 2009, 04:48:36 pm »
Dave--
Quit undermining my authority. I'm clearly never wrong. >=[ ...haha
Also, wait. You hate ENIGMA, why are you still here?
score_under--
That would be painful.
Quit undermining my authority. I'm clearly never wrong. >=[ ...haha
Also, wait. You hate ENIGMA, why are you still here?
score_under--
That would be painful.
168
Announcements / Bragging
« on: January 18, 2009, 12:00:36 am »
It's not bragging if you can back it up, right?
Ism and I implemented a syntax checker. Yay. Now you can test if your code will compile (or at least, SHOULD compile) before you press the actual button, and have to go digging, yay.
Right now, Ism just displays my results in a message box. I'm hoping she makes it highlight the line soon, but that's not what I'm here to brag about.
I repeated the line
if a do if a=0 b=0 else c=d until x=0 else d=e f=0.1
about 2800 times, followed by
a b
at the very end.
I ran syntax check in LGM. Finished in about 3.3 seconds.
I then ran the same code through... another program that some of you may be familiar with. It took about 15.1 seconds.
So I am in a pretty decent mood, considering that even accounting for the overhead from passing files back and forth between ENIGMA and LGM, we're still outperforming other editors by... a lot.
With less nested things, the times are closer. Like 2 seconds vs 2.5. But ENIGMA's always ahead.
I guess that's the beauty of not generating a token tree every time you need to check syntax.
Also, ENIGMA not only gives line number, but an absolute index.
Say you have draw_line(1,2,3,4,5,6,7). It'll return the position of the comma following the 4. That way it's less confusing. I want Ism to highlight that, too, but again, we'll see.
Anyway, I'm tired. It's like... Not Saturday anymore. Gnight.
Ism and I implemented a syntax checker. Yay. Now you can test if your code will compile (or at least, SHOULD compile) before you press the actual button, and have to go digging, yay.
Right now, Ism just displays my results in a message box. I'm hoping she makes it highlight the line soon, but that's not what I'm here to brag about.
I repeated the line
if a do if a=0 b=0 else c=d until x=0 else d=e f=0.1
about 2800 times, followed by
a b
at the very end.
I ran syntax check in LGM. Finished in about 3.3 seconds.
I then ran the same code through... another program that some of you may be familiar with. It took about 15.1 seconds.
So I am in a pretty decent mood, considering that even accounting for the overhead from passing files back and forth between ENIGMA and LGM, we're still outperforming other editors by... a lot.
With less nested things, the times are closer. Like 2 seconds vs 2.5. But ENIGMA's always ahead.
I guess that's the beauty of not generating a token tree every time you need to check syntax.
Also, ENIGMA not only gives line number, but an absolute index.
Say you have draw_line(1,2,3,4,5,6,7). It'll return the position of the comma following the 4. That way it's less confusing. I want Ism to highlight that, too, but again, we'll see.
Anyway, I'm tired. It's like... Not Saturday anymore. Gnight.
169
Announcements / Merry Christmas
« on: December 25, 2008, 10:39:19 pm »
Figured I should say Merry Christmas.
Todo:
- Go through and replace all return 0; with return ENIGMA_VOIDVAL and all worthless int functions with ENIGMA_VOID
- Make all worthless doubles into ENIGMA_INTVAL (for less memory waste and easier transition to C++)
- Make rooms force performance of creation codes later, and to save an if() check in ctor, move create() from end of constructor to end of instance_create()
- Go back and redo draw_primitive_() (they're pretty terrible)
- Make sure sprites are optimized (they use map, God help us)
- Take care of vsync (that's the reason your framerate is 60)
- Fix window caption if it doesn't fix itself (it's liable to)
- Make sure going to different rooms works (I prolly broke that at some point, had a problem with creating two instances of some things)
- Add sprite_set_alpha_from_sprite() (had multiple requests for it, and it's easy)
- Allow using draw buffer as texture (Possible without framebuffer extension? With it?)
- Check alarm events, add collision events, add/fix/redo "other" (depending on what pieces of it I have. I want all this good stuff in asap)
This is all in addition to what I'm doing now, which is composing an interchangeable system for instance tracking, depending on the functions you use.
I'm thinking of having quite a few options, actually, including these:
instance storage:
- keeping instances listed in one big array
- keeping instances in a standard linked list (for games with lots of destroying but not a lot of instance_ functions)
- keeping instances in a map (long standing method)
depth tracking:
- keeping depth in a linked list (for games with two or three depths. Or like, less than ten.)
- keeping depth in a map (for those who say depth=-y)
- no depth (gonna be as big a pain to undo, but I'd like it as an option)
instance reference:
- id is an integer used for finding instances (slow like GM)
- id is an integer representation of the C++ keyword `this', and can be used for instant lookup (fast and hazardous)
- id doesn't exist; only `this' is used (plum crazy for our purposes, but it's efficient)
As for what's already done, I'm too lazy to list that. And it's Christmas. At 10 PM. So even though I had some good news a month ago that I still haven't shared... I'll just build up some things to throw at you all.
As for what I'm planning for bigger and better releases, that's subject to change as well as to hard criticism. Plus it's all totally unrealistic anyway, right? (Just like Build Mode, and, well, the entire rest of the ENIGMA project.) So I think I'll just say nothing on that, as usual.
Anyway, good night all, and Merry Christmas.
Todo:
- Go through and replace all return 0; with return ENIGMA_VOIDVAL and all worthless int functions with ENIGMA_VOID
- Make all worthless doubles into ENIGMA_INTVAL (for less memory waste and easier transition to C++)
- Make rooms force performance of creation codes later, and to save an if() check in ctor, move create() from end of constructor to end of instance_create()
- Go back and redo draw_primitive_() (they're pretty terrible)
- Make sure sprites are optimized (they use map, God help us)
- Take care of vsync (that's the reason your framerate is 60)
- Fix window caption if it doesn't fix itself (it's liable to)
- Make sure going to different rooms works (I prolly broke that at some point, had a problem with creating two instances of some things)
- Add sprite_set_alpha_from_sprite() (had multiple requests for it, and it's easy)
- Allow using draw buffer as texture (Possible without framebuffer extension? With it?)
- Check alarm events, add collision events, add/fix/redo "other" (depending on what pieces of it I have. I want all this good stuff in asap)
This is all in addition to what I'm doing now, which is composing an interchangeable system for instance tracking, depending on the functions you use.
I'm thinking of having quite a few options, actually, including these:
instance storage:
- keeping instances listed in one big array
- keeping instances in a standard linked list (for games with lots of destroying but not a lot of instance_ functions)
- keeping instances in a map (long standing method)
depth tracking:
- keeping depth in a linked list (for games with two or three depths. Or like, less than ten.)
- keeping depth in a map (for those who say depth=-y)
- no depth (gonna be as big a pain to undo, but I'd like it as an option)
instance reference:
- id is an integer used for finding instances (slow like GM)
- id is an integer representation of the C++ keyword `this', and can be used for instant lookup (fast and hazardous)
- id doesn't exist; only `this' is used (plum crazy for our purposes, but it's efficient)
As for what's already done, I'm too lazy to list that. And it's Christmas. At 10 PM. So even though I had some good news a month ago that I still haven't shared... I'll just build up some things to throw at you all.
As for what I'm planning for bigger and better releases, that's subject to change as well as to hard criticism. Plus it's all totally unrealistic anyway, right? (Just like Build Mode, and, well, the entire rest of the ENIGMA project.) So I think I'll just say nothing on that, as usual.
Anyway, good night all, and Merry Christmas.
170
Announcements / ENIGMA Needs a better storage method
« on: December 15, 2008, 07:19:44 pm »
I can't decide what to do next, actually.
I made a system that implements depth. The system can have a few different options, each of which has some unappealing drawback, I'm sure.
What I was going to go with was a red-black tree, just like STL uses in their map. (I may break down and just use STL, depending on how angry I am at them when I wake up tomorrow.)
What I designed the system with originally had no conventional sorting method.
Let me explain.
Instances were just added to a standard linked list for simplicity of working with them.
Then I have a list of event types, which point to a list of depths, which point to both a start and end position on a list of instance pointers. The instance pointers will have their corresponding event accessed.
This was so if you had 10,000 instances, three of which had a step event, ENIGMA would execute only the step events of those three.
I believe this is what "other software" does, so I guess I really had no choice.
Okay, now that I typed a page of exposition, here's the breakdown.
Positive: The nodes on the depth list point to the right points on the list of instances with each event just fine. There is no need to change the instance-event list.
Problem 1: The depths are accessed simply by iterating through the list until you find the right depth. So for those of you who say depth=-y, you may just run into a speed problem. (Nothing major, I promise, but it could still be a few milliseconds faster per call. Big deal, ha?)
Problem 2: The reason I'm mad at STL is because "other software" defies the laws of C++ and 'proper coding.' Meaning that when you say instance_destroy(), STL cries, cuz I'd have to delete an instance that God knows how many iterators are pointing at. (There actually should be just one, but I'd feel icky about just moving the iterator so I could defile the map) Knowing this, if I don't do anything, and just delete the instance from the map, the game will crash.
What I did in my tests was just 'orphan' the node. It's a term I coined for unlinking it, then deleting it after all iterations are complete. (At the very, very end of the step, when framerate is calculated, etc)
So yeah, I'm in a pickle.
Really smart people: Gimme suggestions
Everyone else: Just keep in mind I'm fussing over milliseconds here, and don't go whining "zomg enigmaare vap0rawre!11!"
Final thought:
If you post another newspost over my important questions and announcements, a2h, I will poke you with a VERY sharp stick. >=[[ And the new forum look sucks so I'd 'preciate it if you fixed that please and thank you. :3
I made a system that implements depth. The system can have a few different options, each of which has some unappealing drawback, I'm sure.
What I was going to go with was a red-black tree, just like STL uses in their map. (I may break down and just use STL, depending on how angry I am at them when I wake up tomorrow.)
What I designed the system with originally had no conventional sorting method.
Let me explain.
Instances were just added to a standard linked list for simplicity of working with them.
Then I have a list of event types, which point to a list of depths, which point to both a start and end position on a list of instance pointers. The instance pointers will have their corresponding event accessed.
This was so if you had 10,000 instances, three of which had a step event, ENIGMA would execute only the step events of those three.
I believe this is what "other software" does, so I guess I really had no choice.
Okay, now that I typed a page of exposition, here's the breakdown.
Positive: The nodes on the depth list point to the right points on the list of instances with each event just fine. There is no need to change the instance-event list.
Problem 1: The depths are accessed simply by iterating through the list until you find the right depth. So for those of you who say depth=-y, you may just run into a speed problem. (Nothing major, I promise, but it could still be a few milliseconds faster per call. Big deal, ha?)
Problem 2: The reason I'm mad at STL is because "other software" defies the laws of C++ and 'proper coding.' Meaning that when you say instance_destroy(), STL cries, cuz I'd have to delete an instance that God knows how many iterators are pointing at. (There actually should be just one, but I'd feel icky about just moving the iterator so I could defile the map) Knowing this, if I don't do anything, and just delete the instance from the map, the game will crash.
What I did in my tests was just 'orphan' the node. It's a term I coined for unlinking it, then deleting it after all iterations are complete. (At the very, very end of the step, when framerate is calculated, etc)
So yeah, I'm in a pickle.
Really smart people: Gimme suggestions
Everyone else: Just keep in mind I'm fussing over milliseconds here, and don't go whining "zomg enigmaare vap0rawre!11!"
Final thought:
If you post another newspost over my important questions and announcements, a2h, I will poke you with a VERY sharp stick. >=[[ And the new forum look sucks so I'd 'preciate it if you fixed that please and thank you. :3
171
Announcements / ENIGMA -- srs bizness
« on: November 23, 2008, 08:50:26 am »
As some of you fantasize in your over-idealistic views of ENIGMA, I'm doing my very best to make sure ENIGMA runs as efficiently as possible.
It's always a tear between memory and speed: with enough memory, you can make anything efficient.
Anyway, it's been trial and error. Here's an example of error:
Sprites, to date, have been kept in an std::map for storage. This way, if you have 2 sprites with sprite id's of 64 and 256, you only store two sprites worth of memory. That's a best-case scenario, though.
More often, you have some 8 sprites, all in order, and the lookup time for each sprite totally outweighs the benefit.
Other times you have a slower system that makes error reporting possible. Like when you try to create a nonexisting object, you get a friendly reminder that it doesn't exist.
So from now on, here's how it's going to be:
Everything in ENIGMA is going to be well oiled, but if you, say, request a non-existing sprite, the game will just die. No errors, no nothing. To get the errors, you will have to run the game in debug mode, in which the game will run far less efficiently, but will report any such silly errors.
This way, your end result will be a much, much faster game, but will be expected to have basically no errors at all.
(Honestly, would you release a game that still had errors in it?)
So let me put it simply.
If I do this, the end result will likely be around 10x faster, give or take. However, If an error would result in a segmentation fault, (C++ terminology for 'nasty error caused by memory access violations that kills the program without warning') your game will end without displaying any error messages or anything. (See list below for typical errors)
This harsh reaction, however, will only apply in release mode; debug mode will report any such errors and continue to run the game.
So if you're developing the game, you should be running it in debug mode pretty much the whole time, using build/run mode only after all the errors are out, either to verify final speed or to edit your rooms.
I'd like to know if you feel it'd be worth it. I know I do, but I guess it's only fair to tell you before I implement it.
List of typical errors:
So in comparison, debug mode will be lagtastic. But it'll still be fast enough, and it'll help you get all the errors out.
I'll see what I can do as far as debugging certain things at once goes.
The system will take a lot more work, and of course space, but hopefully it gets the job done.
Send me your thoughts.
-Josh
It's always a tear between memory and speed: with enough memory, you can make anything efficient.
Anyway, it's been trial and error. Here's an example of error:
Sprites, to date, have been kept in an std::map for storage. This way, if you have 2 sprites with sprite id's of 64 and 256, you only store two sprites worth of memory. That's a best-case scenario, though.
More often, you have some 8 sprites, all in order, and the lookup time for each sprite totally outweighs the benefit.
Other times you have a slower system that makes error reporting possible. Like when you try to create a nonexisting object, you get a friendly reminder that it doesn't exist.
So from now on, here's how it's going to be:
Everything in ENIGMA is going to be well oiled, but if you, say, request a non-existing sprite, the game will just die. No errors, no nothing. To get the errors, you will have to run the game in debug mode, in which the game will run far less efficiently, but will report any such silly errors.
This way, your end result will be a much, much faster game, but will be expected to have basically no errors at all.
(Honestly, would you release a game that still had errors in it?)
So let me put it simply.
If I do this, the end result will likely be around 10x faster, give or take. However, If an error would result in a segmentation fault, (C++ terminology for 'nasty error caused by memory access violations that kills the program without warning') your game will end without displaying any error messages or anything. (See list below for typical errors)
This harsh reaction, however, will only apply in release mode; debug mode will report any such errors and continue to run the game.
So if you're developing the game, you should be running it in debug mode pretty much the whole time, using build/run mode only after all the errors are out, either to verify final speed or to edit your rooms.
I'd like to know if you feel it'd be worth it. I know I do, but I guess it's only fair to tell you before I implement it.
List of typical errors:
- Accessing an undefined sprite: Fatal, debug mode will report it
- Accessing an undefined script: Will error at compile time
- Accessing any other undefined resource: Fatal, debug mode will report it
- Going past an array limit in a VAR: Not fatal, don't think debug mode will report it though
- Going past an array limit with pointers: Just fatal. It's a C++ thing.
- Division by zero: Fatal, debug mode will report it in var, cannot report it with int/double/etc
- Nonexisting variable: Totally impossible, may implement something to track that
So in comparison, debug mode will be lagtastic. But it'll still be fast enough, and it'll help you get all the errors out.
I'll see what I can do as far as debugging certain things at once goes.
The system will take a lot more work, and of course space, but hopefully it gets the job done.
Send me your thoughts.
-Josh
172
Announcements / Progress report
« on: November 16, 2008, 09:41:36 am »
Just so you people know I'm still alive.
I've fixed a lot since R3. You'll find basically all of this on the todo page, but since many aren't aware it exists, I'm posting it here.
I also have a special surprise in store, of which I'm sure a few of you are already aware. You'll be hearing about it quite soon.
As one last thing, ENIGMA R3b shouldn't be very long either. I'm mostly waiting for Luda to finish Colligma while going back and fixing errors, at this point.
What I'm currently working on:
- Redoing instances to fix a potential problem with rooms, as well as implement depth
- Working with create events and destroy events to avoid more problems with rooms
What I've recently done:
- Added something called PCS, or "Pre/Post-compile script", which will allow you to pass parameters to GCC as well as execute functions on the exe before resources are added. This will really help with filesize and speed.
Cheers.
I've fixed a lot since R3. You'll find basically all of this on the todo page, but since many aren't aware it exists, I'm posting it here.
- I redid pretty much everything and remade the syntax file (fnames.txt). And by redid everything, I mean I went over all the code and made corrections, minor, optimizational, or otherwise.
- draw_text no longer messes up the projection.
- Variables declared in scripts now work in any object that runs the script
- room_restart() and game_end() are now implemented. I also added room_next() and room_previous(), though it should be noted room errors in enigma are not fatal. (Division by zero, however, is VERY fatal. Don't divide by zero, ...<_<
- WILDCLASS now uses pointer-to-pointer-to types. Any kind of variable can now be referenced between objects.
- The script-path tracer is fixed, scripts are totally fine now.
- The parser's treating of typenames and casts is now fixed. The system makes a lot of assumptions that my thinking suggests are safe bets 100% of the time. In case of any compile errors in the upcoming release, PLEASE inform me.
- Array indexes involving arithmetic now work. What a sad glitch I had missed.
- The window resizes as room changes.
- Room background color is no longer inverted.
- Decimals with no preceding whole integer work again.
- Window functions now actually work. I just never bothered to test them before R3.
- Build mode will no longer freeze if either of the grid dimensions is set to zero.
- Friction is now accurate.
- Sprite indexes are now initialized properly.
- Views work 100% now.
- keyboard_check... and mouse_check... now use correct types.
- Instances that skipped an id number are no longer created twice.
I also have a special surprise in store, of which I'm sure a few of you are already aware. You'll be hearing about it quite soon.
As one last thing, ENIGMA R3b shouldn't be very long either. I'm mostly waiting for Luda to finish Colligma while going back and fixing errors, at this point.
What I'm currently working on:
- Redoing instances to fix a potential problem with rooms, as well as implement depth
- Working with create events and destroy events to avoid more problems with rooms
What I've recently done:
- Added something called PCS, or "Pre/Post-compile script", which will allow you to pass parameters to GCC as well as execute functions on the exe before resources are added. This will really help with filesize and speed.
Cheers.
173
Announcements / PatchA
« on: August 09, 2008, 01:39:42 pm »
So I fixed a lot of the surprise errors from yesterday. The important part is that it held up to basics and showed the improvements to the compilation process. There are still improvements to be made regarding the size and speed of compile.
For now, however, you can download a patch which fixes several errors, including object. and global., as well as transparency. There are a few more fixes to be made, but that will be done as we are able.
Also, place_free checks solidity now. LGM may have a problem conveying an object's solidity, so place solid=1; in the create event until that is resolved.
An automatic updater is planned, and in progress, but isn't available quite yet.
Download the Patch
For now, however, you can download a patch which fixes several errors, including object. and global., as well as transparency. There are a few more fixes to be made, but that will be done as we are able.
Also, place_free checks solidity now. LGM may have a problem conveying an object's solidity, so place solid=1; in the create event until that is resolved.
An automatic updater is planned, and in progress, but isn't available quite yet.
Download the Patch
174
Announcements / Disorder
« on: August 09, 2008, 12:46:20 am »
Well, I can say with some certainty that I've never released something just right the first time, in my entire life.
However, bare with us. At the last minute, we noticed a few things that weren't working, and scrambled to make them do so. This kind of thing generally leads to more mess.
I don't want to spend much time preaching about it, however, tomorrow a patch will be released to fix the majority of the known problems. You'll notice that ENIGMA-R2 has an a at the end. This is because it took me five minutes to realize I'd done something wrong there and reupload.
Tomorrow I'll sort out some of the rest of the stuff. The worst of it includes some borkage with place_free, an explanation for which can be found here:
http://edc.enigma-dev.org/index.php?p=blog&id=33
draw_text will hopefully be reimplemented, global. and object. will work again, and the world will be happy.
All of these, along with LGM's importation of build mode edits, were broken without anyone realizing it. This kind of thing is forgivable with such a huge project, right?
The version you have now is still somewhat usable, but tomorrow we'll patch the holes.
(Disclaimer: I could be lying)
Note: Some of you may have found that you downloaded R2 from SourceForge. We apologize. I'm not telling you whose fault that is, so THERE.
Anyway, I haven't slept in two days. Which probably doesn't help the disorder, so if you'll forgive me, I'm going to try that.
However, bare with us. At the last minute, we noticed a few things that weren't working, and scrambled to make them do so. This kind of thing generally leads to more mess.
I don't want to spend much time preaching about it, however, tomorrow a patch will be released to fix the majority of the known problems. You'll notice that ENIGMA-R2 has an a at the end. This is because it took me five minutes to realize I'd done something wrong there and reupload.
Tomorrow I'll sort out some of the rest of the stuff. The worst of it includes some borkage with place_free, an explanation for which can be found here:
http://edc.enigma-dev.org/index.php?p=blog&id=33
draw_text will hopefully be reimplemented, global. and object. will work again, and the world will be happy.
All of these, along with LGM's importation of build mode edits, were broken without anyone realizing it. This kind of thing is forgivable with such a huge project, right?
The version you have now is still somewhat usable, but tomorrow we'll patch the holes.
(Disclaimer: I could be lying)
Note: Some of you may have found that you downloaded R2 from SourceForge. We apologize. I'm not telling you whose fault that is, so THERE.
Anyway, I haven't slept in two days. Which probably doesn't help the disorder, so if you'll forgive me, I'm going to try that.
175
Announcements / No subject required
« on: August 02, 2008, 01:16:36 am »I had a request for the executables that were used in the making of that movie.
Here they are, as zip:
Download
176
Announcements / R3 Information
« on: May 17, 2008, 03:28:21 pm »Features
I'm doing more things to the third alpha to make it more like Mark Overmars' program Game Maker.Syntax check
This new release will indeed have a syntax check--which I am currently working on--for its off-brand language.Behind-the-scenes processing
R3 will also have some nifty things as far as 'apply a direction and speed, and watch game work' goes. That will take like five minutes to do; the hard part is making hspeed and vspeed change with direction and speed, and vice versa. Nevertheless, it will get done, and it will get done right.draw_text
I have implemented a basic draw_text(), and it is functional. I'll leave it to anyone who wants to work on it after R3, and I say this with high hopes for a potential new ENIGMA Team member X-Tra Fear, from the GMC. He is, from what I have seen of him, a GL expert. Which will certainly not hurt ENIGMA's speed and functionality.More callback related functions
In R3 you will find the keyboard callback of R2, as well as complete mouse button callback (all events and functions) for all three buttons, and the mouse wheel.Collisions
I'll let the rest of the cat out of the bag here. Ludamad from 64Digits has been working on a large collision system to power enigma, which from what I've seen has more than twice the features Game Maker offers. I do not have any data on speed for either Game Maker or ENIGMA to share with the public, but I am confident it will be fine. Luda has spent time optimizing the code to work with bits instead of chars, as many professionals do in similar systems. I can assure you it is memory efficient and assume it is speed efficient as well.iENIGMA
I have a release of GCC for Mac, but I lack a Mac to install it on. I may be able to gain access to it on the Macs at school, in which case ENIGMA R3 will support OS X development. I still haven't decided on and installed a version of Linux, so please be patient, Linux fans. This is also an invitation for anyone who has Linux or Mac to do me a favor and work on the callback for all that good stuff. It should be a two hour job to port ENIGMA to either of the consoles for anyone who knows what they are doing with the respective API, as all ENIGMA's draw functions and behind the scenes operations such as var, data structures, FPS measurement, etc. are all completely cross platform. The job meerly entails using the API to keep track of button status for all keys and mouse buttons in a small array, and to create a game window of the proper size with GL enabled.Thanks for reading, I'll be syntaxing.
-Josh
177
Announcements / Progress report, again
« on: May 08, 2008, 04:27:58 pm »
Just for regular visitors' info:
ENIGMA R3 is ready. This is labeled as the official "alpha" release, and is what I would have liked for you guys to have seen in the very alpha releases one and two.
However, I figure I may as well chalk it with some last minute goodies and general goodness. I have some giant surprises in store for release 3, assuming I can depend on the work and words of three or four individuals.
So get ready. R3 is looking stable, and on the way.
ENIGMA R3 is ready. This is labeled as the official "alpha" release, and is what I would have liked for you guys to have seen in the very alpha releases one and two.
However, I figure I may as well chalk it with some last minute goodies and general goodness. I have some giant surprises in store for release 3, assuming I can depend on the work and words of three or four individuals.
So get ready. R3 is looking stable, and on the way.
178
Announcements / Update
« on: May 05, 2008, 05:12:34 am »
Just trying to keep you people informed for now.
Progress is slowly kicking back in as I get deeper into some of the hidden problems. I had to rewrite var in its entirety to remove the segfault on cleanup.... That is no small task. Rest assured, however. I've learned a lot between writing it the first time and rewriting it now.
The old var boasted 5x faster than GM... This one boasts 10. I'm sure you're wondering how ENIGMA could get much faster. Or maybe you're not. But yeah, it just did. It's also more stable... Old var didn't like being a member of a struct that was dynamically allocated. I don't think this one really cares.
So yes... Enigma isn't canceled just because I can't show you progress like before, so no need to go from forum to forum talking about its imminent failure again.
I'll be working on object's cleanup next. This'll be even more difficult than var, I'm afraid...
Progress is slowly kicking back in as I get deeper into some of the hidden problems. I had to rewrite var in its entirety to remove the segfault on cleanup.... That is no small task. Rest assured, however. I've learned a lot between writing it the first time and rewriting it now.
The old var boasted 5x faster than GM... This one boasts 10. I'm sure you're wondering how ENIGMA could get much faster. Or maybe you're not. But yeah, it just did. It's also more stable... Old var didn't like being a member of a struct that was dynamically allocated. I don't think this one really cares.
So yes... Enigma isn't canceled just because I can't show you progress like before, so no need to go from forum to forum talking about its imminent failure again.
I'll be working on object's cleanup next. This'll be even more difficult than var, I'm afraid...
179
Announcements / Postponement
« on: April 23, 2008, 07:01:16 pm »
A few of you were probably looking for the release last weekend, which was *scheduled* for Sunday night release. However, I detected a segfault in instance_destroy(). And I'm not releasing R3 until I fix it.
Rest assured. R3 is even more special now, and I have a very nice treat in store for you guys, courtesy of ludamad.
R3 will have some organizational issues fixed, making the code more friendly to help. It's only managed to further cripple GDB so far, but whatever. That program was pretty useless anyway.
Anyway. Point is.
Release three is everything you wish you saw in Release 1, but didn't because beta isn't until Release 4 anyway.
I'll be working.
Rest assured. R3 is even more special now, and I have a very nice treat in store for you guys, courtesy of ludamad.
R3 will have some organizational issues fixed, making the code more friendly to help. It's only managed to further cripple GDB so far, but whatever. That program was pretty useless anyway.
Anyway. Point is.
Release three is everything you wish you saw in Release 1, but didn't because beta isn't until Release 4 anyway.
I'll be working.
180
Announcements / ENIGMA Release 2a
« on: April 14, 2008, 04:46:37 pm »
That's right! ENIGMA is now on release two, faithful fans. And as was intended, the alpha revealed all I needed to know about it, and now according to my testers, it is all working.
So to the really faithful fans who were here the first minute to download the new release, I'd like to apologize. The new release has been uploaded as ENIGMA-r2a. However, don't think you have to download all 20MB again. For those who downloaded the flawed alpha version, here is a patch:
ENIGMA Patch 2a
The patch is all of two lines that need replaced.
Thanks a ton to Chiken, who I sent some ten versions of the same exe until I knew where the error was and fixed it. (If I had the error, I would not have distributed)
As for the rest of you, all you have to do is download it from the downloads page.
Unfortunately, you will have to download the entirety of the new release, as the version of GCC that came with the first release is prone to failure. Just delete the old directory entirely, please.
What's new in Release 2a?
Basically all the bugs from Release one are corrected.
Also, for the time being, all ENIGMA games need to be under the GNU General Public license. IE, open source. This was an accident, which will be corrected in Version 1.0. However, for this series of alpha releases, it is actually a safety precaution as well.
Do not worry though. Just include the GM6 of the thing in the folder and we'll let everything else slide. I will be very lenient about this, especially as it is temporary. But it IS a safety precaution and WILL be treated as such if necessary. Keep that in mind, those who this concerns.
Thanks for reading guys, and enjoy the new release. Please report any and all bugs or suggestions in the enigma bug forum in the community. I will deal with them as rapidly as possible.
This release was about a week after Release 1. I do intend to keep a nice quick pace like that.
Thanks,
-Josh @ Dreamland
One more note concerning ENIGMA and LGM.
I refer to ENIGMA as an `IDE' simply because it is not a `compiler.' It actually just reads your game and intelligently decides how to code it. (More intelligently in the future though, I hope.)
The code it generates is passed to GCC (the MinGW distribution), a freeware compiler available here.
The IDE itself, that is, the interface you use to write code and put together files for ENIGMA to compile, is LateralGM. It is a project by an independent team, whose progress you can follow around their forums here.
Note that the version of LGM that comes with Enigma is a special build made specifically to accomodate Enigma, and not an official build, although it does give you a small sneak peak of the upcoming LGM version, 1.6.
So to the really faithful fans who were here the first minute to download the new release, I'd like to apologize. The new release has been uploaded as ENIGMA-r2a. However, don't think you have to download all 20MB again. For those who downloaded the flawed alpha version, here is a patch:
ENIGMA Patch 2a
The patch is all of two lines that need replaced.
Thanks a ton to Chiken, who I sent some ten versions of the same exe until I knew where the error was and fixed it. (If I had the error, I would not have distributed)
As for the rest of you, all you have to do is download it from the downloads page.
Unfortunately, you will have to download the entirety of the new release, as the version of GCC that came with the first release is prone to failure. Just delete the old directory entirely, please.
What's new in Release 2a?
Basically all the bugs from Release one are corrected.
- LGM can communicate with ENIGMA now.
- The code editor only displays functions that are implemented.
- Lengthdir now accepts integers as arguments without rounding.
- The default draw color is black.
- Division works like GM's.
- There is no parse iteration error.
- Withs are corrected, as far as I can see.
- Both sprite_add and in-game sprites work from what I can tell. (They are still primitive, so try not to overdo it yet.)
- A keyword "localv" has been added. It will tell ENIGMA that you are declaring the variable, but it is meant to be instance-local, not codepiece-local.
- The keyword "new" has been added to the parser. It is for C++ experts only.
Also, for the time being, all ENIGMA games need to be under the GNU General Public license. IE, open source. This was an accident, which will be corrected in Version 1.0. However, for this series of alpha releases, it is actually a safety precaution as well.
Do not worry though. Just include the GM6 of the thing in the folder and we'll let everything else slide. I will be very lenient about this, especially as it is temporary. But it IS a safety precaution and WILL be treated as such if necessary. Keep that in mind, those who this concerns.
Thanks for reading guys, and enjoy the new release. Please report any and all bugs or suggestions in the enigma bug forum in the community. I will deal with them as rapidly as possible.
This release was about a week after Release 1. I do intend to keep a nice quick pace like that.
Thanks,
-Josh @ Dreamland
One more note concerning ENIGMA and LGM.
I refer to ENIGMA as an `IDE' simply because it is not a `compiler.' It actually just reads your game and intelligently decides how to code it. (More intelligently in the future though, I hope.)
The code it generates is passed to GCC (the MinGW distribution), a freeware compiler available here.
The IDE itself, that is, the interface you use to write code and put together files for ENIGMA to compile, is LateralGM. It is a project by an independent team, whose progress you can follow around their forums here.
Note that the version of LGM that comes with Enigma is a special build made specifically to accomodate Enigma, and not an official build, although it does give you a small sneak peak of the upcoming LGM version, 1.6.