ENIGMA Development Environment

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

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

>=o

*undoes the filter thing*

Like I said, real easy to implement. Assuming I don't run into any problems getting a pointer to a function with 16 optional arguments, other than the shear size of the type name.

But it still seems pretty worthless. And no wonder you complain about speed, serpy. Mark never bothers to tokenize new object code ahead of time, or something. New objects are much, much slower than regular ones.

I know, I was wondering what that had to do with it being interpreted at load time.

because it makes you recap the entire topic.

O_o?

Ruiner of fun <_<

because I can.