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

2686
Announcements / Bragging
« on: January 18, 2009, 12:00:36 AM »
It's not bragging if you can back it up, right?

Ism and I implemented a syntax checker. Yay. Now you can test if your code will compile (or at least, SHOULD compile) before you press the actual button, and have to go digging, yay.

Right now, Ism just displays my results in a message box. I'm hoping she makes it highlight the line soon, but that's not what I'm here to brag about.

I repeated the line
if a do if a=0 b=0 else c=d  until x=0 else d=e f=0.1
about 2800 times, followed by
a b
at the very end.

I ran syntax check in LGM. Finished in about 3.3 seconds.
I then ran the same code through... another program that some of you may be familiar with. It took about 15.1 seconds.

So I am in a pretty decent mood, considering that even accounting for the overhead from passing files back and forth between ENIGMA and LGM, we're still outperforming other editors by... a lot.

With less nested things, the times are closer. Like 2 seconds vs 2.5. But ENIGMA's always ahead.

I guess that's the beauty of not generating a token tree every time you need to check syntax.

Also, ENIGMA not only gives line number, but an absolute index.
Say you have draw_line(1,2,3,4,5,6,7). It'll return the position of the comma following the 4. That way it's less confusing. I want Ism to highlight that, too, but again, we'll see.

Anyway, I'm tired. It's like... Not Saturday anymore. Gnight.

2687
Off-Topic / lies
« on: January 09, 2009, 12:29:21 PM »
That'd still be redistribution. I'm pretty sure you can lay a hat on the street and have people put money in it while you reverse engineer something.

And Retro, they say a lot of things. It's so people feel a tad safer using something with no walls.

2688
Off-Topic / Re: Reverse Engineering
« on: January 03, 2009, 11:07:34 AM »
You just can't redistribute them once you have.  Or redistribute them at all, for that matter.

2689
Announcements / Re: Happy New Year's!
« on: January 01, 2009, 11:29:03 AM »
Happy New Year's, all

2690
Announcements / Re: Merry Christmas
« on: December 28, 2008, 10:50:33 PM »
Not really. I got rid of them after too many people's hardware sucked.

2691
Announcements / Re: Merry Christmas
« on: December 28, 2008, 03:58:26 PM »
ID is just this, so it's a pointer to the instance in memory. I've never seen a pointer less than 10000, so that shouldn't even be a concern.

2692
Announcements / Re: Merry Christmas
« on: December 28, 2008, 03:53:39 PM »
I'll typedef self and local to this, global to actual global structure, and I guess noone can stay -1.

2693
Announcements / Re: Merry Christmas
« on: December 28, 2008, 03:36:10 PM »
because this is C++. I'm not just changing a word around, I'm removing all the time wasted by having id and self meaningless numbers like 100001 and -3.

2694
Announcements / Re: Merry Christmas
« on: December 28, 2008, 01:42:09 PM »
Actually this and id, but yeah.

Since ID is just a number from 100001 up, using it involves looking up an instance in a list. For best results, I'd use a regular linked list and use this to identify objects.

'Other programs' use something along the lines of a map, I'm sure, and use the map's amazing lookup prowess to find the instance, instead of just being able to say "There it is!" like using this would allow me to do.

2695
Announcements / Re: Merry Christmas
« on: December 26, 2008, 01:32:13 PM »
There's no need. My changes all have a default setting that doesn't change the look of the language at all. (Except typenames, but meh, those'll come in time)

The changes are to let you select a faster option that may compromise how close the two languages look.

2696
Announcements / Merry Christmas
« on: December 25, 2008, 10:39:19 PM »
Figured I should say Merry Christmas.

Todo:
- Go through and replace all return 0; with return ENIGMA_VOIDVAL and all worthless int functions with ENIGMA_VOID
- Make all worthless doubles into ENIGMA_INTVAL (for less memory waste and easier transition to C++)
- Make rooms force performance of creation codes later, and to save an if() check in ctor, move create() from end of constructor to end of instance_create()
- Go back and redo draw_primitive_() (they're pretty terrible)
- Make sure sprites are optimized (they use map, God help us)
- Take care of vsync (that's the reason your framerate is 60)
- Fix window caption if it doesn't fix itself (it's liable to)
- Make sure going to different rooms works (I prolly broke that at some point, had a problem with creating two instances of some things)
- Add sprite_set_alpha_from_sprite() (had multiple requests for it, and it's easy)
- Allow using draw buffer as texture (Possible without framebuffer extension? With it?)
- Check alarm events, add collision events, add/fix/redo "other" (depending on what pieces of it I have. I want all this good stuff in asap)

This is all in addition to what I'm doing now, which is composing an interchangeable system for instance tracking, depending on the functions you use.

I'm thinking of having quite a few options, actually, including these:
instance storage:
- keeping instances listed in one big array
- keeping instances in a standard linked list (for games with lots of destroying but not a lot of instance_ functions)
- keeping instances in a map (long standing method)
depth tracking:
- keeping depth in a linked list (for games with two or three depths. Or like, less than ten.)
- keeping depth in a map (for those who say depth=-y)
- no depth (gonna be as big a pain to undo, but I'd like it as an option)
instance reference:
- id is an integer used for finding instances (slow like GM)
- id is an integer representation of the C++ keyword `this', and can be used for instant lookup (fast and hazardous)
- id doesn't exist; only `this' is used (plum crazy for our purposes, but it's efficient)

As for what's already done, I'm too lazy to list that. And it's Christmas. At 10 PM. So even though I had some good news a month ago that I still haven't shared... I'll just build up some things to throw at you all.
As for what I'm planning for bigger and better releases, that's subject to change as well as to hard criticism. Plus it's all totally unrealistic anyway, right? (Just like Build Mode, and, well, the entire rest of the ENIGMA project.) So I think I'll just say nothing on that, as usual.

Anyway, good night all, and Merry Christmas.


2697
Announcements / Re: ENIGMA Needs a better storage method
« on: December 19, 2008, 04:20:01 PM »
That'd take way too long, and be far too inefficient.

2698
Announcements / Re: ENIGMA Needs a better storage method
« on: December 17, 2008, 06:43:16 AM »
Ism-- Nope, that certainly wouldn't work here.  At least not well. I'm mostly concerned about speed. Space is an issue to.

For some games, there's only one or two depths, so a tree would be overkill.
For others, there are closer to 41, or even up to 640 different used ones. So a tree would be a little nicer, but still, I can't imagine there really being 640 simultaneously used depths, so...

As for instances, I think a tree would be best bet. That way lookup is really fast, even though removal and creation are slowed.

2699
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

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