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