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 »
2731
Announcements / Re: ENIGMA -- srs bizness
« on: November 25, 2008, 06:43:21 pm »
Since the game wouldn't compile if there were any truly undefined variables, they just don't exist in ENIGMA. So here, undefined means that you didn't say varname=something; before you said if(varname) or function(varname).
2732
Announcements / Re: ENIGMA -- srs bizness
« on: November 23, 2008, 06:04:01 pm »
Whew. For a minute there I was afraid everyone'd be like ZOMG NO DUN HURT OUR PRESHIS ERRORZ
2733
Issues Help Desk / Re: NOOB QUESTION!
« on: November 23, 2008, 05:04:26 pm »
I was never good at writing help files and readme's. *shrugs*
Either way, yeah, 3D should be far more extensible than GM, since there'd be no overhead from calling a DLL, which you'd have to do in GM.
Either way, yeah, 3D should be far more extensible than GM, since there'd be no overhead from calling a DLL, which you'd have to do in GM.
2734
General ENIGMA / Re: I think that you'll be pleased to know
« on: November 23, 2008, 05:00:38 pm »
NAWT FAIR. I want an imaginary name to go along with my imaginary program! D:
Oh wait, ENIGMA has screen shots and releases.... Never mind.
Oh wait, ENIGMA has screen shots and releases.... Never mind.
2735
General ENIGMA / Re: Enigma/GM, different code?
« on: November 23, 2008, 09:49:40 am »Or rather, "Will be some time in about, say, a year and a half or so".
Sounds about right. I see what you mean, you want it for temporary use.
Hmm...
I don't wanna defile comments, but I guess I could easily do it. Again, I'll think about it. (Probably a yes)
2736
Announcements / ENIGMA -- srs bizness
« on: November 23, 2008, 08:50:26 am »
As some of you fantasize in your over-idealistic views of ENIGMA, I'm doing my very best to make sure ENIGMA runs as efficiently as possible.
It's always a tear between memory and speed: with enough memory, you can make anything efficient.
Anyway, it's been trial and error. Here's an example of error:
Sprites, to date, have been kept in an std::map for storage. This way, if you have 2 sprites with sprite id's of 64 and 256, you only store two sprites worth of memory. That's a best-case scenario, though.
More often, you have some 8 sprites, all in order, and the lookup time for each sprite totally outweighs the benefit.
Other times you have a slower system that makes error reporting possible. Like when you try to create a nonexisting object, you get a friendly reminder that it doesn't exist.
So from now on, here's how it's going to be:
Everything in ENIGMA is going to be well oiled, but if you, say, request a non-existing sprite, the game will just die. No errors, no nothing. To get the errors, you will have to run the game in debug mode, in which the game will run far less efficiently, but will report any such silly errors.
This way, your end result will be a much, much faster game, but will be expected to have basically no errors at all.
(Honestly, would you release a game that still had errors in it?)
So let me put it simply.
If I do this, the end result will likely be around 10x faster, give or take. However, If an error would result in a segmentation fault, (C++ terminology for 'nasty error caused by memory access violations that kills the program without warning') your game will end without displaying any error messages or anything. (See list below for typical errors)
This harsh reaction, however, will only apply in release mode; debug mode will report any such errors and continue to run the game.
So if you're developing the game, you should be running it in debug mode pretty much the whole time, using build/run mode only after all the errors are out, either to verify final speed or to edit your rooms.
I'd like to know if you feel it'd be worth it. I know I do, but I guess it's only fair to tell you before I implement it.
List of typical errors:
So in comparison, debug mode will be lagtastic. But it'll still be fast enough, and it'll help you get all the errors out.
I'll see what I can do as far as debugging certain things at once goes.
The system will take a lot more work, and of course space, but hopefully it gets the job done.
Send me your thoughts.
-Josh
It's always a tear between memory and speed: with enough memory, you can make anything efficient.
Anyway, it's been trial and error. Here's an example of error:
Sprites, to date, have been kept in an std::map for storage. This way, if you have 2 sprites with sprite id's of 64 and 256, you only store two sprites worth of memory. That's a best-case scenario, though.
More often, you have some 8 sprites, all in order, and the lookup time for each sprite totally outweighs the benefit.
Other times you have a slower system that makes error reporting possible. Like when you try to create a nonexisting object, you get a friendly reminder that it doesn't exist.
So from now on, here's how it's going to be:
Everything in ENIGMA is going to be well oiled, but if you, say, request a non-existing sprite, the game will just die. No errors, no nothing. To get the errors, you will have to run the game in debug mode, in which the game will run far less efficiently, but will report any such silly errors.
This way, your end result will be a much, much faster game, but will be expected to have basically no errors at all.
(Honestly, would you release a game that still had errors in it?)
So let me put it simply.
If I do this, the end result will likely be around 10x faster, give or take. However, If an error would result in a segmentation fault, (C++ terminology for 'nasty error caused by memory access violations that kills the program without warning') your game will end without displaying any error messages or anything. (See list below for typical errors)
This harsh reaction, however, will only apply in release mode; debug mode will report any such errors and continue to run the game.
So if you're developing the game, you should be running it in debug mode pretty much the whole time, using build/run mode only after all the errors are out, either to verify final speed or to edit your rooms.
I'd like to know if you feel it'd be worth it. I know I do, but I guess it's only fair to tell you before I implement it.
List of typical errors:
- Accessing an undefined sprite: Fatal, debug mode will report it
- Accessing an undefined script: Will error at compile time
- Accessing any other undefined resource: Fatal, debug mode will report it
- Going past an array limit in a VAR: Not fatal, don't think debug mode will report it though
- Going past an array limit with pointers: Just fatal. It's a C++ thing.
- Division by zero: Fatal, debug mode will report it in var, cannot report it with int/double/etc
- Nonexisting variable: Totally impossible, may implement something to track that
So in comparison, debug mode will be lagtastic. But it'll still be fast enough, and it'll help you get all the errors out.
I'll see what I can do as far as debugging certain things at once goes.
The system will take a lot more work, and of course space, but hopefully it gets the job done.
Send me your thoughts.
-Josh
2737
Announcements / Re: Progress report
« on: November 22, 2008, 05:33:04 pm »
nbeer--
Not so much as size optimization as additional speed optimization, always in the speed of the running game, but especially in compile speed. Seriously, do you see how long that thing takes?
...I've slightly improved it since R3, but this series of patches I'm working on is what's gonna push it over.
Not so much as size optimization as additional speed optimization, always in the speed of the running game, but especially in compile speed. Seriously, do you see how long that thing takes?
...I've slightly improved it since R3, but this series of patches I'm working on is what's gonna push it over.
2738
Announcements / Re: Progress report
« on: November 22, 2008, 01:07:26 pm »
Oni-- My last piece of eyecandy was 300KB stripped. (100KB zipped, 30kb 7z'd)
Retro-- Define frameskip. Just to do nothing for one step? Simple.
Retro-- Define frameskip. Just to do nothing for one step? Simple.
2739
Announcements / Re: Progress report
« on: November 21, 2008, 06:16:49 pm »
Yeah, lots of waiting going on, but like I said, still and always renovating.
Made my own instance list that will handle depth now. Currently it can insert and delete, etc; the easy things. I'm making an even lower-cost list to handle cleanups.
Made my own instance list that will handle depth now. Currently it can insert and delete, etc; the easy things. I'm making an even lower-cost list to handle cleanups.
2740
Tips, Tutorials, Examples / Re: motion_add();
« on: November 16, 2008, 04:35:50 pm »
No, assemblers assemble code. You just write it.
2741
Announcements / Progress report
« on: November 16, 2008, 09:41:36 am »
Just so you people know I'm still alive.
I've fixed a lot since R3. You'll find basically all of this on the todo page, but since many aren't aware it exists, I'm posting it here.
I also have a special surprise in store, of which I'm sure a few of you are already aware. You'll be hearing about it quite soon.
As one last thing, ENIGMA R3b shouldn't be very long either. I'm mostly waiting for Luda to finish Colligma while going back and fixing errors, at this point.
What I'm currently working on:
- Redoing instances to fix a potential problem with rooms, as well as implement depth
- Working with create events and destroy events to avoid more problems with rooms
What I've recently done:
- Added something called PCS, or "Pre/Post-compile script", which will allow you to pass parameters to GCC as well as execute functions on the exe before resources are added. This will really help with filesize and speed.
Cheers.
I've fixed a lot since R3. You'll find basically all of this on the todo page, but since many aren't aware it exists, I'm posting it here.
- I redid pretty much everything and remade the syntax file (fnames.txt). And by redid everything, I mean I went over all the code and made corrections, minor, optimizational, or otherwise.
- draw_text no longer messes up the projection.
- Variables declared in scripts now work in any object that runs the script
- room_restart() and game_end() are now implemented. I also added room_next() and room_previous(), though it should be noted room errors in enigma are not fatal. (Division by zero, however, is VERY fatal. Don't divide by zero, ...<_<
- WILDCLASS now uses pointer-to-pointer-to types. Any kind of variable can now be referenced between objects.
- The script-path tracer is fixed, scripts are totally fine now.
- The parser's treating of typenames and casts is now fixed. The system makes a lot of assumptions that my thinking suggests are safe bets 100% of the time. In case of any compile errors in the upcoming release, PLEASE inform me.
- Array indexes involving arithmetic now work. What a sad glitch I had missed.
- The window resizes as room changes.
- Room background color is no longer inverted.
- Decimals with no preceding whole integer work again.
- Window functions now actually work. I just never bothered to test them before R3.
- Build mode will no longer freeze if either of the grid dimensions is set to zero.
- Friction is now accurate.
- Sprite indexes are now initialized properly.
- Views work 100% now.
- keyboard_check... and mouse_check... now use correct types.
- Instances that skipped an id number are no longer created twice.
I also have a special surprise in store, of which I'm sure a few of you are already aware. You'll be hearing about it quite soon.
As one last thing, ENIGMA R3b shouldn't be very long either. I'm mostly waiting for Luda to finish Colligma while going back and fixing errors, at this point.
What I'm currently working on:
- Redoing instances to fix a potential problem with rooms, as well as implement depth
- Working with create events and destroy events to avoid more problems with rooms
What I've recently done:
- Added something called PCS, or "Pre/Post-compile script", which will allow you to pass parameters to GCC as well as execute functions on the exe before resources are added. This will really help with filesize and speed.
Cheers.
2743
Issues Help Desk / Re: collision_rectangle
« on: November 16, 2008, 09:16:16 am »
there was one, actually. It's in my demonstration platformer.
2744
Issues Help Desk / Re: ds_list_ functions
« on: November 16, 2008, 09:07:47 am »
ds_list was done by Rusky. I have still yet to implement it, or test it for myself.
negmod was a general replacement for % after I discovered % didn't take doubles, and had trouble with negatives or something.
Either way, it's basically just (char) & 0xFF now.
negmod was a general replacement for % after I discovered % didn't take doubles, and had trouble with negatives or something.
Either way, it's basically just (char) & 0xFF now.
2745
Issues Help Desk / Re: A replacement for draw_text
« on: November 16, 2008, 09:05:35 am »
It's there in R3, assuming it functions. Does it...?
Check if it's on my list of corrected bugs in R3b
Check if it's on my list of corrected bugs in R3b
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 »