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 / Re: Bragging
« on: January 18, 2009, 09:18:54 AM »
Either way, I wanna stay with GCC and GDB.

Oh, and Game_Boy, what did you mean with the syntax trace? That shouldn't be needed, since you check each individual file. If you mean check the outputted code, it should never be syntactically incorrect.

2687
Announcements / Re: Bragging
« on: January 18, 2009, 08:14:13 AM »
score_under-- That'd be great for me, but not for anyone else. (I happen to use GDB, which comes with Code::Blocks and Dev-C++)
For actual users, I want to have a full featured debug window. I have plans for it that are so big, I'ma keep them to myself for fear of sounding stupid.

2688
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.

2689
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.

2690
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.

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

2692
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.

2693
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.

2694
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.

2695
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.

2696
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.

2697
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.

2698
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.


2699
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.

2700
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.