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: I got to thinking.
« on: August 09, 2009, 10:01:48 AM »
ENIGMA will always support GM functions for the same reason that Microsoft still has a thousand deprecated functions from Win95. It's just so old things you've made will still work.

Most of the GM functions are so vague that they will fit into any system we decide to build, especially for 3D. The most advanced thing his 3D functions can do is work with his own model format. It's almost pitiful.

I've wanted a mesh/material resource for some time now. The background resource, however, I'd like to stay named backgrounds and just have it apparent that they contain a texture. The more advanced users will be the ones using 3D, and they will understand that sprites and backgrounds can be treated as textures. Novice users, however, won't understand that textures can be used as a background image.

Or perhaps they will, but I always think it's best to start something at its simplest and then show how additional functionality is possible.

As for a mesh resource, I'd really like that. LGM doesn't have so much as a sprite editor at the moment, so I'm not going to speak for all the things I'd like to see in the IDE. However, making a 3DS importer shouldn't be difficult.

Right now, I'm focusing on making a fully functional parser. I believe this will carry us the rest of the way.

If you look at the GMC, you'll see a bubbling vat of ignorance. But amid that ignorance lies some true talent in specific individuals who dedicate their time to making GM-Compatible DLLs. Imagine if this group of people was able to develop (in their own language, for many of them) right in the game's file.

A new resource we have already added will allow users to add functions to ENIGMA that are as fast and functional as the official ones. And, should they develop a working system, it may go on to be an official part of ENIGMA. That's very idealistic, of course, but if nothing else, I know of several people who are at least decent at C++ who would be willing to help develop GM functions for ENIGMA.

What I'm getting at is that, with a little luck, people will come along to extend this thing far past where GM is, and hopefully past where I could have done myself.

And if I can get these new parsers working, users will have the C++ language at their fingertips, right along with GML.

General ENIGMA / Re: Game Maker 8
« on: August 07, 2009, 10:28:57 PM »
There's like 9001 reasons to ban you for that post, but I'ma just sit and laugh instead, while a2h does a little <_< thing.

Announcements / Re: Subject
« on: August 07, 2009, 09:21:13 PM »
* Josh hates bittersweet compromises

Announcements / Re: Subject
« on: August 07, 2009, 08:20:58 PM »
* Josh laughs for a number of reasons

Announcements / Re: Subject
« on: August 07, 2009, 07:24:21 AM »
* Josh wonders where the discussion went, but likes combos

Issues Help Desk / Re: Transparency
« on: August 07, 2009, 07:22:02 AM »
Because since then I've gutted the parser, and written three more. And now I have to get them all working before I release.

General ENIGMA / Re: Alternate to cpp {}
« on: August 07, 2009, 07:21:11 AM »
Since when?

Issues Help Desk / Re: Transparency
« on: August 05, 2009, 04:57:44 PM »
I'll make sure this works, but I recall fixing it.

I checked my fixed bugs list, and yeah, I fixed that. Just haven't released since, and now I can't release for a while. Heh.

« on: August 05, 2009, 11:05:57 AM »
Retro: Doubles are always 64 bits anyway. Long doubles are not though, so don't be fooled. I've seen long doubles of size 8, 12, 16... ung.
Serpy: Lambda kills kittens. I saw it. Don't use it.

Oh, and as serpy says, there are 10 byte doubles. But I've never actually seen one. score_under was telling me about an instruction for dealing with those a couple days ago, so I imagine they're somewhere. But since long double is 12 bytes anyway, there's really no need to be troubled with details of a 10 byte one.

General ENIGMA / Re: Alternate to cpp {}
« on: August 05, 2009, 11:03:26 AM »
As of R4, C++ is totally usable anyway. Meaning ++ and cout will both be available to you.

I may leave cpp {} in for people who understand parsed-EDL syntax, and are faced with a compile error that is not yet fixed.

