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

Proposals / Re: LGM-ENIGMA options panel.
« on: May 18, 2010, 01:31:55 PM »
Well, you'd be rather pissed if you'd padded your lines with an extra plus or so, just to realize it won't work in ENIGMA. But yes, it is trivial, which is why it will default to the right (inherit from C++) for new games.

And yes, I assumed most hated #'s behavior as I did, but I'm willing to take the heat otherwise. The reason I'm not just allowing strict GM mimicry is that inheriting from C++ means a difference between "abc" and 'abc', 'abc' being an integer in every sense, as C++ types know.

I definitely want the format extensible; the question is how we're going to do it. We can learn from PHP and label blocks of the file; the blocks would be marked with a version just in case we wish to upgrade but keep the name (Shouldn't really happen). Blocks would then just be added with a new name/version as ENIGMA supported more resources/extensions.
Option two is to take a lesson from JAR and have ENIGMA's format be a compressed directory. I do believe Java has functions to add and remove from ZIP archives without repacking them constantly. It'd also reduce the risk of corruption, I believe (especially considering that there are tools to recover contents of zips). Also, it'd make writing version control for the format much easier; the file could contain the .svn/.git/whatever without disturbing anything else in the file. If a segment was causing error, it could be removed by the user. But it seems messy to me to constantly move shit out of a zip, so I'm not sure.

Ism, speak your mind on that, if you would.

Announcements / Re: Updates, Updates, Updates on the way.
« on: May 18, 2010, 01:16:51 PM »
I suppose this means it would be wise for me to update that list at some point. Have you added a mechanism to do such?
*scrambles to gather functions that have been coded but not included with ENIGMA*

Announcements / Re: Fixed those Makefiles
« on: May 17, 2010, 11:43:26 PM »
Indeed. And I could write it to a config file, and may end up doing so later depending on circumstances, but for now it's unnecessary and inconvenient; I'd rather it just worked for now.

Sprites work in R4 now. LGM is odd about its support for importing images with transparency, so be weary. ENIGMA doesn't mind them, however. Now's not the time to benchmark due to debug... scaffolding, we'll call it... left in place. I'll remove it promptly enough.

For now, good night.

Announcements / Re: Updates, Updates, Updates on the way.
« on: May 17, 2010, 05:49:49 PM »
I needed to think of a function, and that was the first that came to mind. :P

Announcements / Re: Updates, Updates, Updates on the way.
« on: May 17, 2010, 04:07:53 PM »
Code: (C++) [Select]
#include <iostream>
using namespace std;
int main() {
  string a = "hello, world";
  cout << a << endl;
  fflush(stdout); //oh snap, I didn't include this :3
  return 0;

Also, I added a tag for (int i = 0; i < 10; i++) inline code.

There's also a spoiler tag, a whisper tag which is probably not properly integrated as I did not inform Gary it exists... some other tags. I really just want the first two I showed, though.

General ENIGMA / Re: Tradeoff
« on: May 17, 2010, 03:43:17 PM »
Yes, people pop in from time to time anymore to see if there's a release date, then they vanish as quickly as they showed up.
The little bastards. :3

Announcements / Re: Updates, Updates, Updates on the way.
« on: May 17, 2010, 03:34:48 PM »
I was thinking that to reduce sever load it'd be a good idea to keep a generated copy of the page which could be refreshed by forum admins if the database is updated from an outside source.

Anyway, trouble is that BBParser I wrote is old and doesn't use SMF's style; it uses its own unique tag system. Nice thing is that it highlights code and has an inline code tag. If only the two could just be merged...

Announcements / The Saga Continues
« on: May 16, 2010, 09:54:29 PM »
I'm pleased to inform that Makefiles now work, themselves, exactly as I intended them to. I had some trouble getting them to work on Windows, but now it's looking good. I've renamed some of them to use the "proper" case. The rest will follow in their own time.

I have two computers in front of me. One is about seven years old and runs a single core, 2.9 GHz. It compiles and runs in roughly 5 seconds.
My other is a much more recent lap top. Roughly a year old, dual core, 2.88. It compiles and runs the game in about 2 seconds by my stopwatch (2.07, actually, thanks for asking).

Anyway, those are basically pointless statistics. I encourage users to check out 224 and test it for themselves. I'll be doing a couple important things next, in this order:
1. Add sprites to the exe again.
1.5. Deal with the series of adversities resulting from that move on both operating systems.
2. Replace var with my stagnating recode.
3. Replace instance system with my semi-documented second version. This will implement depth and hopefully heredity.
4. Reincorporate macros and scoping into the syntax check, as well as replacing operators := and <> (begin and end will be macros).
4.5. With the new instance system in, incorporate event behaviors, default events and event prefixes (such as alarm behaviors, default draw event [draw_sprite] and force calculations at the beginning of step).
5. Backgrounds from sprites.
6. ? ? ? ?
7. Profit? Just release? I don't know. Maybe I'll move on to sounds and leave the project in the SVN, maybe I'll make the testing phase more public by bringing the project out of the SVN.

There's not been a better time to check out the SVN than now (Yes, it's only getting better from here, I hope). If you do not know how, refer to old topics or ask here.
Please report all problems, however minor, preferably here until we've a bugtracker.

