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 »
2701
Announcements / Re: Merry Christmas
« on: December 28, 2008, 03:53:39 pm »
I'll typedef self and local to this, global to actual global structure, and I guess noone can stay -1.
2702
Announcements / Re: Merry Christmas
« on: December 28, 2008, 03:36:10 pm »
because this is C++. I'm not just changing a word around, I'm removing all the time wasted by having id and self meaningless numbers like 100001 and -3.
2703
Announcements / Re: Merry Christmas
« on: December 28, 2008, 01:42:09 pm »
Actually this and id, but yeah.
Since ID is just a number from 100001 up, using it involves looking up an instance in a list. For best results, I'd use a regular linked list and use this to identify objects.
'Other programs' use something along the lines of a map, I'm sure, and use the map's amazing lookup prowess to find the instance, instead of just being able to say "There it is!" like using this would allow me to do.
Since ID is just a number from 100001 up, using it involves looking up an instance in a list. For best results, I'd use a regular linked list and use this to identify objects.
'Other programs' use something along the lines of a map, I'm sure, and use the map's amazing lookup prowess to find the instance, instead of just being able to say "There it is!" like using this would allow me to do.
2704
Announcements / Re: Merry Christmas
« on: December 26, 2008, 01:32:13 pm »
There's no need. My changes all have a default setting that doesn't change the look of the language at all. (Except typenames, but meh, those'll come in time)
The changes are to let you select a faster option that may compromise how close the two languages look.
The changes are to let you select a faster option that may compromise how close the two languages look.
2705
Announcements / Merry Christmas
« on: December 25, 2008, 10:39:19 pm »
Figured I should say Merry Christmas.
Todo:
- Go through and replace all return 0; with return ENIGMA_VOIDVAL and all worthless int functions with ENIGMA_VOID
- Make all worthless doubles into ENIGMA_INTVAL (for less memory waste and easier transition to C++)
- Make rooms force performance of creation codes later, and to save an if() check in ctor, move create() from end of constructor to end of instance_create()
- Go back and redo draw_primitive_() (they're pretty terrible)
- Make sure sprites are optimized (they use map, God help us)
- Take care of vsync (that's the reason your framerate is 60)
- Fix window caption if it doesn't fix itself (it's liable to)
- Make sure going to different rooms works (I prolly broke that at some point, had a problem with creating two instances of some things)
- Add sprite_set_alpha_from_sprite() (had multiple requests for it, and it's easy)
- Allow using draw buffer as texture (Possible without framebuffer extension? With it?)
- Check alarm events, add collision events, add/fix/redo "other" (depending on what pieces of it I have. I want all this good stuff in asap)
This is all in addition to what I'm doing now, which is composing an interchangeable system for instance tracking, depending on the functions you use.
I'm thinking of having quite a few options, actually, including these:
instance storage:
- keeping instances listed in one big array
- keeping instances in a standard linked list (for games with lots of destroying but not a lot of instance_ functions)
- keeping instances in a map (long standing method)
depth tracking:
- keeping depth in a linked list (for games with two or three depths. Or like, less than ten.)
- keeping depth in a map (for those who say depth=-y)
- no depth (gonna be as big a pain to undo, but I'd like it as an option)
instance reference:
- id is an integer used for finding instances (slow like GM)
- id is an integer representation of the C++ keyword `this', and can be used for instant lookup (fast and hazardous)
- id doesn't exist; only `this' is used (plum crazy for our purposes, but it's efficient)
As for what's already done, I'm too lazy to list that. And it's Christmas. At 10 PM. So even though I had some good news a month ago that I still haven't shared... I'll just build up some things to throw at you all.
As for what I'm planning for bigger and better releases, that's subject to change as well as to hard criticism. Plus it's all totally unrealistic anyway, right? (Just like Build Mode, and, well, the entire rest of the ENIGMA project.) So I think I'll just say nothing on that, as usual.
Anyway, good night all, and Merry Christmas.
Todo:
- Go through and replace all return 0; with return ENIGMA_VOIDVAL and all worthless int functions with ENIGMA_VOID
- Make all worthless doubles into ENIGMA_INTVAL (for less memory waste and easier transition to C++)
- Make rooms force performance of creation codes later, and to save an if() check in ctor, move create() from end of constructor to end of instance_create()
- Go back and redo draw_primitive_() (they're pretty terrible)
- Make sure sprites are optimized (they use map, God help us)
- Take care of vsync (that's the reason your framerate is 60)
- Fix window caption if it doesn't fix itself (it's liable to)
- Make sure going to different rooms works (I prolly broke that at some point, had a problem with creating two instances of some things)
- Add sprite_set_alpha_from_sprite() (had multiple requests for it, and it's easy)
- Allow using draw buffer as texture (Possible without framebuffer extension? With it?)
- Check alarm events, add collision events, add/fix/redo "other" (depending on what pieces of it I have. I want all this good stuff in asap)
This is all in addition to what I'm doing now, which is composing an interchangeable system for instance tracking, depending on the functions you use.
I'm thinking of having quite a few options, actually, including these:
instance storage:
- keeping instances listed in one big array
- keeping instances in a standard linked list (for games with lots of destroying but not a lot of instance_ functions)
- keeping instances in a map (long standing method)
depth tracking:
- keeping depth in a linked list (for games with two or three depths. Or like, less than ten.)
- keeping depth in a map (for those who say depth=-y)
- no depth (gonna be as big a pain to undo, but I'd like it as an option)
instance reference:
- id is an integer used for finding instances (slow like GM)
- id is an integer representation of the C++ keyword `this', and can be used for instant lookup (fast and hazardous)
- id doesn't exist; only `this' is used (plum crazy for our purposes, but it's efficient)
As for what's already done, I'm too lazy to list that. And it's Christmas. At 10 PM. So even though I had some good news a month ago that I still haven't shared... I'll just build up some things to throw at you all.
As for what I'm planning for bigger and better releases, that's subject to change as well as to hard criticism. Plus it's all totally unrealistic anyway, right? (Just like Build Mode, and, well, the entire rest of the ENIGMA project.) So I think I'll just say nothing on that, as usual.
Anyway, good night all, and Merry Christmas.
2706
Announcements / Re: ENIGMA Needs a better storage method
« on: December 19, 2008, 04:20:01 pm »
That'd take way too long, and be far too inefficient.
2707
Announcements / Re: ENIGMA Needs a better storage method
« on: December 17, 2008, 06:43:16 am »
Ism-- Nope, that certainly wouldn't work here. At least not well. I'm mostly concerned about speed. Space is an issue to.
For some games, there's only one or two depths, so a tree would be overkill.
For others, there are closer to 41, or even up to 640 different used ones. So a tree would be a little nicer, but still, I can't imagine there really being 640 simultaneously used depths, so...
As for instances, I think a tree would be best bet. That way lookup is really fast, even though removal and creation are slowed.
For some games, there's only one or two depths, so a tree would be overkill.
For others, there are closer to 41, or even up to 640 different used ones. So a tree would be a little nicer, but still, I can't imagine there really being 640 simultaneously used depths, so...
As for instances, I think a tree would be best bet. That way lookup is really fast, even though removal and creation are slowed.
2708
Announcements / ENIGMA Needs a better storage method
« on: December 15, 2008, 07:19:44 pm »
I can't decide what to do next, actually.
I made a system that implements depth. The system can have a few different options, each of which has some unappealing drawback, I'm sure.
What I was going to go with was a red-black tree, just like STL uses in their map. (I may break down and just use STL, depending on how angry I am at them when I wake up tomorrow.)
What I designed the system with originally had no conventional sorting method.
Let me explain.
Instances were just added to a standard linked list for simplicity of working with them.
Then I have a list of event types, which point to a list of depths, which point to both a start and end position on a list of instance pointers. The instance pointers will have their corresponding event accessed.
This was so if you had 10,000 instances, three of which had a step event, ENIGMA would execute only the step events of those three.
I believe this is what "other software" does, so I guess I really had no choice.
Okay, now that I typed a page of exposition, here's the breakdown.
Positive: The nodes on the depth list point to the right points on the list of instances with each event just fine. There is no need to change the instance-event list.
Problem 1: The depths are accessed simply by iterating through the list until you find the right depth. So for those of you who say depth=-y, you may just run into a speed problem. (Nothing major, I promise, but it could still be a few milliseconds faster per call. Big deal, ha?)
Problem 2: The reason I'm mad at STL is because "other software" defies the laws of C++ and 'proper coding.' Meaning that when you say instance_destroy(), STL cries, cuz I'd have to delete an instance that God knows how many iterators are pointing at. (There actually should be just one, but I'd feel icky about just moving the iterator so I could defile the map) Knowing this, if I don't do anything, and just delete the instance from the map, the game will crash.
What I did in my tests was just 'orphan' the node. It's a term I coined for unlinking it, then deleting it after all iterations are complete. (At the very, very end of the step, when framerate is calculated, etc)
So yeah, I'm in a pickle.
Really smart people: Gimme suggestions
Everyone else: Just keep in mind I'm fussing over milliseconds here, and don't go whining "zomg enigmaare vap0rawre!11!"
Final thought:
If you post another newspost over my important questions and announcements, a2h, I will poke you with a VERY sharp stick. >=[[ And the new forum look sucks so I'd 'preciate it if you fixed that please and thank you. :3
I made a system that implements depth. The system can have a few different options, each of which has some unappealing drawback, I'm sure.
What I was going to go with was a red-black tree, just like STL uses in their map. (I may break down and just use STL, depending on how angry I am at them when I wake up tomorrow.)
What I designed the system with originally had no conventional sorting method.
Let me explain.
Instances were just added to a standard linked list for simplicity of working with them.
Then I have a list of event types, which point to a list of depths, which point to both a start and end position on a list of instance pointers. The instance pointers will have their corresponding event accessed.
This was so if you had 10,000 instances, three of which had a step event, ENIGMA would execute only the step events of those three.
I believe this is what "other software" does, so I guess I really had no choice.
Okay, now that I typed a page of exposition, here's the breakdown.
Positive: The nodes on the depth list point to the right points on the list of instances with each event just fine. There is no need to change the instance-event list.
Problem 1: The depths are accessed simply by iterating through the list until you find the right depth. So for those of you who say depth=-y, you may just run into a speed problem. (Nothing major, I promise, but it could still be a few milliseconds faster per call. Big deal, ha?)
Problem 2: The reason I'm mad at STL is because "other software" defies the laws of C++ and 'proper coding.' Meaning that when you say instance_destroy(), STL cries, cuz I'd have to delete an instance that God knows how many iterators are pointing at. (There actually should be just one, but I'd feel icky about just moving the iterator so I could defile the map) Knowing this, if I don't do anything, and just delete the instance from the map, the game will crash.
What I did in my tests was just 'orphan' the node. It's a term I coined for unlinking it, then deleting it after all iterations are complete. (At the very, very end of the step, when framerate is calculated, etc)
So yeah, I'm in a pickle.
Really smart people: Gimme suggestions
Everyone else: Just keep in mind I'm fussing over milliseconds here, and don't go whining "zomg enigmaare vap0rawre!11!"
Final thought:
If you post another newspost over my important questions and announcements, a2h, I will poke you with a VERY sharp stick. >=[[ And the new forum look sucks so I'd 'preciate it if you fixed that please and thank you. :3
2709
Issues Help Desk / Re: Enigma communication error
« on: December 13, 2008, 03:20:02 pm »
[size=8]>_<[/size]
2710
Proposals / Re: Some things just have to be deprecated
« on: December 13, 2008, 03:16:54 pm »
>=o
*undoes the filter thing*
*undoes the filter thing*
2712
Proposals / Re: Some things just have to be deprecated
« on: December 08, 2008, 06:10:36 pm »
Like I said, real easy to implement. Assuming I don't run into any problems getting a pointer to a function with 16 optional arguments, other than the shear size of the type name.
But it still seems pretty worthless. And no wonder you complain about speed, serpy. Mark never bothers to tokenize new object code ahead of time, or something. New objects are much, much slower than regular ones.
But it still seems pretty worthless. And no wonder you complain about speed, serpy. Mark never bothers to tokenize new object code ahead of time, or something. New objects are much, much slower than regular ones.
2713
Tips, Tutorials, Examples / Re: choose(), mean(), median()
« on: December 08, 2008, 08:00:33 am »
Actually, it turns it into... I spose I'll say a byte code, for lack of anything better to call it. It's pretty close to compiling, only it's compiling for itself to read later, not the system to read later.
2714
Tips, Tutorials, Examples / Re: choose(), mean(), median()
« on: December 06, 2008, 06:13:27 pm »
I know, I was wondering what that had to do with it being interpreted at load time.
2715
Proposals / Re: Some things just have to be deprecated
« on: December 06, 2008, 06:12:54 pm »
Practically never.
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 »