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 »
1951
Proposals / Re: LGM-ENIGMA options panel.
« on: May 20, 2010, 08:51:14 am »
Without doubt, versioning will be easier with any sort of directory/archive based "format." Extensibility will also be increased. Now, each approach has some different problems. I've gradated these here:
Storing as a Directory:
This is a radical approach that will make copying and sharing tedious. Copying a directory makes the kernel iterate file hierarchy, which there doesn't seem to be a good platform at doing. The alternative is to zip the file yourself, which can be time consuming. The benefit is that the IDE or user can use their own compression scheme, and manipulating resources becomes faster and relatively infallible. Version control would be operable immediately at the push of a button. Selecting the file to load in ENIGMA could be a pain in the ass unless a manifest file is configured: it would just be a directory with an extension; how would ENIGMA know if you just wanted to explore it or if you wanted to explore it?
I would like to propose a solution, part of which I implied in that paragraph. When exploring for a file to open, LGM/the IDE could check for a file called EGMmanifest.egm. If found, it reads it for version, and if the version is sane, it opens it or errors that it is too new/old. Otherwise it just opens the directory. Problem with this is, it would take a lot of work (at least in the APIs with which I am familiar) to specify that behavior when exploring directories. Perhaps Java makes that easier.
That introduces the problem of associating ENIGMA projects with ENIGMA. When you double click a GMK, you get Game Maker. Causing that on Windows/Linux would be a hack at best. For that, I propose that double clicking the .EGM manifest will open the file in ENIGMA. To enable this with mime types, the file could be prefixed with EGM as the first line by standard. Thus, to open their project, users would double click the directory, then double click the manifest. Relatively painless, but somewhat annoying after time, especially with orphaned folder windows.
Storing as a Zip Archive:
This has worked for Java for executables for a long time. Not a lot needs written to a Jar at runtime, if anything, but the functionality is out there. This could make writing slow; the question is whether it would be slower than GM's method of packing everything each and every save. Logically, how could it be? But we've yet to see. Association becomes a real prick on Linux, as Linux doesn't care that the extension is a Jar, it sees the ZIP magic number at the beginning of the file. So Linux users would have to Right Click->Open With->LateralGM. Windows users could just double click though, which is who we're really concerned about not offending with trivial tasks.
Sharing would be fast and easy. Versioning would be kind of a pain in the ass, since the entire thing needs compressed, so you have to wait for that, then the versioning application gets to run on it, so you wait for that, then it gets compressed again... Depending on how often that was, I'd be annoyed.
Storing as a PNG-like format:
Basically, this avoids the above problems of file association, and takes a different approach to attaining an extensible format. This would be the most difficult for third-party applets to manipulate, as they would, unlike in the other two methods, need an understanding of a special format. It would also introduce problems for versioning amid all the plugins.
Consider that in the other two methods, versioning was ready either all the time or as soon as the file was automatically unpacked by a completely unrelated third-party compression tool (even though zip is embedded into Java's language, it still has nothing to do with ENIGMA). Here, a third party would actually have to do a little research to figure out how to open the file.
Plugins would need a method not only for writing and reading their extension from the file, but for unpacking to a directory for versioning, which is just an example of a functionality that someone may wish to implement that would be lost because individual plugins would have to be designed around it: If the plugin wasn't built to support versioning or numerous other functionalities brought to the table by other plugins, then it simply never will unless the author of the versioning plugin or X new plugin specifically codes a method for all the extensions. In case the sheer amount of information in that paragraph made my meaning unclear, I am saying that coordination between formats that are entirely plugin-dependent can be difficult for a new, unrelated plugin.
Also, the "reading" part of this format is likely to get messy due to Ism having no way of knowing (as far as I can tell) how they (plugin/extension programmers, though they don't exist) label their extensions to the format. Not to mention that the order of plugin loading is likely to change from instance to instance of installed versions, so Ism can't just iterate the plugins asking if this is their work: they could be called prematurely. Basically, Ism would have to make calls to each plugin who has registered itself as a format editor to ask, "Is this your doing? If so, undo it." These methods would all be called (until one fessed up to it) on every extension.
Storing as a Directory:
This is a radical approach that will make copying and sharing tedious. Copying a directory makes the kernel iterate file hierarchy, which there doesn't seem to be a good platform at doing. The alternative is to zip the file yourself, which can be time consuming. The benefit is that the IDE or user can use their own compression scheme, and manipulating resources becomes faster and relatively infallible. Version control would be operable immediately at the push of a button. Selecting the file to load in ENIGMA could be a pain in the ass unless a manifest file is configured: it would just be a directory with an extension; how would ENIGMA know if you just wanted to explore it or if you wanted to explore it?
I would like to propose a solution, part of which I implied in that paragraph. When exploring for a file to open, LGM/the IDE could check for a file called EGMmanifest.egm. If found, it reads it for version, and if the version is sane, it opens it or errors that it is too new/old. Otherwise it just opens the directory. Problem with this is, it would take a lot of work (at least in the APIs with which I am familiar) to specify that behavior when exploring directories. Perhaps Java makes that easier.
That introduces the problem of associating ENIGMA projects with ENIGMA. When you double click a GMK, you get Game Maker. Causing that on Windows/Linux would be a hack at best. For that, I propose that double clicking the .EGM manifest will open the file in ENIGMA. To enable this with mime types, the file could be prefixed with EGM as the first line by standard. Thus, to open their project, users would double click the directory, then double click the manifest. Relatively painless, but somewhat annoying after time, especially with orphaned folder windows.
Storing as a Zip Archive:
This has worked for Java for executables for a long time. Not a lot needs written to a Jar at runtime, if anything, but the functionality is out there. This could make writing slow; the question is whether it would be slower than GM's method of packing everything each and every save. Logically, how could it be? But we've yet to see. Association becomes a real prick on Linux, as Linux doesn't care that the extension is a Jar, it sees the ZIP magic number at the beginning of the file. So Linux users would have to Right Click->Open With->LateralGM. Windows users could just double click though, which is who we're really concerned about not offending with trivial tasks.
Sharing would be fast and easy. Versioning would be kind of a pain in the ass, since the entire thing needs compressed, so you have to wait for that, then the versioning application gets to run on it, so you wait for that, then it gets compressed again... Depending on how often that was, I'd be annoyed.
Storing as a PNG-like format:
Basically, this avoids the above problems of file association, and takes a different approach to attaining an extensible format. This would be the most difficult for third-party applets to manipulate, as they would, unlike in the other two methods, need an understanding of a special format. It would also introduce problems for versioning amid all the plugins.
Consider that in the other two methods, versioning was ready either all the time or as soon as the file was automatically unpacked by a completely unrelated third-party compression tool (even though zip is embedded into Java's language, it still has nothing to do with ENIGMA). Here, a third party would actually have to do a little research to figure out how to open the file.
Plugins would need a method not only for writing and reading their extension from the file, but for unpacking to a directory for versioning, which is just an example of a functionality that someone may wish to implement that would be lost because individual plugins would have to be designed around it: If the plugin wasn't built to support versioning or numerous other functionalities brought to the table by other plugins, then it simply never will unless the author of the versioning plugin or X new plugin specifically codes a method for all the extensions. In case the sheer amount of information in that paragraph made my meaning unclear, I am saying that coordination between formats that are entirely plugin-dependent can be difficult for a new, unrelated plugin.
Also, the "reading" part of this format is likely to get messy due to Ism having no way of knowing (as far as I can tell) how they (plugin/extension programmers, though they don't exist) label their extensions to the format. Not to mention that the order of plugin loading is likely to change from instance to instance of installed versions, so Ism can't just iterate the plugins asking if this is their work: they could be called prematurely. Basically, Ism would have to make calls to each plugin who has registered itself as a format editor to ask, "Is this your doing? If so, undo it." These methods would all be called (until one fessed up to it) on every extension.
1952
Announcements / Re: Fixed those Makefiles
« on: May 20, 2010, 08:16:05 am »
luis, flexaplex:
Mark decided he'd take a different approach to the woeful inadequacy of computers' floating point capabilities. While it is true that most languages cannot correctly compare fifths/tenths added together (it is a repeating decimal in binary and therefore can not be represented in a single string of bits of any size), or that sin(pi) == 0 (it's actually 1.2246063538223773e-16), Mark decided that GM should have that capability. That being the case, he made his comparison operators not compare the entire double.
If GM evaluates 1.0000000000001 > 1 as false, Mark is an idiot. ENIGMA will evaluate 1.0000000000001 > 1 and 1.000000000000001 > 1 as true, 1.0000000000000001 > 1 as false. This is because 1.0000000000000001 is simply outside the precision of a floating point value. In actuality, both ENIGMA and GM will store more bits of precision than they check, which is all the solution really needs at this point.
Because of this, I was going to replicate the behavior in ENIGMA by casting to float before comparisons. IEEE tells us that this isn't as simple as just chopping off a large part of the significand, since doubles implement larger exponents as well. But I'm assuming FPUs have a special path just for the occasion.
Mark decided he'd take a different approach to the woeful inadequacy of computers' floating point capabilities. While it is true that most languages cannot correctly compare fifths/tenths added together (it is a repeating decimal in binary and therefore can not be represented in a single string of bits of any size), or that sin(pi) == 0 (it's actually 1.2246063538223773e-16), Mark decided that GM should have that capability. That being the case, he made his comparison operators not compare the entire double.
If GM evaluates 1.0000000000001 > 1 as false, Mark is an idiot. ENIGMA will evaluate 1.0000000000001 > 1 and 1.000000000000001 > 1 as true, 1.0000000000000001 > 1 as false. This is because 1.0000000000000001 is simply outside the precision of a floating point value. In actuality, both ENIGMA and GM will store more bits of precision than they check, which is all the solution really needs at this point.
Because of this, I was going to replicate the behavior in ENIGMA by casting to float before comparisons. IEEE tells us that this isn't as simple as just chopping off a large part of the significand, since doubles implement larger exponents as well. But I'm assuming FPUs have a special path just for the occasion.
1953
Announcements / Re: Fixed those Makefiles
« on: May 19, 2010, 06:56:25 pm »
Scratch that. As it happens, sin(180*pi/180) = 1.2246063538223773e-16.
GM implemented a threshold for such in its == operators. I guess ENIGMA will have to do the same. Morbidly disappointing, really.
GM implemented a threshold for such in its == operators. I guess ENIGMA will have to do the same. Morbidly disappointing, really.
1954
Announcements / Re: Fixed those Makefiles
« on: May 19, 2010, 05:34:04 pm »
Well, mod is easily fixed by--and this needs done soon anyway--creating a file of syntax quirks and in it placing #define mod %. I will do that soon enough; but it won't work for everything because the syntax checker doesn't actually unroll macros yet, even though everything else does.
I'm not sure what's causing your other bugs, Ism, if they are bugs at all. We'll check the outputted C++ next we talk.
I'm not sure what's causing your other bugs, Ism, if they are bugs at all. We'll check the outputted C++ next we talk.
1955
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*
1956
General ENIGMA / Re: So GitHub has (experimental) SVN support now...
« on: May 19, 2010, 08:20:57 am »
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.
1957
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.
1959
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.
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.
1960
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.
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.
1961
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*
*scrambles to gather functions that have been coded but not included with ENIGMA*
1962
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.
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.
1963
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.
1964
Announcements / Re: Updates, Updates, Updates on the way.
« on: May 17, 2010, 04:07:53 pm »Code: (cpp) [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 [snip=cpp]for (int i = 0; i < 10; i++)[/snip] 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.
1965
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
The little bastards. :3
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 »