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

1951
Off-Topic / Re: WebM released
« on: May 19, 2010, 05:27:44 PM »
I thought it would be Google's right to release their work into the public domain if they get the patent. *shrug*

1952
Serp's really been pushing ( <-- pun ) the idea of switching to git. But I prefer SVN due to the fact that I find SourceForge less likely to go down and I prefer the history of my files be immutable; even when the file is deleted in later revisions.

1953
Announcements / Re: Fixed those Makefiles
« on: May 18, 2010, 09:11:13 PM »
Retro: All my makefiles use *.o to quickly link. The link target is depended on by Windows' and Linux' targets. The assumption is that you're using one of those. I separated it to avoid reprinting all its dependencies.

1954
Off-Topic / Re: c++0x
« on: May 18, 2010, 07:48:14 PM »
C++: It is easier when you are blind


:troll:

1955
Off-Topic / Re: c++0x
« on: May 18, 2010, 05:35:40 PM »
GCC's had and whored most of those for a while now.
It's not like template<> wasn't already ambiguous in some cases.
Fortunately, I believe lambda is the only exception to this not being a problem. I believe they introduced a couple more syntax quirks that I was going to add to ENIGMA anyway... I imagine it will all blow over well.
They've had typeof for a while. __typeof, it was. I just defined it as int for ENIGMA, because expression types don't really matter to my parser, as they are all just abstract names to it. I may need to fix that as they start pulling shit like typeof(something awful) :: some_member... Hopefully that never really happens, or by the time it does, a project I've had my eye on that can tell GCC to export XML reaches fruition.
Or becomes unnecessary as GCC decides to implement an alternative, which is even less likely.

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

1957
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*

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

1959
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

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

1961
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

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

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

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

1965
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