ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

Pages: 1 2 3 »
  Print  
Author Topic: LGM-ENIGMA options panel.  (Read 5552 times)
Offline (Male) Josh @ Dreamland
Posted on: May 16, 2010, 08:04:21 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2951

View Profile Email
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

« Last Edit: May 16, 2010, 08:05:54 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) IsmAvatar
Reply #1 Posted on: May 17, 2010, 09:58:01 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 877

View Profile Email
New option added in r225.

Quote
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 What 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.
* Creating a new game in LGM will set all options to the right

As of r225, the settings are always set to the left, and other behaviors are not implemented yet. This should change soon.
Not that it really matters yet, because Enigma doesn't even have a mechanism for handling the settings yet.
« Last Edit: May 17, 2010, 10:00:10 AM by IsmAvatar » Logged
Offline (Unknown gender) luiscubal
Reply #2 Posted on: May 17, 2010, 01:01:59 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
Quote
In GML, ++ and -- are both the same as +.
To be fair with GML, it kind of makes sense. -x is the same as 0-x, and +x is the same as 0+x. So ++x would be 0+(0+x), which is x, and --x would be 0-(0-x), which is also x. It is, therefore, perfectly acceptable and recommendable behavior for any language which allows +/- prefixes but not ++/-- operations.

Quote
This determines which it will do in the current game.
Seriously? I mean, it's quite a trivial detail of GML. It's not like people will abuse this "feature". I mean, it's the kind of thing nobody does intentionally, right...? Right...?

Quote
show_message(chr(numbersignOrdinal)) will show "#", not a newline.
Great! I always hated this in GM. Mostly because I didn't know how to escape it.

Quote
EGM (which has yet to be genuinely forged, sadly)
A good starting point would be to decide if there is going to be ANY GM feature you won't *EVER* implement(GM itself, not GML, since code is plain text anyway).
After that, you'll want to decide if you want the format to be extensible(as in, old ENIGMA versions can read future EGM files mostly, except for features they don't support, and plugins can add stuff like versioning information to the file) or if you want to use a GM-style format.
Once you have those two decided, drafting the format should be really easy.
Logged
Offline (Male) Josh @ Dreamland
Reply #3 Posted on: May 18, 2010, 01:31:55 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2951

View Profile Email
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.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) serprex
Reply #4 Posted on: May 18, 2010, 02:40:25 PM
Smooth ER
Developer
Joined: Apr 2008
Posts: 106

View Profile WWW
Demur: .jar is a bad idea to find inspiration from
Demur: .jar is meant for release
Demur: You're only picking over source representation
Demur: Making it an uncompressed directory probably suits better
Josh: Post so
Demur: Why should I?
Josh: well, if you wanted credit for the idea
Demur: It's the obvious solution
Demur: sprite0 sprite1 naming scheme
Demur: If people want, they can reorganize IDs on their own
Demur: Want to add a resource? Put it in the directory
Josh: except it loses part of the idea
Josh: which is to have a format that's easy to upload
Demur: Zip the directory
Demur: Done
Josh: :P
Logged
Offline (Unknown gender) luiscubal
Reply #5 Posted on: May 18, 2010, 04:11:43 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
I actually like the ZIP solution.

The system could be:
Code: [Select]
/enigma
/game.settings
/game.info
/sprites/...
/sounds/...
/fonts/...
/objects/...
/timelines/...
/rooms/...
/some-extension-data/...

ZIP is only of the most extensible file formats you could think of.
However, that does cause the problem of figuring out what the correct file format for objects, rooms, etc. is.
Should scenes be extensible? Should the filename be the *name* or the *ID*? Should the ZIP have the subfolders or should that go in the manifest? Or should that be in the file data?
Logged
Offline (Female) serprex
Reply #6 Posted on: May 18, 2010, 04:17:25 PM
Smooth ER
Developer
Joined: Apr 2008
Posts: 106

View Profile WWW
Zip is a good format for distribution, but having to go through the process of zipping any save isn't nice. Thus why it'd be good if Enigma supported opening zip files, but in reality worked with uncompressed directories. Trust your file systems
Logged
Offline (Female) IsmAvatar
Reply #7 Posted on: May 19, 2010, 09:39:34 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 877

View Profile Email
Recall - jar is really just zip with some special rules - namely that the manifest should appear near the beginning.
Logged
Offline (Unknown gender) luiscubal
Reply #8 Posted on: May 19, 2010, 10:00:15 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
Java has native support for zips in its APIs. Not sure how fast it is, but you can tell Java to sacrifice compression for speed.
Logged
Offline (Female) IsmAvatar
Reply #9 Posted on: May 19, 2010, 10:02:37 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 877

View Profile Email
Java also has native support for JAR in its APIs.
Logged
Offline (Unknown gender) luiscubal
Reply #10 Posted on: May 19, 2010, 10:32:38 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
Are there any advantages of JAR over ZIP, considering how similar they are?
Logged
Offline (Female) IsmAvatar
Reply #11 Posted on: May 19, 2010, 11:18:26 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 877

View Profile Email
a JAR is runnable.
Logged
Offline (Unknown gender) luiscubal
Reply #12 Posted on: May 19, 2010, 12:08:40 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
ENIGMA projects are supposed to be directly runnable(without compiling first, that is)?
Logged
Offline (Female) IsmAvatar
Reply #13 Posted on: May 19, 2010, 01:08:24 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 877

View Profile Email
You asked me if there's any advantages of JAR over ZIP, and I answered truthfully.
Since Jar was mentioned before and partially dismissed, I just wanted to make it perfectly clear that the difference between zip and jar was almost negligible before someone made a fool of themselves an burst in here with a "zomg, how to open jar on windows? Use zip plz".

That said, jar is mostly intended to make use of the manifest file, and thus its primary purposes are signing files and release distribution. As you've pointed out, for simple project files, which is basically just a collection, and not a runnable, unless signing is desired, zip is just as good as jar, with a very minor edge being that it's more recognizable and does not imply release distribution.

As for how signing files would be achieved from the Java api, I'd have to look into it, since it's not immediately apparent in the JAR api (would probably be a 2-step process: Use another API to sign, and then use the Jar API to stick the signature in the manifest).
« Last Edit: May 19, 2010, 01:10:54 PM by IsmAvatar » Logged
Offline (Unknown gender) luiscubal
Reply #14 Posted on: May 19, 2010, 01:14:32 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
I'd go for ZIP with a different file extension (*.egm).
Even if we use JAR, I'd say a specific file extension for ENIGMA has advantages (particularly to avoid confusion and for file association)
Logged
Pages: 1 2 3 »
  Print