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: Game Maker 8
« on: July 21, 2009, 09:34:53 pm »
I just have to change random_integer to irandom. I'll also need to study their random_range function to see what it does. Shouldn't be difficult.
(Fun fact: seeds in ENIGMA produce the same results as the same seed in GM/Delphi)

If by alpha masks, they just mean you can specify which color is transparent, ENIGMA and LGM can already do that. We agreed on it for later extensibility.

I'd like someone to tell me how constants are defined now, though.

Announcements / Subject
« on: July 21, 2009, 09:27:47 pm »
I told a2h to rag on me to post what I've done each day.
Don't get your hopes up though; I'm not updating the stupid 'completed functions' page.

Recent activities include collecting all my work from the last few months and organizing them into the same root directory.
What's basically happening is I'm hooking up the Expression evaluator, CFile Parser, Syntax Checker, and EDL Parser up to the Compiler, regardless of what's done and what's not.
This will, ideally, allow me to get them all working together and add on as I go.

I've also begun a large-part recode around the original EDL Parser. It has to be done at some point. Why? Well...

It's a somewhat-known fact that the EDL Parser is written in GML. A lot of you are thinking "wtf" right now. I wrote the parser, then exported it, and parsed it to C++ with itself. And it worked. (With the addition of function names around each script it parsed).

It instantly gained at least a tenfold speed increase, but that's not enough.
(Not to mention parsed GML is plug ugly; NO comments, which is 1% less than the 'desired' percentage of comments I normally leave, and no whitespace or structure)

Basically, the idea's brilliant, but the code's a bit sluggish and eww since it used to be GML. Was the ultimate benchmark, but now things need to be implemented that GML can't describe.

Please take the next couple minutes to get over the fact the parser is/was GML. Read on when you're ready.

Moving on, then, the new parser will not use < to indicate tokens in its stream. Instead, it will add a couple more letters for equally fast, less ambiguous indexing.

Scripts were scoped into each object that used them in R3. In R4, they will be defined in the global scope, and will be passed this. (The C++ loose-equivalent of id) This corrects a problem where with (a) scrname() doesn't work. You probably didn't notice.

Also, localv is being changed to local in light of Yoyo deciding that global var a; was a good idea. Now you can say local var a;, which is about as useless as saying self.varname, but is useful for saying local int a; or local double a; and not wasting all that space and time. (Though not much of either, really.)

Those who pay attention and have decent footing between these two languages know that you will now have the entirety of C++ at your disposal. If you really wanted, you could #include <iostream> and cout << "something";. Unless I decide that I'm going to maintain checking for assignment operator, in which case you'd have to say something stupid before it with an =. Haha.

There's another chunk of work I'm not looking forward to, which involves the new format. We've added basically every resource to the format, but this doesn't mean they all work yet. I'll derive background from sprite, but sound is gonna be a pain in the arse.

Another change, for those with good footing in C++, is that string() will not be a function anymore. GML fans,  don't panic: Saying string() will still work. The difference is purely technical; string() will be a constructor of a new datatype.
I had a problem with var that prohibited me from taking int as an argument type, which hindered efficiency. The new string class should fix that problem. It will be derived from std::string, with some additional namespace magic to prevent screwups.

If anyone really needs me to explain the details of that, I can, but I'm not going to unless someone asks.

In other other news, I'll be continuing development on Linux. Most of you know ENIGMA works on Linux now. Since the OS is more picky with things--for instance, file name capitalization--I think it'd be a good idea to move to it. And file names aren't the extent of it; big GCC, as in, the GCC which is not minimalist or for Windows and likely has the majority of GNU devs on its case, offers more precise error checking and warns on more things. Which is nice, as it prevents errors down the road.

Anyway, I'ma get back to working on the compiler. I have to find my new instance system and put it in the shell folder. After it's at a good stop point, I'm wiping the SVN and reuploading everything. (Makes it easier switching back and forth between platforms).

No news on ENIGMA's LibOGC frontend.

Cheers. A2h will hopefully make me edit this tomorrow. Maybe even post new.

« on: July 01, 2009, 01:37:29 am »
I couldn't agree more. Until it's been five or six days. Because I only love GA / WiMoMaCon 1,000,000 times.

Announcements / Re: Expression Evaluator complete.
« on: June 21, 2009, 09:26:04 pm »
Yoyo's going to be making everything, just ask them.

