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 »
1966
Announcements / Re: Updates, Updates, Updates on the way.
« on: May 17, 2010, 03:34:48 pm »
I was thinking that to reduce sever load it'd be a good idea to keep a generated copy of the page which could be refreshed by forum admins if the database is updated from an outside source.
Anyway, trouble is that BBParser I wrote is old and doesn't use SMF's style; it uses its own unique tag system. Nice thing is that it highlights code and has an inline code tag. If only the two could just be merged...
Anyway, trouble is that BBParser I wrote is old and doesn't use SMF's style; it uses its own unique tag system. Nice thing is that it highlights code and has an inline code tag. If only the two could just be merged...
1967
Announcements / The Saga Continues
« on: May 16, 2010, 09:54:29 pm »
I'm pleased to inform that Makefiles now work, themselves, exactly as I intended them to. I had some trouble getting them to work on Windows, but now it's looking good. I've renamed some of them to use the "proper" case. The rest will follow in their own time.
I have two computers in front of me. One is about seven years old and runs a single core, 2.9 GHz. It compiles and runs in roughly 5 seconds.
My other is a much more recent lap top. Roughly a year old, dual core, 2.88. It compiles and runs the game in about 2 seconds by my stopwatch (2.07, actually, thanks for asking).
Anyway, those are basically pointless statistics. I encourage users to check out 224 and test it for themselves. I'll be doing a couple important things next, in this order:
1. Add sprites to the exe again.
1.5. Deal with the series of adversities resulting from that move on both operating systems.
2. Replace var with my stagnating recode.
3. Replace instance system with my semi-documented second version. This will implement depth and hopefully heredity.
4. Reincorporate macros and scoping into the syntax check, as well as replacing operators := and <> (begin and end will be macros).
4.5. With the new instance system in, incorporate event behaviors, default events and event prefixes (such as alarm behaviors, default draw event [draw_sprite] and force calculations at the beginning of step).
5. Backgrounds from sprites.
6. ? ? ? ?
7. Profit? Just release? I don't know. Maybe I'll move on to sounds and leave the project in the SVN, maybe I'll make the testing phase more public by bringing the project out of the SVN.
There's not been a better time to check out the SVN than now (Yes, it's only getting better from here, I hope). If you do not know how, refer to old topics or ask here.
Please report all problems, however minor, preferably here until we've a bugtracker.
Furthermore, I should mention that I believe the new instance system will further lessen compile time. A schematic will be posted when one is available.
One last thing. If anyone who has checked out previously on Windows has trouble compiling, I recommend deleting your old makefiles and checking out the new ones. Windows and its SVN clients are... odd about that. To say the least. I suppose this goes for Linux fans, too, but it's unnecessary as make never tries to execute comment lines on Linux.
I have two computers in front of me. One is about seven years old and runs a single core, 2.9 GHz. It compiles and runs in roughly 5 seconds.
My other is a much more recent lap top. Roughly a year old, dual core, 2.88. It compiles and runs the game in about 2 seconds by my stopwatch (2.07, actually, thanks for asking).
Anyway, those are basically pointless statistics. I encourage users to check out 224 and test it for themselves. I'll be doing a couple important things next, in this order:
1. Add sprites to the exe again.
1.5. Deal with the series of adversities resulting from that move on both operating systems.
2. Replace var with my stagnating recode.
3. Replace instance system with my semi-documented second version. This will implement depth and hopefully heredity.
4. Reincorporate macros and scoping into the syntax check, as well as replacing operators := and <> (begin and end will be macros).
4.5. With the new instance system in, incorporate event behaviors, default events and event prefixes (such as alarm behaviors, default draw event [draw_sprite] and force calculations at the beginning of step).
5. Backgrounds from sprites.
6. ? ? ? ?
7. Profit? Just release? I don't know. Maybe I'll move on to sounds and leave the project in the SVN, maybe I'll make the testing phase more public by bringing the project out of the SVN.
There's not been a better time to check out the SVN than now (Yes, it's only getting better from here, I hope). If you do not know how, refer to old topics or ask here.
Please report all problems, however minor, preferably here until we've a bugtracker.
Furthermore, I should mention that I believe the new instance system will further lessen compile time. A schematic will be posted when one is available.
One last thing. If anyone who has checked out previously on Windows has trouble compiling, I recommend deleting your old makefiles and checking out the new ones. Windows and its SVN clients are... odd about that. To say the least. I suppose this goes for Linux fans, too, but it's unnecessary as make never tries to execute comment lines on Linux.
1968
Proposals / Re: Tiering vs Components
« on: May 16, 2010, 08:13:08 pm »
Polygone: There's a new resource for C++ scripts. ENIGMA's backwards compatibility with GML will be more than sufficient to write a script in it, don't worry. It wouldn't be that difficult, but still, I'd rather not if it doesn't become a problem.
1969
Proposals / LGM-ENIGMA options panel.
« on: May 16, 2010, 08:04:21 pm »
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.
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.
1970
Proposals / Re: Tiering vs Components
« on: May 16, 2010, 07:12:02 pm »
Sticky how? My proposal for object_event_add was V8; Luda believes he could write a faster JIT compiler with the more focused purpose of interpreting GML; problem is the experience factor. Luda's a talented individual; so's serp, and I like to think I am, but I'm not sure how we'd fare against the abilities of V8's team, even with a vastly simpler language. Really, I'm still quite open to suggestions on that matter. I will probably code something that generates the backend of an interpreter for games, and I know exactly how that will be done, but the front end is still completely subject to debate.
I should, in fact, forward two proposals on this forum that are somewhat related to the matter.
Things aren't really sticky with bringing in C++ features, though; we're using a C++ compiler. All I have to do is understand the syntax enough to ignore it; to check that everything in <> is a type or simple value, and that all (t*)<(.*)> are replaced with t(.*) of equal size, and templates are introduced. Then I need a pass to get members of event-declared structures, then one to resolve all "a.b" in light of the new information. It's little more than I have to do to support globalvar (Which will end up as a macro to global var). The only aspect I really have to go out of my way for is the scope resolution operator, ::. But I'll recover.
I should, in fact, forward two proposals on this forum that are somewhat related to the matter.
Things aren't really sticky with bringing in C++ features, though; we're using a C++ compiler. All I have to do is understand the syntax enough to ignore it; to check that everything in <> is a type or simple value, and that all (t*)<(.*)> are replaced with t(.*) of equal size, and templates are introduced. Then I need a pass to get members of event-declared structures, then one to resolve all "a.b" in light of the new information. It's little more than I have to do to support globalvar (Which will end up as a macro to global var). The only aspect I really have to go out of my way for is the scope resolution operator, ::. But I'll recover.
1972
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 04:45:15 pm »
Oh, that was just one of the 600 problems I've encountered on the way. Indented comments were executed; that was a more recent one.
The one I'm dealing with now is that parameters work differently on Windows. make GRAPHICS=OpenGL doesn't work anymore.
The one I'm dealing with now is that parameters work differently on Windows. make GRAPHICS=OpenGL doesn't work anymore.
1973
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 02:16:12 pm »
You forgot the
Also, that's why "Compile" lets you choose the full filename. The 'exe' is meant for ENIGMA to run/work with.
Also, that's why "Compile" lets you choose the full filename. The 'exe' is meant for ENIGMA to run/work with.
1974
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 02:07:11 pm »
As a matter of fact, Linux is the only OS they work on at the moment, because Windows can't call make. ^_^
System() can't parse the program name from the arguments.
CreateProcess() can't find mingw32-make.
So really, it only works on Linux at the moment.
Makefile is given priority over makefile; other than that, either is fine.
Only one makefile should be outputting an exe, and it's the one under SHELL. Windows will only run EXE, Linux will run anything given --e permissions. So I used exe.
System() can't parse the program name from the arguments.
CreateProcess() can't find mingw32-make.
So really, it only works on Linux at the moment.
Makefile is given priority over makefile; other than that, either is fine.
Only one makefile should be outputting an exe, and it's the one under SHELL. Windows will only run EXE, Linux will run anything given --e permissions. So I used exe.
1975
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 12:21:57 pm »
The splash screen doesn't display here; I assumed you'd removed it.
1976
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 09:31:15 pm »
Well, it's an irremovable part of ENIGMA's philosophy. And it's a bit late to fork the project over it. If you don't like it, you don't like ENIGMA, and you probably don't belong here.
1977
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 08:25:19 pm »
In the case that it is declared as "local int", "local string", or what have you, in a later event, which could be considered bad practice, but it seems asinine to disallow that over the minuscule amount of work taken to support it.
1978
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:55:06 pm »
COBOL did work fine, then we found something better.
Hey, go find something better.
Don't give me "lots and lots" bullshit; I can enumerate every inconsistency with the languages and what's been done about it. There are roughly five. Holding lexed code to determine what type an object is before acting on it isn't one of those inconsistencies.
Hey, go find something better.
Don't give me "lots and lots" bullshit; I can enumerate every inconsistency with the languages and what's been done about it. There are roughly five. Holding lexed code to determine what type an object is before acting on it isn't one of those inconsistencies.
1979
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:46:05 pm »
I recall no such people.
C++ isn't a problem with the architecture; clearly it's working fine. Just not with your proposal. This doesn't agree with your idea of what I should be doing, so you see it as a problem.
C++ isn't a problem with the architecture; clearly it's working fine. Just not with your proposal. This doesn't agree with your idea of what I should be doing, so you see it as a problem.
1980
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:42:43 pm »
Great ad hominem. Is there an argument to go with it?
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 »