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 »
2356
Announcements / Re: Rejoice
« on: February 23, 2010, 05:21:34 pm »
BAHAHAHAHAHAHAHAHAHAHHAHAHAHA
How'd the documentation for that look?
How'd the documentation for that look?
2357
Announcements / Re: Rejoice
« on: February 23, 2010, 05:17:23 pm »
Oh yes, that's funny. I'm dyslexic, asshole. ...haha.
Fine, maybe I just can't spell old dead people.
Fine, maybe I just can't spell old dead people.
2358
Announcements / Re: Rejoice
« on: February 21, 2010, 12:38:37 pm »Quote
Well, I meant more like being able to check functions only in certain moments where the user would want it using the functions, hopefully without too major speed loss. E.g. you could call "error_start()" to start being error checking session and "error_stop()" to stop it, or perhaps "error_object(obj, true)" to check for errors that occur within a certain object and "error_object(obj, false)". Just suggesting...
The former (error_start) leaves two options.
1) Have an if() to check if it's enabled, which wastes the same a mount of time as just doing the damn error checking
2) Use function pointers that can be swapped on error_start(), which removes any chance of inlining.
The latter (error_object) is a terrible idea by any standard. Now instead of one if(), we're looking up whether we are supposed to be generating errors for that object in a... map? Array? Either of them are awful in one way or another (map's lookup time, array's allocation time).
I'd be better off just leaving the errors than to add functions for them, but I'd rather not have them when they aren't needed.
2359
Issues Help Desk / Re: A replacement for draw_text
« on: February 20, 2010, 11:09:09 pm »
The GM6 doesn't store font glyphs as bitmap, they store it by font name. EXE stores the bitmaps.
2360
Announcements / Re: Rejoice
« on: February 20, 2010, 11:00:32 pm »
A bounds check every time a sprite is drawn? That's just one of them that really sticks in my mind. I might prevent the untimely death of the game by modding the index by the number of sprites, but aside from that... Hell, I wouldn't even just mod it. I'd waste another ((1 << ceil(log2(sprite_count))) - sprite_count) * sizeof(sprite_struct*) bytes (as in, wrap the sprites to a greater power of two) and use an & instead.
It's the little, "oh, this won't really hurt anything" ideas that end up in projects behaving like GM. "Oh, all those local variables are negligible." "Oh, using a map to store array elements won't slow anything." Whatever I can save, I will, or it'll all build up into slow gunk.
Also, score_, I'm not sure if all structs are compile-only in the sense that they will not affect size if unused. I'm thinking vtables might be stored regardless (Not a C thing).
It's the little, "oh, this won't really hurt anything" ideas that end up in projects behaving like GM. "Oh, all those local variables are negligible." "Oh, using a map to store array elements won't slow anything." Whatever I can save, I will, or it'll all build up into slow gunk.
Also, score_, I'm not sure if all structs are compile-only in the sense that they will not affect size if unused. I'm thinking vtables might be stored regardless (Not a C thing).
2361
Issues Help Desk / Re: A replacement for draw_text
« on: February 20, 2010, 12:53:20 pm »Quote
GM's loading screen cannot be eliminated by compilation. What on earth gave you that idea?The fact that at present, ENIGMA doesn't have one. Most things that compile in ENIGMA have presently not been big enough to have a noticeable load time, so no one has really missed a loading bar. That will likely change in the future, so I'll have to install one that's on by default. Click the Clown should never require a loading bar. <_<"
And no, Game Maker uses the font the game was compiled with, whether it exists on the new computer or not.
2362
Announcements / Re: Rejoice
« on: February 20, 2010, 10:15:42 am »
Game_Boy--
Precisely.
Everyone else--
Listen to Game_Boy.
@"Perhaps you could implement a function set ... to make his/her application look out for errors"
The point of removing error checking is to save on multiple ifs each call. That's part of the reason GM is slow; the runner can never be recompiled to your needs. I would be no more happy to find that a user of my finished game had it throw an error on them (especially one that could be ignored) than to find that it had just acted funny or died (in the case that ignoring the error was inevitable).
@"you/the team has to work more on the error messages"
That's been a goal since the beginning.
Precisely.
Everyone else--
Listen to Game_Boy.
@"Perhaps you could implement a function set ... to make his/her application look out for errors"
The point of removing error checking is to save on multiple ifs each call. That's part of the reason GM is slow; the runner can never be recompiled to your needs. I would be no more happy to find that a user of my finished game had it throw an error on them (especially one that could be ignored) than to find that it had just acted funny or died (in the case that ignoring the error was inevitable).
@"you/the team has to work more on the error messages"
That's been a goal since the beginning.
2363
Announcements / Re: Rejoice
« on: February 19, 2010, 09:20:49 pm »
luis--
All the object data is in one file, but built-in functions are in many, many different files.
plague--
I'm hoping so.
Rusky--
It would be a great option if the team guaranteed its readiness. Until then, I'll stick with what I've worked on.
Retro--
I've not found such a flag, but I'd think there is one.
I will definitely need such a test done. The time will come for that.
All the object data is in one file, but built-in functions are in many, many different files.
plague--
I'm hoping so.
Rusky--
It would be a great option if the team guaranteed its readiness. Until then, I'll stick with what I've worked on.
Retro--
I've not found such a flag, but I'd think there is one.
I will definitely need such a test done. The time will come for that.
2364
Issues Help Desk / Re: A replacement for draw_text
« on: February 19, 2010, 11:11:46 am »
Retro:
That's when decryption is done and trees are generated.
a2h:
I'm not sure why that's the case. Maybe he does the smoothing himself. O_o
That's when decryption is done and trees are generated.
a2h:
I'm not sure why that's the case. Maybe he does the smoothing himself. O_o
2365
Announcements / Re: Rejoice
« on: February 19, 2010, 11:07:54 am »
Anymore i think you're sharing these things just to have something to share. "When its C++ support is a little more mature"? When the hell is that? Should I just wait for them to figure out what they're doing? Mine took a while, but it's done now (or as done as it needs to be). Let me know when Clang is more... mature.
As for "quite fast," it was used in lieu of a number. It meant "much faster than R3 as far as can presently be discerned." Though one object in each file would be nice (and doable) if LGM kept track of which objects were modified since last compile, I don't believe it does, so there isn't much point to putting them in separate files at the moment (I'll ask Ism about it next I see her, actually).
As for "quite fast," it was used in lieu of a number. It meant "much faster than R3 as far as can presently be discerned." Though one object in each file would be nice (and doable) if LGM kept track of which objects were modified since last compile, I don't believe it does, so there isn't much point to putting them in separate files at the moment (I'll ask Ism about it next I see her, actually).
2366
Announcements / Rejoice
« on: February 18, 2010, 11:33:14 pm »
Everything I wanted to work at this juncture works now. It's almost bittersweet; the teeth-grating hard part is seemingly over.
There is a problem, though. Typical student-made C lexers take upwards of minutes to parse the STL headers. I figured since I didn't need much of the data a compiler needs, I could do a lexless run-over to gather desired information, thus saving oodles of time. Well, it worked, but not well enough. On average processor load on my pretty average computer, parsing all the STL headers takes between one and two seconds. The latest result being 1.53662. Honestly, it's nothing to cry about, but this means I shouldn't just parse this stuff each compile, meaning Ism and I have to work something out to have LGM load ENIGMA as a DLL. This way, it will be able to retain such information.
I had typed up a report of what comes next on the school computers, but those have lately been failing to post here. I guess I'll summarize:
- As soon as I have access to a Windows box, I will reparse the STL headers on it, and then test windows.h to make sure it works (I have no doubt that it will). I also need to test the GL headers.
- Development will need to be carried out on said Windows device for a few cycles. This is because I assume said device (the one I have picked out) is 64 bit. Serprex had some problems with 64 bit machines in the past; I need to be sure they do not persist.
- Speaking of serp, I need his version of the system. He has been optimizing it for a while now. This will probably all be done inside tomorrow.
- Since the development of ENIGMA's parser, a new GM format has been released, along with a new EGM File format. ENIGMA needs to be versed in this new format. The parser also needs updated to use the CFile parser's list instead of the small list of built-ins I used to keep. This is a large step on the road to full extensibility.
And speaking of extensibility, with it come implications. Logically, I can't optimize for run speed, compile time, and output size all at once. So, here's what seems to be destined:
Other optimizations become difficult to describe and list due to number and insignificance (they only add up in the long run). Not to mention I'm really tired.
Before I go though, I should elaborate on the implications of having removable systems.
Each of ENIGMA's systems is designed now to be optional. Since R3, when compile time was too high, these groups of related functions have been divided into individual source files. The problem with doing so is that many files in ENIGMA are highly interdependent. Many sources need a few members from instances, most often id, sprite_index, and mask_index. To give access to these variables without requiring all variables, R4 will require a super-parent, if you will, that contains only the most basic of locals. Other locals, like speed and direction, will be stored in a derived parent from which all other objects will derive. This will allow for all non-essential locals to be removed without major recompile.
*yawns* I need sleep today.
There is a problem, though. Typical student-made C lexers take upwards of minutes to parse the STL headers. I figured since I didn't need much of the data a compiler needs, I could do a lexless run-over to gather desired information, thus saving oodles of time. Well, it worked, but not well enough. On average processor load on my pretty average computer, parsing all the STL headers takes between one and two seconds. The latest result being 1.53662. Honestly, it's nothing to cry about, but this means I shouldn't just parse this stuff each compile, meaning Ism and I have to work something out to have LGM load ENIGMA as a DLL. This way, it will be able to retain such information.
I had typed up a report of what comes next on the school computers, but those have lately been failing to post here. I guess I'll summarize:
- As soon as I have access to a Windows box, I will reparse the STL headers on it, and then test windows.h to make sure it works (I have no doubt that it will). I also need to test the GL headers.
- Development will need to be carried out on said Windows device for a few cycles. This is because I assume said device (the one I have picked out) is 64 bit. Serprex had some problems with 64 bit machines in the past; I need to be sure they do not persist.
- Speaking of serp, I need his version of the system. He has been optimizing it for a while now. This will probably all be done inside tomorrow.
- Since the development of ENIGMA's parser, a new GM format has been released, along with a new EGM File format. ENIGMA needs to be versed in this new format. The parser also needs updated to use the CFile parser's list instead of the small list of built-ins I used to keep. This is a large step on the road to full extensibility.
And speaking of extensibility, with it come implications. Logically, I can't optimize for run speed, compile time, and output size all at once. So, here's what seems to be destined:
- When testing your game, it will compile quite fast. The output size will be tremendous (approaching the size of GM output as the project grows). Speed will be "decent," which is great by GM standard. Error handling will be as follows, as debated long ago:
- In regular run mode and release mode, errors will either kill you or they won't. They are not likely to be checked for.
- In debug mode, thorough checking will be done that could cause slowdown
- The jury is out on build mode.
- When compiling your game for final release, the process will take from 10 seconds to a minute. This depends not so much on your computer as on your optimization settings. C++ comes with a set of native-related optimizations, ENIGMA's most notable optimizations are to be as follows:
- Unused functions will not be included. This is possible thanks entirely to the CFile parser. [size optimization]
- Unused local variables can be removed. [memory optimization] [possibly {semi-}manual]
- Switch statements will be replaced with a type of hash map where possible. This will be another feat of mostly the C parser. [speed optimization]
Other optimizations become difficult to describe and list due to number and insignificance (they only add up in the long run). Not to mention I'm really tired.
Before I go though, I should elaborate on the implications of having removable systems.
Each of ENIGMA's systems is designed now to be optional. Since R3, when compile time was too high, these groups of related functions have been divided into individual source files. The problem with doing so is that many files in ENIGMA are highly interdependent. Many sources need a few members from instances, most often id, sprite_index, and mask_index. To give access to these variables without requiring all variables, R4 will require a super-parent, if you will, that contains only the most basic of locals. Other locals, like speed and direction, will be stored in a derived parent from which all other objects will derive. This will allow for all non-essential locals to be removed without major recompile.
*yawns* I need sleep today.
2367
Announcements / Re: Domain Name Provider Transfer
« on: February 18, 2010, 11:13:37 pm »
I know who their provider is and what their provider charges for a variety of servers. I also know their old provider, when Mark still made major decisions. I believe they were even better for this job... I don't care what they blindly wandered into.
2368
Announcements / Re: Domain Name Provider Transfer
« on: February 18, 2010, 09:59:06 pm »
Suggesting that I don't know everything Sandy and Mark do is not the fallacy; using that to suggest that my claims that they are inefficient are invalid is where the fallacy is.
2369
Issues Help Desk / Re: A replacement for draw_text
« on: February 18, 2010, 06:51:21 pm »
Both:
GM can use any sprite the *creator* has installed (it can import any sprite the end user has installed at runtime). Being able to render custom fonts is proof *something* is stored in the EXE. Transforming text causes pixelation. That means it's being stored as a bitmap before draw; whether before load time is unknown at this point. We can't prove it doesn't store the actual font file in the exe with what we know here; you'll just have to take my word for it that it is in fact part of the GM exe format. (And I know this for a fact, so unless I've been miserably mistaken for a long time...)
GM can use any sprite the *creator* has installed (it can import any sprite the end user has installed at runtime). Being able to render custom fonts is proof *something* is stored in the EXE. Transforming text causes pixelation. That means it's being stored as a bitmap before draw; whether before load time is unknown at this point. We can't prove it doesn't store the actual font file in the exe with what we know here; you'll just have to take my word for it that it is in fact part of the GM exe format. (And I know this for a fact, so unless I've been miserably mistaken for a long time...)
2370
Issues Help Desk / Re: A replacement for draw_text
« on: February 18, 2010, 07:09:43 am »
The GM way is nicer-looking, but completely incompatible with the unicode way (unless, as I assume, SFML went to the trouble of anti-aliasing their gylphs).
I can't store a sprite for each of two byte's worth of glyphs.
I can't store a sprite for each of two byte's worth of glyphs.
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 »