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

2701
Announcements / ENIGMA Needs a better storage method
« on: December 15, 2008, 07:19:44 PM »
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

2702
Issues Help Desk / Re: Enigma communication error
« on: December 13, 2008, 03:20:02 PM »
[size=8]>_<[/size]

2703
Proposals / Re: Some things just have to be deprecated
« on: December 13, 2008, 03:16:54 PM »
>=o

*undoes the filter thing*

2704
Announcements / Re: OMG BLOGS
« on: December 11, 2008, 04:56:09 PM »
(5+5)2 = 100

2705
Proposals / Re: Some things just have to be deprecated
« on: December 08, 2008, 06:10:36 PM »
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.

2706
Tips, Tutorials, Examples / Re: choose(), mean(), median()
« on: December 08, 2008, 08:00:33 AM »
Actually, it turns it into... I spose I'll say a byte code, for lack of anything better to call it. It's pretty close to compiling, only it's compiling for itself to read later, not the system to read later.

2707
Tips, Tutorials, Examples / Re: choose(), mean(), median()
« on: December 06, 2008, 06:13:27 PM »
I know, I was wondering what that had to do with it being interpreted at load time.

2708
Proposals / Re: Some things just have to be deprecated
« on: December 06, 2008, 06:12:54 PM »
Practically never.

2709
Issues Help Desk / Re: Enigma communication error
« on: December 06, 2008, 06:12:34 PM »
because it makes you recap the entire topic.

2710
Proposals / Re: Some things just have to be deprecated
« on: December 06, 2008, 05:51:08 AM »
It's useless, all right.

switch function()
{
case 0: script0()
case 1: script1()
case 2: script2()
}

That's the only piece of code it could replace.

I suppose execute_script would be easy enough to implement. So as soon as I see it on the request page, I'll do it. Ha

2711
Tips, Tutorials, Examples / Re: choose(), mean(), median()
« on: December 06, 2008, 05:48:09 AM »
O_o?

2712
Issues Help Desk / Re: Enigma communication error
« on: December 06, 2008, 05:45:35 AM »
>_<

I'll find the bug. Hopefully.

2713
Tips, Tutorials, Examples / Re: Alternate to game_end
« on: November 30, 2008, 10:30:09 PM »
Ruiner of fun <_<

2714
General ENIGMA / Re: Alternate to cpp {}
« on: November 30, 2008, 10:22:13 PM »
then what's wrong with cpp { if() {} }?

For EDL'ers that aren't good with C++'s more picky syntax, they'll never need cpp{} around  only a starting brace, unless they're just taking code from somewhere else, in which case they should still be versed enough as to use semicolons.

The only time it'd be nice to have cpp <> is for a complex C++ for loop, followed by a with statement. But I don't think we'll be seeing much of that.

Maybe if someone actually turns up a case where cpp <{}> would be useful... otherwise it's just more symbols to type.
I suppose I could make it <{}> or {}, but...

I'll think about it.

2715
General ENIGMA / Re: Discussion of "No subject required"
« on: November 30, 2008, 10:21:33 PM »
because I can.