Furthermore, I should mention that I believe the new instance system will further lessen compile time. A schematic will be posted when one is available.

One last thing. If anyone who has checked out previously on Windows has trouble compiling, I recommend deleting your old makefiles and checking out the new ones. Windows and its SVN clients are... odd about that. To say the least. I suppose this goes for Linux fans, too, but it's unnecessary as make never tries to execute comment lines on Linux.

Proposals / Re: Tiering vs Components
« on: May 16, 2010, 08:13:08 PM »
Polygone: There's a new resource for C++ scripts. ENIGMA's backwards compatibility with GML will be more than sufficient to write a script in it, don't worry. It wouldn't be that difficult, but still, I'd rather not if it doesn't become a problem.

Proposals / LGM-ENIGMA options panel.
« on: May 16, 2010, 08:04:21 PM »
This is a tentative panel that will swell and shrink as I make up my mind on things.
However, this list can probably be inserted into documentation of some sort when it is settled.

Presently, these are the settings:
Inherit strings from:
Basically, this is where we will be inheriting the behavior of strings. ENIGMA introduces a new behavior in that show_message(chr(numbersignOrdinal)) will show "#", not a newline. Meaning that # is parsed as \n is in C, instead of handled special by every function that encounters it. This should cause little to no problem. As in, minor irritation in a very small minority of games.
Inherit ++/-- from:
In GML, ++ and -- are both the same as +. In C, they increment/decrement. This determines which it will do in the current game.
Treat Literals as:
Closing brace of struct:
As the most commonly missed semicolon, it was decided that it should be assumed to be there. This setting can toggle that off.

These are implemented, but should be reconsidered/removed:
Represent instances as:
I have yet to discover how well this will work with the room system's method of instance representation and yet to determine how to deal with any related changes that may be required as a result.
Store instances as:
"List" at least has become unnecessary due to my new instances system which has not yet been documented here nor implemented. Basically, it's because I'm storing things in multiple ways, list being one of them. I can still offer a choice between Map and Array for the other.

This should be added:
Inherit operator= from:
This needs implemented because I, for one, am offended by the behavior of a = b = c; in GML. It should set a and b both to c, not set a to the boolean value of b == c. So it'd be good to have an option for it.

Other potentially useful options that would have to be forms include these:

Default variable type: Defaults to var in all cases.
Default template parameter type: Thinking it should default to variant.

Questions I anticipate:

Won't this mean that you'll have to change things constantly?
No, these settings are local to each game. When Ism's versioning modifications are complete, this is Wwhat it will look like:
Loading a GM6/GMK will set all options to the left (unless Ism adds a mechanism to change this default GM import behavior).
Loading an EGM (which has yet to be genuinely forged, sadly) will load any previously saved settings.

Won't these mean huge recompile times?
For most of these, not if the tier system is implemented correctly for the lower systems and a unique system is implemented for higher systems. For the choice between array and map for instance storage, the system may or may not be geared to allow branched inclusion between the two. Don't count on it, though, as games using Array/Vector will probably be few anyway due to performance issues on create. :P

Proposals / Re: Tiering vs Components
« on: May 16, 2010, 07:12:02 PM »
Sticky how? My proposal for object_event_add was V8; Luda believes he could write a faster JIT compiler with the more focused purpose of interpreting GML; problem is the experience factor. Luda's a talented individual; so's serp, and I like to think I am, but I'm not sure how we'd fare against the abilities of V8's team, even with a vastly simpler language. Really, I'm still quite open to suggestions on that matter. I will probably code something that generates the backend of an interpreter for games, and I know exactly how that will be done, but the front end is still completely subject to debate.

I should, in fact, forward two proposals on this forum that are somewhat related to the matter.

Things aren't really sticky with bringing in C++ features, though; we're using a C++ compiler. All I have to do is understand the syntax enough to ignore it; to check that everything in <> is a type or simple value, and that all (t*)<(.*)> are replaced with t(.*) of equal size, and templates are introduced. Then I need a pass to get members of event-declared structures, then one to resolve all "a.b" in light of the new information. It's little more than I have to do to support globalvar (Which will end up as a macro to global var). The only aspect I really have to go out of my way for is the scope resolution operator, ::. But I'll recover.

General ENIGMA / Re: ENIGMA's value
« on: May 16, 2010, 04:45:42 PM »
What are you saying? :troll:

Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 04:45:15 PM »
Oh, that was just one of the 600 problems I've encountered on the way. Indented comments were executed; that was a more recent one.

The one I'm dealing with now is that parameters work differently on Windows. make GRAPHICS=OpenGL doesn't work anymore.

Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 02:16:12 PM »
You forgot the :troll:

Also, that's why "Compile" lets you choose the full filename. The 'exe' is meant for ENIGMA to run/work with.

Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 02:07:11 PM »
As a matter of fact, Linux is the only OS they work on at the moment, because Windows can't call make. ^_^
System() can't parse the program name from the arguments.
CreateProcess() can't find mingw32-make.
So really, it only works on Linux at the moment.

Makefile is given priority over makefile; other than that, either is fine.

Only one makefile should be outputting an exe, and it's the one under SHELL. Windows will only run EXE, Linux will run anything given --e permissions. So I used exe.