Pages: 1 2 »
  Print  
Author Topic: ENIGMA -- srs bizness  (Read 7237 times)
Offline (Male) Josh @ Dreamland
Posted on: November 23, 2008, 08:50:26 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2949

View Profile Email
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
« Last Edit: November 23, 2008, 09:06:26 AM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) ludamad
Reply #1 Posted on: November 23, 2008, 09:37:15 AM
Developer
Joined: May 2008
Posts: 1256

View Profile Email
I wouldn't have it any other way.
Logged
Offline (Unknown gender) Game_boy
Reply #2 Posted on: November 23, 2008, 09:37:55 AM
Member
Joined: Apr 2008
Posts: 228

View Profile
This is a fantastic idea. I absolutely support it.

In the same way, could you make the debug mode compile faster than normal (but reduce game speed)? Testing games is going to be a pain when you have to wait the full compile time to test something. However, when games are released, obviously initial compile time can be completely sacrified for speed as it is compile once, run many.
Logged
Offline (Unknown gender) ludamad
Reply #3 Posted on: November 23, 2008, 09:41:51 AM
Developer
Joined: May 2008
Posts: 1256

View Profile Email
He can't really make it compile that much faster unless he could rig G++ to make like 0 optimizations. Otherwise he'd need an interpreter.
Logged
Offline (Unknown gender) Game_boy
Reply #4 Posted on: November 23, 2008, 09:50:43 AM
Member
Joined: Apr 2008
Posts: 228

View Profile
He can't really make it compile that much faster unless he could rig G++ to make like 0 optimizations. Otherwise he'd need an interpreter.

OK. What about turning on more optimisations than default in the release mode?
Logged
Offline (Unknown gender) ludamad
Reply #5 Posted on: November 23, 2008, 09:59:21 AM
Developer
Joined: May 2008
Posts: 1256

View Profile Email
That's certainly a good idea for final release, compiling with "Best Optimization" will be an option in ENIGMA already, according to Josh.
Logged
Offline (Female) serprex
Reply #6 Posted on: November 23, 2008, 10:13:15 AM
Smooth ER
Developer
Joined: Apr 2008
Posts: 106

View Profile WWW
What of exceptions?
Logged
Offline (Male) RetroX
Reply #7 Posted on: November 23, 2008, 10:36:00 AM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
Wouldn't it just be easier to catch these kinds of things during compile?
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Female) serprex
Reply #8 Posted on: November 23, 2008, 10:45:32 AM
Smooth ER
Developer
Joined: Apr 2008
Posts: 106

View Profile WWW
Easier to include testing for special cases? Not really
Useful? Perhaps, but these are runtime errors. The very nature of a runtime error kind of implies that it can't be solved at compile time
Logged
Offline (Unknown gender) Game_boy
Reply #9 Posted on: November 23, 2008, 10:56:27 AM
Member
Joined: Apr 2008
Posts: 228

View Profile
That's certainly a good idea for final release, compiling with "Best Optimization" will be an option in ENIGMA already, according to Josh.

Sounds good.
Logged
Offline (Male) RetroX
Reply #10 Posted on: November 23, 2008, 12:09:34 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
Yes, but checking for undefined objects in scripts would work during compile.  Dividing by zero can be checked.
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Unknown gender) ludamad
Reply #11 Posted on: November 23, 2008, 12:25:21 PM
Developer
Joined: May 2008
Posts: 1256

View Profile Email
RetroX:
A=floor(rand());
B/A;

How is one to make a compile time error there?
Logged
Offline (Male) RetroX
Reply #12 Posted on: November 23, 2008, 12:50:42 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
oh.
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Unknown gender) Game_boy
Reply #13 Posted on: November 23, 2008, 01:18:52 PM
Member
Joined: Apr 2008
Posts: 228

View Profile
RetroX:
A=floor(rand());
B/A;

How is one to make a compile time error there?

Very easily. Take the range of the values rand() returns, and have the compiler spawn that many instances of the executable, ecah one with a different value, inside virtual machines. If there is more than one such function, simply create a virtual machine for each pair of possible values. Any conceivable ENIGMA application should only require a few trillion test cases. But you could be ABSOLUTELY confident that no runtime errors would happen.

EDIT: It should be obvious I am joking. If not, then I assure you I am.
« Last Edit: November 25, 2008, 02:18:45 PM by Game_boy » Logged
Offline (Unknown gender) ludamad
Reply #14 Posted on: November 23, 2008, 01:21:44 PM
Developer
Joined: May 2008
Posts: 1256

View Profile Email
Game Boy: Ever heard of the halting problem? For the same reason there is no clear cut way of finding out, in general, whats going to happen on runtime. Also, you aren't taking into account user input. I assume you were joking, but still, it simply isn't possible. It's not turing computable.
Logged
Pages: 1 2 »
  Print