ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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

General ENIGMA / Re: Discussion of "No subject required"
« on: November 30, 2008, 10:21:27 PM »
to very hot

General ENIGMA / Re: Discussion of "No subject required"
« on: November 30, 2008, 10:21:20 PM »
pushing this over

Proposals / Re: Some things just have to be deprecated
« on: November 30, 2008, 01:31:12 PM »
Well, localv was meant to be used in create, but I could rig static to behave like localv except in constructor. That's only if I have to, though.

Using localv in the create event is virtually the same thing. The create event's been bouncing in and out of the constructor in my mind, but it actually is in the constructor in R3. (It won't be next release, because it'd save time to call it in instance_create instead of checking that we aren't in a room create later. If it's in a room create, I need to make sure all the instances exist before calling create events, I think. I need to run tests...)

Proposals / Re: Some things just have to be deprecated
« on: November 30, 2008, 12:13:35 PM »
I fear you'll find static doesn't get along with instances.
Stays the same after you delete an instance and recreate it.

In other words
Abandon all hope.

« on: November 30, 2008, 11:13:38 AM »
I learned my lesson with that one. Got a lot of heat from game_end() not being implemented, despite its simplicity.

Either way, you shouldn't take it so hard. It's like if I walked to the GMC and posted an ENIGMA topic. I'd get some oohs and ahhs between the spear chucking, but, er... That's no place to pick up new customers.

Tips, Tutorials, Examples / Re: Alternate to game_end
« on: November 29, 2008, 11:44:11 PM »
Practically nothing errors at runtime in ENIGMA.

If you want to end the game, say:
cpp { 1/0; }

I'll mention that game_end is implemented for next release, though.

Tips, Tutorials, Examples / Re: choose(), mean(), median()
« on: November 29, 2008, 11:37:33 PM »
GM "compiles" things into a token tree. At load time. Instead of beforehand. Or it'd be just slightly more secure.

Either way, stdargs can't take custom classes anyway, iirc. So even under ideal conditions, if I could determine arg count, this wouldn't work. =\

General ENIGMA / Re: Wuts dis I c thar
« on: November 26, 2008, 09:25:42 AM »
I'll put my thoughts on the staff board.

My comments are free, though.

1) Nice design
2) Ugly SourceForge banner at the top, with bulky useless banner. Eeew.
3) Hosted on SourceForge, which is even more eeew.
4) Still not integrated with EDC. Will it be easier to?

Announcements / Re: ENIGMA -- srs bizness
« on: November 25, 2008, 06:43:21 PM »
Since the game wouldn't compile if there were any truly undefined variables, they just don't exist in ENIGMA. So here, undefined means that you didn't say varname=something; before you said if(varname) or function(varname).

Announcements / Re: ENIGMA -- srs bizness
« on: November 23, 2008, 06:04:01 PM »
Whew. For a minute there I was afraid everyone'd be like ZOMG NO DUN HURT OUR PRESHIS ERRORZ

Issues Help Desk / Re: NOOB QUESTION!
« on: November 23, 2008, 05:04:26 PM »
I was never good at writing help files and readme's.  *shrugs*

Either way, yeah, 3D should be far more extensible than GM, since there'd be no overhead from calling a DLL, which you'd have to do in GM.

General ENIGMA / Re: I think that you'll be pleased to know
« on: November 23, 2008, 05:00:38 PM »
NAWT FAIR. I want an imaginary name to go along with my imaginary program! D:

Oh wait, ENIGMA has screen shots and releases.... Never mind.

General ENIGMA / Re: Enigma/GM, different code?
« on: November 23, 2008, 09:49:40 AM »
Or rather, "Will be some time in about, say, a year and a half or so".

Sounds about right. I see what you mean, you want it for temporary use.


I don't wanna defile comments, but I guess I could easily do it. Again, I'll think about it. (Probably a yes)

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.