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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
1441
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..."
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.
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.
1442
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.
As for the GLES folder, ask TGMG. He thought it would become necessary; we haven't seen it be so yet.
1443
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.
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.
1444
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.
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.
1445
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.
1446
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.
1447
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).
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).
1448
Proposals / Re: ENIGMA Game Format
« on: January 29, 2011, 05:46:13 am »
Same as my plans for image formats. Each resource has a text file with the name and any other information that can be left text, and a reference to a binary file in the same directory. I don't have a problem with resources that would use only a binary file and a name simply having such info glued onto the beginning (we could standardize a format for that).
I won't defend YAML. Some of it is glued together. But it's much easier to parse than XML, and it's much easier to read and much harder to fuck up. Assuming INI is the format used in GNOME .desktop files, that is my secondary proposal.
Besides, I think that if the format is to earn the OGF extension, it should utilize a format that every language has a parser for, not just Python. So yeah, how's INI sound?
I won't defend YAML. Some of it is glued together. But it's much easier to parse than XML, and it's much easier to read and much harder to fuck up. Assuming INI is the format used in GNOME .desktop files, that is my secondary proposal.
Besides, I think that if the format is to earn the OGF extension, it should utilize a format that every language has a parser for, not just Python. So yeah, how's INI sound?
1449
Proposals / LateralGM extensions; official proposal
« on: January 28, 2011, 10:42:56 pm »
Once ENIGMA has its own format, it will finally be possible for it to include its own resources in outputted game files. That being the case, it is time, as Luis indicated earlier, that LGM offers a less painful method of defining custom resources.
Notice: I am in no way an expert on Java. I speak in this thread solely on authority of designing the C++ backend to potential extensions, which here is not much authority at all. My suggestions are to be taken not as a suggestion for the Java code behind the mechanism, but as the overall concept of the goals thereof.
That said, I think we should first define the goals simply in terms of what has been shown to be needed thus far (namely, by Luis's "Panes" extension proposal and my "Libraries" proposal which will conclude this message).
Before that, terms. For the purpose of this message (feel free to adopt them for your own), the following lexicons will be used:
"Loader" refers to the mechanism which will load extensions to the LateralGM interface.
"Extension" refers to a single unspecified object the Loader is loading.
"Component" refers to an interface element, such as a button or a graphic.
"Node" refers to a resource tree Component.
"MDI" refers to whatever the fuck that Java thing is that houses all the other editor windows.
I have not decided how the C++ backend should be extended, aside from that it must share a list of extension IDs.
What I have decided on is a new resource that will be added, in addition to Panes. R4's introduction called for a resource dubbed "Whitespace" and renamed to "Definitions." Both names suck. I now propose that this be a tabbed, C-code resource, basically offering what simple C IDE's offer (tabs and a code editing pane with simple features).
This proposal is likely incomplete, but I have work tomorrow and should be sleeping. Comments welcome. Comments from Java programmers especially welcome.
Notice: I am in no way an expert on Java. I speak in this thread solely on authority of designing the C++ backend to potential extensions, which here is not much authority at all. My suggestions are to be taken not as a suggestion for the Java code behind the mechanism, but as the overall concept of the goals thereof.
That said, I think we should first define the goals simply in terms of what has been shown to be needed thus far (namely, by Luis's "Panes" extension proposal and my "Libraries" proposal which will conclude this message).
Before that, terms. For the purpose of this message (feel free to adopt them for your own), the following lexicons will be used:
"Loader" refers to the mechanism which will load extensions to the LateralGM interface.
"Extension" refers to a single unspecified object the Loader is loading.
"Component" refers to an interface element, such as a button or a graphic.
"Node" refers to a resource tree Component.
"MDI" refers to whatever the fuck that Java thing is that houses all the other editor windows.
- The Loader must allow the addition of a Node or group of Nodes (represented by a folder) into the resource tree.
- The Plugin must be informed when a tree Node under its control is double clicked. (original proposal said this job was the Loader's)
- Each extension will be responsible for tracking its own data and creating its own UI elements in the passed MDI context.
- Each Extension will be given the opportunity to save or load its data when the rest of the game is doing so.
- Extensions will be given a method of identifying themselves as being instantiable in other resources
- Take, for example, a 3D mesh resource. It would inherit from a class that can be assigned to a GM object as one assigns a sprite or mask.
- An Extension that can be instantiated in room will be allowed to be placed multiple times, visually.
- Such an Extension should provide a method to obtain bounding box information for placement and clipping, as well as a method to render itself in the room.
- Extensions that can be instantiated in GM objects should provide a method of obtaining an iconic preview, as sprites do.
- Extensions must be able to supply a unique ID and a C-structured or easily restructured dump of relevant data to the output executable. If the ID is not unique, backend plugins (Namely, ENIGMA) will be unable to determine what structure they are looking at, resulting in undefined behavior (like segfault). The data must obviously be easily structured per the C spec (like POD) so that ENIGMA can work with them.
- A method must be provided of accessing any complicated UI Components to the Extensions (Namely, the JEdit class and the GML syntax highlighting context, which should be easily extended or swapped out in a specific JEdit instance). (original proposal said this job was the Loader's)
I have not decided how the C++ backend should be extended, aside from that it must share a list of extension IDs.
What I have decided on is a new resource that will be added, in addition to Panes. R4's introduction called for a resource dubbed "Whitespace" and renamed to "Definitions." Both names suck. I now propose that this be a tabbed, C-code resource, basically offering what simple C IDE's offer (tabs and a code editing pane with simple features).
This proposal is likely incomplete, but I have work tomorrow and should be sleeping. Comments welcome. Comments from Java programmers especially welcome.
1450
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, andI'll call you a trollwe'll have a reasonable debate.
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
1451
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.
1453
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.
1454
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:
So it became a question of how messed up I wanted to allow the syntax to be.
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.
1455
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.
You can stick a cast anywhere in an expression you like in ENIGMA. Just like ++, or !. Casts are just another unary operator.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »