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 / ENIGMA Game Format
« on: January 28, 2011, 10:19:02 PM »
ENIGMA needs its own format for game storage. GM takes far too long to load and store some executables; I was thinking it would be best to use a format allowing for quick addition, subtraction, and modification of contained resources.

With that in mind, and with the interests of picking a format that works well with Java, I believe our best bet is to use ZIP.

Essentially, .ogf or .egm files would be a compressed directory containing a subdirectory for each resource, which would be in its own format. I was thinking that the format could be largely eYAML; for instance, a sprite would be given a file name reflecting its ID (sprite0000.ey), and would contain a name: and file: attribute indicating, of course, the actual name of the resource and the image file it contains. This way, the format would basically document itself.

Just as easily, however, individual resources could be kept in separate binary files with their own unique formats.

As an option, a manifest file could be kept, but I think it'd be nicer if users could open and manipulate the resources in any zip-capable file browser and text editor. ZIP also reduces the likelihood for total corruption, and there are many tools around which can repair damaged zip files. Plus, since ZIP is he medium of choice for Java, it is unlikely we will encounter such an issue if we are using Java's own ZIP functions for the same purpose.

Any other settings would be stored in the trunk of the Zip, along with the game information and other important metrics.

This concludes my proposal for the egm (ENIGMA) or ogf (Open Game-) format. If you believe you have a better idea, post it here, and I'll call you a trollwe'll have a reasonable debate.

Proposals / Re: Static object variables
« on: January 28, 2011, 03:17:00 PM »
Frankly, I kind of like it better as ::, too. I'll see about supporting all three ( . -> and :: ) for their C++ purposes.

Proposals / Re: do-until
« on: January 28, 2011, 02:10:12 PM »

Function Peer Review / Re: move_towards_point
« on: January 28, 2011, 09:50:29 AM »
Correct. Game Maker will complain, hence, ENIGMA is backwards-compatible.

Proposals / Re: unable to parse (obj.variable) = value;
« on: January 28, 2011, 08:26:46 AM »
Neither does C++. But C++ lets you do this:

Code: (C) [Select]
function() = script(); //GM doesn't have references
(double&)varname = 10; //GM doesnt have types
++varname = 12; //GM doesn't have ++
(expression1,expression2,varname) = 10; // GM doesn't allow coma separation in expressions
var + 1; // Error: Assignment operator expected
cout << 1; //Error: Assignment operator expected

So it became a question of how messed up I wanted to allow the syntax to be.

Function Peer Review / Re: move_towards_point
« on: January 28, 2011, 08:21:07 AM »
Indeed. I've managed to make variant work as fast as double, but double is still slower than int. Granted, they are hundreds (int thousands) of times faster than Game Maker, but best practice is to declare them. local int varname; will take care of all your woes.

You can stick a cast anywhere in an expression you like in ENIGMA. Just like ++, or !. Casts are just another unary operator.

Announcements / Re: Happenings
« on: January 28, 2011, 08:15:02 AM »
Yeah, I still need to run that, but I'm afraid it'll gripe that it's not privileged. I'll add that now.

Proposals / Re: mask_index
« on: January 28, 2011, 12:54:53 AM »
I only bothered to set it when Colligma was hooked up. It wouldn't have gone unnoticed for long if it was needed. And hell, Ism's capable of adding it, now. She's done so in the past.

Function Peer Review / Re: move_towards_point
« on: January 28, 2011, 12:54:16 AM »
with (obj) direction=dir, speed=spd; isn't worth porting, considering the corresponding C++ is completely different.

Proposals / Re: Static object variables
« on: January 28, 2011, 12:52:43 AM »
As it stands, ENIGMA uses . for all other access. A single dot will represent the correct choice of GM access (integer.variable), instance access (inst.member), or pointer access ((&inst)->member). I was considering having it resolve scopes as well, but it may require a special flag on results from the type resolver or before the call to it, depending on how I have it structured (An actual 'int' keyword should be distinguishable from an int variable).

Proposals / Re: Multiple Theads, are they a possibillity?
« on: January 28, 2011, 12:48:07 AM »
What I was thinking about doing is adding threading by the same mechanism that I can add instance deactivation. Basically, I would keep a new tree and shit for each thread (deactivated instances get placed in thread -1, which is never processed).

Threading an object would be as simple as saying instance_thread(inst,thread).
Users would be allowed to figure out for themselves that sometimes life isn't as easy as putting everything in its own thread and hoping depth and shit stay in order.

Proposals / Re: unable to parse (obj.variable) = value;
« on: January 28, 2011, 12:44:45 AM »
I was under the impression the syntax was strictly as follows:
Code: [Select]
(obj).variable = value;

If GM is suddenly allowing that sort of thing, I will remove all checks related to assignment operators. That will add compatibility with stream structures like cout, anyway.

Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 28, 2011, 12:41:44 AM »
Someone verify that and then bug me or Ism about it.

Proposals / Re: do-until
« on: January 28, 2011, 12:41:01 AM »
It should work.
#define until(x...) while(!(x)) is all I do.

I'll look into it all the same.

Edit: I don't see where you got that it doesn't work. If it gets past the syntax check (which it does) there's no reason for it not to work.

Off-Topic / Re: Automatic code formatting
« on: January 28, 2011, 12:36:15 AM »
Select the code formatter from the Plugins menu.