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

1426
Proposals / Re: Script Editor Features
« on: February 25, 2011, 05:59:52 pm »
We may as well run with #region for ENIGMA's use, but we'll want to generalize it. Maybe with an interface for seeking to different regions.

1427
Announcements / Re: Happenings
« on: February 19, 2011, 12:23:47 am »
Stop in at the IRC. You'll see what's going on. Basically, we have more resource-related segfaults and more Mac issues than ever before, I've started a Java code editor for some reason, Ism's dealing with Mac problems, TGMG pops in at odd intervals and works on Mac problems, and everyone else has disappeared. All this, coupled with school work, has left me seeing stars, and I really just want something to bite into really, really hard.

1428
Announcements / Re: Happenings
« on: February 15, 2011, 11:12:28 pm »
Certainly not. Our inner workings have just been reduced to a clusterfuck again, as usual.

1429
Announcements / Re: Happenings
« on: February 01, 2011, 11:05:36 pm »
One last test, I hope:
http://dl.dropbox.com/u/1052740/ENIGMA-R4-r640-win.zip

Come on, lucky 640.

1430
Announcements / Re: Happenings
« on: February 01, 2011, 12:24:52 am »
Fixed, Griggs.

1431
Proposals / Re: LateralGM extensions; official proposal
« on: January 31, 2011, 03:08:35 pm »
Works for me.

Do as you see fit, Ism.

1432
Announcements / Re: Happenings
« on: January 30, 2011, 11:42:01 am »
I understand that much; all I'm saying is that those files have been in there for a while and they're still identical. But I haven't said anything about it personally because TGMG told me early on that they'd be changed at some point.

1433
Proposals / Re: LateralGM extensions; official proposal
« on: January 30, 2011, 10:33:55 am »
I'm saying that the save file and the GUI are both part of the Display tier. The Logic tier is responsible for preparing the data for the display. In Wikipedia's example, it sums it. Here, it'd put it into a Java-ready, file-ready, or C-ready format.

1434
Proposals / Re: LateralGM extensions; official proposal
« on: January 29, 2011, 11:44:45 pm »
I meant you didn't elaborate on "whatever the fuck Java uses..." :P

And where did I say logic then describe presentation? The logic tier adds shit before it makes it to be presented. I was trying to compare screen presentation to output file presentation; literally for presenting data to later instances or to ENIGMA.

That is the very image I as looking at.

1435
Announcements / Re: Happenings
« on: January 29, 2011, 11:16:29 pm »
Surfaces were removed after R3 because no one's shitty Intel card supported them.

As for the GLES folder, ask TGMG. He thought it would become necessary; we haven't seen it be so yet.

1436
Proposals / Re: LateralGM extensions; official proposal
« on: January 29, 2011, 11:14:55 pm »
I appreciate how you left the MDI definition untouched.

Anyway, I agree with your outer tiers, but I fail to see how the logic tier doesn't encompass the read and write functions. Thinking I had the concept wrong, I went to Wikipedia, and its example basically confirmed it; they gave the example of a cash register. The presentation tier was the display (the Mesh GUI), data was the sales database (the vertex buffer, metrics, and resource name); the logic tier added it all together for the display. The display is just an output, as saving is. The logic tier would simply provide an accessor for standardized access and, at your option, for writing. You can justify it either by asserting that the GUI and a save file are no different (multiple display tier entities) or by simply calling it allowing a method to merge the extension's data tier into the parent's. Doesn't matter to me anyway, really.

1437
Proposals / Re: ENIGMA Game Format
« on: January 29, 2011, 11:02:10 pm »
I side with Ism on not using EDL, despite the unification it would offer. LGM is Java, and the point of ENIGMA is for game development. Put simply, we don't have the resources (read: necessary number of programmers) to allow LGM development in EDL.

If we were to design our own format and make it an official part of our spec, then I strongly believe we should cut up the YAML format and run with the bits we like. Define our own behavior for tab and space mixing (namely, treating tabs and spaces identically). I don't mind using {} for groups to eliminate all ambiguity, but I think if python could do without them, so can we. I do like JSON, except I don't think quotes around keys is necessary.

Give the format some thought. We can probably come to an agreement on the IRC.

1438
Announcements / Re: Happenings
« on: January 29, 2011, 10:38:54 pm »
They may have been moved, or they may have, as you and XKCD pointed out, been redone to meet a new requirement. Which ones are you looking at? We've been making a point of removing or re-implementing them lately.

1439
Announcements / Re: Happenings
« on: January 29, 2011, 04:09:07 pm »
You can also put them in the Code::Blocks project or wherever else; there are a number of ways to add functions.

1440
Proposals / Re: ENIGMA Game Format
« on: January 29, 2011, 04:02:40 pm »
I feel the same way about XML, and I felt the same way about INI before I saw it was basically GNOME's .desktop format.

YAML is actually pretty easy to parse, but parsers do backflips and are relatively gross in concept. @Rusky I didn't consider offering multiple formats; I think we should have the specification call for it, but I personally don't want to include multiple parsers. Are you suggesting that the file should give a doctype, or that (1) the reader will be expecting the same format the writer uses and (2) an intervening human would be able to tell which format it was? I'm thinking the latter; doctypes are gross.

As for JSON, I recall that it was very similar to YAML. In fact, looking at sample JSON, it seems that YAML is just an ugly mix between Python and JSON (it uses Python's indentation grouping instead of {} like most of everything else).

So basically,
XML is out of the question unless the specification is to allow flexible formats (in which case ENIGMA will =NOT= be using XML anyway),
JSON is just better-known and more stable YAML and would be a practical consideration (I'll have to modify my YAML parser or strap on a standard one).
INI is an older format and would require compromise on both ends.
YAML makes Ism's skin crawl (the full spec makes my skin crawl) and would involve sizey compromise on either end to support fully, and
eYAML is a concise implementation of YAML that makes only Ism's skin crawl but would be too specific for a general format, thus requiring formats to be optional as per Rusky's proposal.

I am, in general, all for having the text format be up to the extension. However, it seems messy to specify that there is no specified format for these text files, and messier to constrain it to four or so well-known formats without having some doctype, which are nasty.
Should we settle on some means of allowing multiple formats, we still have to choose one for LGM extensions to use (I personally doubt we'll use more than one for just ENIGMA, though we should leave it open for future users to do so).