Announcements / Re: Expression Evaluator complete.
« on: June 18, 2009, 09:02:26 pm »
I only replace them in if()'s and the like.
I find that a=b=c=0 is too damn useful to dispose of. I'll probably end up option-izing it.

Announcements / Re: Expression Evaluator complete.
« on: June 17, 2009, 09:20:53 pm »
Yeah, I didn't really put much thought into converting it to GML. I just flipped a couple macro values.
Either way, nice catch. Noted for whenever this is applied to debug mode. And since this evaluates just the expression part, not the actual assignment operator, it'll be as simple as replacing that error with treating it as a comparison.

Announcements / Expression Evaluator complete.
« on: June 16, 2009, 02:26:59 pm »
I'm pleased to inform that the expression evaluator is working just as I'd hoped.
I'd like it to have a public test.

There are two versions. The C++ one, and the GML one. The C++ one is for macros, and so does not allow strings or floats. (Numbers that aren't integers.) Also as per preprocessors, it doesn't allow casts. (Though, there is a cast system implemented.)
This means that 5/2 = 2.
The GML one does allow strings and floats. It should work just like you're used to.

Note that functions and variables aren't in yet. It's an expression evaluator. It's designed for #if. Variables will be treated as zero. I just overkilled it a bit so I could more easily make a full fledged interpreter later on.

Other changes include that ternary exists, and there are more than two string comparison operators.
(("str"=="str")?"true":"false")+"zor" is my favorite string test.
Also, note that single quotes are treated as numbers in C++, and I think I left them that way in the GML one. So 'str' is a number, "str" is a string.

This means one less step on my todo list. One more item checked off.

Those who wish to try it out can download it here:
Both as 7z / as zip
C++ as 7z / as zip
GML as 7z / as zip
When the window pops up, you are immediately allowed to type. You can clear the screen by typing c or cls, and close it by typing x. (And pressing enter.)

Anyway, I'm going back to the CFile parser now, which I've been told by many is the impossible task for one person with no tools. But I don't care what they think. ^_^

Also, feel free to keep guessing at the secret from last topic.
I'll be working.

Issues Help Desk / Re: *solved* execute_string
« on: June 10, 2009, 10:47:47 am »
Sure you can, it just won't be as fast as if it were compiled. Still, though, it will be real time.

It does bring out some vulnerabilities, though, as a list will need to be kept of variables in the game, even if they are hashed.

Issues Help Desk / Re: Lol
« on: June 09, 2009, 02:46:45 pm »
It's also for writing entire operating systems. And Dave's right; C will leave you with some nasty habits in C++.

Announcements / Re: Compatibility Issues
« on: May 05, 2009, 02:18:40 pm »
Sprintf(), all of the C++ world hates you for no reason at all. Go away.

Also, I'm not dumping useful Windows functions just because Linux and Mac don't have something just like it. That's what SDL did; it's a wonder SDL even creates a window for you since it provides no interface to manipulate it. <_<

Announcements / Re: Compatibility Issues
« on: May 04, 2009, 05:14:56 am »
 Not for ENIGMA, just in general to see what my options are. There aren't any ENIGMA functions that depend on it yet.
 I don't want to set a release date, but I'm hoping a month, maybe two. It's a lot of time, but I want all the bugs out, and I want the system to be at its best and most solid. With all the other releases, I've left room for improvement. With this one, I'm trying to leave only room for additions.
 And yeah, I know it's been a while. Sometimes I forget how long a while, and then I remember, gee, the last release of ENIGMA still takes more than a few seconds to compile. But I'm pulling out all the stops.

 Hero for the day.

Announcements / Re: Compatibility Issues
« on: May 03, 2009, 09:46:10 am »
Every number is currently a double. Which is the problem; doubles are slow.
And yes to the MIME types. But I don't know where that data is stored. I've used GConf, for setting hot keys system wide, but I don't know where it keeps that info.
Ism was looking into ext/ just yesterday, and turned out to not have permission to write to it except when she was root. So that's no good either.

And again, I'm sort of opposed to the idea of keeping the registry file in the main directory. Ism suggested a hidden folder on the user's home directory. Since GM uses registry_set_root for some BIZARRE reason, (it's almost like GM was meant to be cross platform), I could easily rig it to change locations of where I'm writing. But I don't think I'd have permission to put anything on the root of the drive, either. If I did, though, registry_set_root could simply change the directory I write the registry info in.

Also, Retro, I don't want to make a separate release for each group of Windows platforms. I'll stick with the idea of allowing it to be recompiled for older systems. LGM can probably make calls to ENIGMA to rebuild parts of itself for different platforms, since GCC will always be available.

Announcements / Re: Compatibility Issues
« on: May 02, 2009, 02:56:21 pm »
I'd have to agree with that.

For Linux and Mac, I was thinking about writing it to the var folder, if permission allows, because I'd really rather not store things like that in the same folder as the game, for obvious reasons. Not so much for security, considering the registry really isn't as hidden as GM users would like to believe. In fact, I don't think security of it would really be a problem: If you're on Linux, chances are you already know what Windows' system registry is anyway, so putting it in a nearby file wouldn't make much of a difference in that respect. Here, the real beauty of the registry (or writing to var/ in Linux' case), would be that the game could still access the data, even if it the game's file was moved without the registry file.

Thinking about it, Windows' registry is also used for associating file types. To be honest, I'm not sure how that works on Linux, so that'd require some research... It'd probably never be compatible anyway. But ENIGMA wasn't really intended to need to associate file types anyway, and if the need arises, I can always make a built-in function for that.

Announcements / Compatibility Issues
« on: May 02, 2009, 12:09:17 pm »
Questions that have been haunting me since day one, and I'm sick of dealing with them, so I'll present them to my user base.

  • Var can't return int, string, double, and char*. It just can't; it leads to ambiguity out the back end to where your game won't compile.

Knowing this, do I have all the functions take double and string as parameters (a 100% waste of memory and at least 800% waste of speed), or do I alienate std::string as a return type?

Neither of those are very attractive choices. There is a middle option where I have the user decide whether or not they want to keep var as a type, and re-compile ENIGMA optionally to take scalar arguments. (Scalar meaning one type, in this case of the smallest needed size)

I will try again to get var to work with conflicting cast types, but std::string is the one that causes ambiguity. Even though I added an explicit cast function for it in var. (Meaning I told it exactly what to do to convert var to string, but it errored anyway.)

  • Game Maker does not have functions that don't return anything. Even functions in GM that return nothing will actually behave as zero, and can be used in assignment and arithmetic. This isn't the case in C++.

For the first three releases, I returned zero in all those functions, as int for max speed.

Why not do away with them? Some people like to add a function that needs called but returns nothing to a function that must be called after the first function, in order to call them in one statement. Like registry_set_root(3)+registry_read_real_ext("blah","blah")

That's an ugly, yet useful feature of the language. I was considering having function return ENIGMA_VOID, and the return statement at the end be return_void;. This would enable the user to choose whether or not to do this and recompile.

  • Game Maker does not return success or fail. Especially for functions like registry_write_string(). A lot of functions that are VERY prone to failure have unclear methods or no method at all of determining whether it worked.

Should ENIGMA return error codes as WinApi does? For registry functions, this would also eliminate combining things like registry_set_root(3)+registry_read_real_ext("blah","blah"), though since registry_set_root will never fail and the latter returns nonzero normally, that's not exactly the best example here.

Maybe a function to check if the last calls succeeded?

  • WinApi has developed some since its first release in 1912. As such, we have a set of 16 bit functions that are preserved for compatibility with 95 and 98, but then more recent functions that are meant for 2000+ and may not work on really old Windows systems.

The problem here is, do we stick with the old ones and risk being obsolete come Windows 7, or do we lose 95 and 98 compatibility and go with the new? Again, this can be fixed by compiling separate releases for each operating system, but that's not exactly attractive as an option.

There are plenty more conflicts, but these are just a few that are immediately bothering me.
If you haven't guessed, registry functions have been implemented.

College classes are nearly over; I have a huge take-home final exam to worry about this weekend, followed by 23 more days of high school. But then I'm done, and will actually have a decent amount of time to work. I hope.

Announcements / Re: Progress
« on: April 28, 2009, 03:11:38 pm »
Bleh, happens. Not sure why FireFox didn't form complete the password for me, and really not sure how I took five times to enter it correctly. (The last two tries I copied and pasted in the correct password... Even confirmed it with a2h to make sure.)