General ENIGMA / Re: Writting Enigma's IDE in C#
« on: August 05, 2009, 10:58:18 AM »
If it's on page one, I think bumping it's fair game.

Bumping newsposts is >_<" though.

Announcements / Re: Subject
« on: August 04, 2009, 11:51:18 PM »
And the Commodore 64, sure. I just have to write up a couple window functions for t-- oh, that's right.

But seriously, all the major OSes either are Microsoft, or they support XLib. So that's BASICALLY everything with a monitor. And since GL guarantees two colors, and XLib doesn't guarantee shit, we're good.


(ddd)a is ccccca instead, so )a isn't misread and replaced with );a
Still working toward finishing parsers. Tomorrow I must experiment with syntax checker, making sure it's finished and incorporating inline structures/classes. (And inline asm if syntax check doesn't have that in yet).

Announcements / Re: Subject
« on: August 01, 2009, 09:25:45 PM »
If you mean that I should use something cross platform, there's nothing *that* cross platform for me to use. I'm writing it in as low a level interfaces as I can manage. From what I'm seeing, it should work on everything with a monitor.

...Okay, not really. But from what I can tell, pretty much everything in the realm of computers that doesn't support Win32Api supports XLib. And everything else... Well, I'll get to it.

Anyway, as for progress:

Code: [Select]
int a = 0; if a = 1 b=2c=3     else d=4 e=5 f='test removal of strings'g=\"poop\" \
 endorphin = /*removal of comments*/ 6; motherlicker = 7; //or eight\r\n end\
 break; label: goto label; awful_code() return 0  /*

Becomes these so far:
Code: [Select]
ddd n = 0; ss(n = 0);n=0;n=0;bbbb;n=0;n=0;n=";n=";nnnnnnnnn = 0; nnnnnnnnnnnn = 0; nnn;bbbbb; nnnnn: pppp nnnnn; nnnnnnnnnn();pppppp 0;
Code: [Select]
int a = 0; if(a = 1);b=2;c=3;else;d=4;e=5;f=";g=";endorphin = 6; motherlicker = 7; end;break; label: goto label; awful_code();return 0;
Although I was originally considering total removal of spaces, it's proven to work efficiently without doing so thus far. I think I may yet do so for later efficiency/ease, however.

As for explanation of methodology here...

This is a more insightful revamping of my original parser; the one written in GML. However, this one is more capable of handling all the C++ tokens, too.  The old one was modified to do so; this one is being designed for it.

I'm still using the original flow of things, though, so I think I can get away with saying it was still originally GML. The idea was good enough that it operated fine for its time...  now it just needs some polishing up.

Anyway, how it works is relatively easy when you break it down. The code is first stripped of all comments, strings, and whitespace for workability. Comments/Other whitespace become a single space. Strings of any type are replaced with the quote character ("). Variable names become "n". They are then broken down into specific treatments based on if they represent a statement...

Statements requiring () are replaced with "s". These include if(), with(), switch()...
Statements requiring a parameter without needing or plain without () become "p". Take return x; and goto lbl; for example.
Statements requiring an immediate semicolon are parsed as "b". This is raising some questions as to what to do with "do" and "else".

Those two exceptions ("do" and "else") cannot be treated the same.
Code: [Select]
do do a=b() until c=d until e=f
Code: [Select]
if a if b c() else else d()
The first code is valid if "do do" is left alone. The second is only valid if it becomes "else; else". The semicolon there means "do nothing". I'm considering just adding a token for each of them. (Probably "c" for do and "e" for else).

These will mean a couple extra rules added in two simple functions.

The code will seem so simple when it's all laid out. But for now, it's scraping brain matter.

Announcements / Re: Subject
« on: July 31, 2009, 08:52:36 AM »


Announcements / Re: Subject
« on: July 30, 2009, 11:07:13 AM »
And var xy; xy.a=0; will error "Undefined variable xy", even though you declared it. var x; errors that you can't redefine a builtin variable. Which is dumb. I may have to make EINGMA error if you say local int x; though.