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 / 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:
  • 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.


Announcements / Re: Progress report
« on: November 22, 2008, 05:33:04 PM »
Not so much as size optimization as additional speed optimization, always in the speed of the running game, but especially in compile speed. Seriously, do you see how long that thing takes?

...I've slightly improved it since R3, but this series of patches I'm working on is what's gonna push it over.

Announcements / Re: Progress report
« on: November 22, 2008, 01:07:26 PM »
Oni-- My last piece of eyecandy was 300KB stripped. (100KB zipped, 30kb 7z'd)

Retro-- Define frameskip. Just to do nothing for one step? Simple.

Announcements / Re: Progress report
« on: November 21, 2008, 06:16:49 PM »
Yeah, lots of waiting going on, but like I said, still and always renovating.

Made my own instance list that will handle depth now. Currently it can insert and delete, etc; the easy things. I'm making an even lower-cost list to handle cleanups.

Tips, Tutorials, Examples / Re: motion_add();
« on: November 16, 2008, 04:35:50 PM »
No, assemblers assemble code. You just write it.

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 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.


Tips, Tutorials, Examples / Re: show_message()
« on: November 16, 2008, 09:20:26 AM »

Issues Help Desk / Re: collision_rectangle
« on: November 16, 2008, 09:16:16 AM »
there was one, actually. It's in my demonstration platformer. :P

Issues Help Desk / Re: ds_list_ functions
« on: November 16, 2008, 09:07:47 AM »
ds_list was done by Rusky. I have still yet to implement it, or test it for myself.

negmod was a general replacement for % after I discovered % didn't take doubles, and had trouble with negatives or something.

Either way, it's basically just (char) & 0xFF now.

Issues Help Desk / Re: A replacement for draw_text
« on: November 16, 2008, 09:05:35 AM »
It's there in R3, assuming it functions. Does it...?

Check if it's on my list of corrected bugs in R3b

Issues Help Desk / Re: Global variables
« on: November 16, 2008, 09:04:38 AM »
global. works, I believe. Certainly does now, and I'm pretty sure it did in R3.

Issues Help Desk / Re: How do we use our own CPP library files?
« on: November 16, 2008, 09:04:11 AM »
you could just include the file after its dependencies in SHELLmain.cpp, then add any newly implemented functions to fnames.txt.

Issues Help Desk / Re: A few questions...
« on: November 16, 2008, 09:02:56 AM »
What Rusky said.

I leave it there for debug purposes, mostly, but if you bypass the syntax checker you could just continue developing your GM project in C++, I suppose. As long as you were willing to add in all the missing functions yourself.

Function Peer Review / Re: The formula for finding point_distance.
« on: November 16, 2008, 08:59:04 AM »
XD @ i constant

Nah. C++ would just kill your game for you. ^_^

General ENIGMA / Re: working codelines blabla
« on: November 16, 2008, 08:52:20 AM »
I gave it an honest effort, but I guess what it boils down to is this:

fnames.txt is filtered C++ syntax.
LGM's (or whatever it is) is their own syntax that, mind you, is a real pain in the arse to convert to.

So every time I do something, I'd have to update it in mine, which I do a poor enough job of, and then I'd have to update it in theirs, too.

I'll see what I can do, though.