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 »
2176
Announcements / Re: Metaphase
« on: April 02, 2010, 10:05:40 am »
You're right. For unicode, short and wchar_t should be enough. I have no idea why anyone would need a third character.
2177
Announcements / Re: Metaphase
« on: April 02, 2010, 09:00:07 am »
All you have to do is post something if a piece of code won't compile. I will do my best to print helpful info about what may have went wrong, but as long as you are testing simple codes, we should get to the bottom of it relatively painlessly.
I'm just afraid a lot of things will go wrong, and there'll be reports everywhere.
@retep-
I'm just afraid a lot of things will go wrong, and there'll be reports everywhere.
@retep-
2178
Announcements / Re: New Interests
« on: April 02, 2010, 08:57:37 am »
One of the nice things about ENIGMA is that people will leave knowing one of the most popular languages in the world.
That's why I added all these C++ layers without infringing on the GML ones. Users will slowly get accustomed to C++ features, and before you know it, they'll understand the system.
That's why I added all these C++ layers without infringing on the GML ones. Users will slowly get accustomed to C++ features, and before you know it, they'll understand the system.
2179
Announcements / Metaphase
« on: April 01, 2010, 09:27:54 pm »
April Fool's has finally passed, with only moderate ripple effects, I might add.
A lot of insanely awesome stuff is going on right now, a lot of which I'll keep a surprise, but I'm happy to report that Ism can now successfully pass me resource data via the DLL. We are still missing a few things that R3 had support for, which I am trying to scramble up support for. Expect a testing phase commencing tomorrow. This should not overflow into the following day.
What that test will actually look like depends on a number of factors. Right now, I'm too excited to sleep. So the project has me for a while.
LGM has a bug, seemingly only on Windows, that we'll need to isolate and resolve. Isn't a very obtrusive bug and doesn't really fall on me, so.
Other things that need done with LGM include re-implementing the syntax check button now that ENIGMA's a DLL, and configuring it to inform me of changes in the C++ resource to avoid wasting an additional second during compile.
I think I may also implement the new instance system before I begin the test phase.
Also, keep this phase relatively quiet: I'm considering making it community-members only. Two reasons for this:
1) A huge part of the point of this is to alleviate stress caused by the release having a fatal flaw that has been overlooked.
2) I want the testing phase to be a small sample of people who can actually tell me what isn't working, or what's missing.
This testing phase will hopefully be both an opportunity to debug and to request small functions, maybe systems. While you test, I will be implementing sounds. Do not expect them from day 1.
In fact, since at this point I'm getting things that were done already in R3 working, expect the entire project to be a miserable piece of failure, and then be enamored by all the wonderful things it turns out that it can do.
Of course, if it doesn't do a particular wonderful thing, such as R3.0's inability to use non-numeral-prefixed constants (such as .5), and R2's lack of comments, DO REPORT THAT.
Again, though, keep it low for now. Release should be ready by the end of tomorrow. We'll see about getting something from Luda in that. I can't stress enough not to count on all the systems that will be in R4 to be that way immediately; many of them still need integration that is better done during the testing phase. Don't expect the bitmask system yet; Luda said he'd try to have the rectangle part of his design ready, though. Also, I'm looking at backgrounds and tiles right now, frowning. So, we'll see what this gets us.
A lot of insanely awesome stuff is going on right now, a lot of which I'll keep a surprise, but I'm happy to report that Ism can now successfully pass me resource data via the DLL. We are still missing a few things that R3 had support for, which I am trying to scramble up support for. Expect a testing phase commencing tomorrow. This should not overflow into the following day.
What that test will actually look like depends on a number of factors. Right now, I'm too excited to sleep. So the project has me for a while.
LGM has a bug, seemingly only on Windows, that we'll need to isolate and resolve. Isn't a very obtrusive bug and doesn't really fall on me, so.
Other things that need done with LGM include re-implementing the syntax check button now that ENIGMA's a DLL, and configuring it to inform me of changes in the C++ resource to avoid wasting an additional second during compile.
I think I may also implement the new instance system before I begin the test phase.
Also, keep this phase relatively quiet: I'm considering making it community-members only. Two reasons for this:
1) A huge part of the point of this is to alleviate stress caused by the release having a fatal flaw that has been overlooked.
2) I want the testing phase to be a small sample of people who can actually tell me what isn't working, or what's missing.
This testing phase will hopefully be both an opportunity to debug and to request small functions, maybe systems. While you test, I will be implementing sounds. Do not expect them from day 1.
In fact, since at this point I'm getting things that were done already in R3 working, expect the entire project to be a miserable piece of failure, and then be enamored by all the wonderful things it turns out that it can do.
Of course, if it doesn't do a particular wonderful thing, such as R3.0's inability to use non-numeral-prefixed constants (such as .5), and R2's lack of comments, DO REPORT THAT.
Again, though, keep it low for now. Release should be ready by the end of tomorrow. We'll see about getting something from Luda in that. I can't stress enough not to count on all the systems that will be in R4 to be that way immediately; many of them still need integration that is better done during the testing phase. Don't expect the bitmask system yet; Luda said he'd try to have the rectangle part of his design ready, though. Also, I'm looking at backgrounds and tiles right now, frowning. So, we'll see what this gets us.
2180
Announcements / Re: New Interests
« on: April 01, 2010, 07:12:48 pm »
*shrug*
Can't compete with age.
*fixes post count*
Can't compete with age.
*fixes post count*
2181
Proposals / Re: Tierable Systems
« on: April 01, 2010, 06:08:14 pm »
"to keep the same interface ... that doesn't mean their internals should or even could remain the same."
I tried explaining this, maybe not thoroughly enough. The tiering system is only for local variables instantiated along with objects. These are the variables that will be in every single instance, like x and y in GM. They are entirely independent of locals to a system; a system can have as many of those as it wants and still be independent. Certainly you knew that... To have the same interface is to have the same locals.
"With components, those debugging features could be turned on and off at runtime, without any recompilation"
The community is going to respond GREAT to this. That was political suicide in the world of GM, sorry. And don't bother attacking me; I'm a little above that. Number one, no one else is; number two, debug things are costly size-wise. Is it your intention to remove the debug things entirely during final compilation? If not, you may as well just leave; otherwise, there's no point to having them removable before that final build anyway.
I tried explaining this, maybe not thoroughly enough. The tiering system is only for local variables instantiated along with objects. These are the variables that will be in every single instance, like x and y in GM. They are entirely independent of locals to a system; a system can have as many of those as it wants and still be independent. Certainly you knew that... To have the same interface is to have the same locals.
"With components, those debugging features could be turned on and off at runtime, without any recompilation"
The community is going to respond GREAT to this. That was political suicide in the world of GM, sorry. And don't bother attacking me; I'm a little above that. Number one, no one else is; number two, debug things are costly size-wise. Is it your intention to remove the debug things entirely during final compilation? If not, you may as well just leave; otherwise, there's no point to having them removable before that final build anyway.
2182
Announcements / Re: New Interests
« on: April 01, 2010, 05:58:19 pm »
It's funny that no one here can tell who's trolling and who's being trolled. I knew when I posted it that Miky would get his britches in a tangle. Wasn't sure what would happen after that.
-And with his 666th post, he denounced the entire topic-
So yes, here's celebrating April Fool's, and my 666th post. Ahhh, good days.
-And with his 666th post, he denounced the entire topic-
So yes, here's celebrating April Fool's, and my 666th post. Ahhh, good days.
2183
Announcements / Re: New Interests
« on: April 01, 2010, 01:30:00 pm »YOU ARE A FUCKING IDIOT!!!
WHAT THE FUCK HAPPENED HERE!!!
"ENIGMA will make sure that you don't accidentally add anything to obtain "1""
ARE YOU FUCKING RETARDED???
DON'T DO THIS JOSH!!!
Well, it's the only way, since GM doesn't offer any method to distinguish between integer and pointer, only loosely between instance and object.
Also, Java doesn't have pointers, and C# makes you ask sternly for them.
2184
Announcements / New Interests
« on: April 01, 2010, 12:48:16 pm »
As you can plainly see, the interests of this community have changed from software and game development to unicorns. As such, the ENIGMA project has been discontinued, effective immediately. For the third year in a row.
Okay, enough of that now. On to serious matters.
Upon further consideration, it has appeared to me that C++ just isn't right for ENIGMA; despite my best efforts, I don't think I can pull off all the things Game Maker does without a better system. Specifically, one with such goodies as dependent typing and a good garbage collector, so users can use ds_list_create and just forget they did so without worry, and so late at night when it's hard to keep track of what I'm doing, I'll be fine. I won't have to fear that I've made a mistake in my coding; something else will let me know or just take care of it for me. We all want that, right? Switching to a better language could definitely improve development speed, in that respect.
Besides, it's time to give the project's organization some serious rethinking. POD has become, though efficient, too confusing when looking at the bigger picture: we're better off calling things by reference. Doing so makes sense, and will help the garbage collector and any debugging implementations as well.
I was looking at C# or Java, maybe even with some Haskell. All of those languages are gaining popularity quite quickly; chances are they'll work on all the platforms we want ENIGMA to compile for within the next ten years. Those languages don't each offer all of the features I mentioned above, but they'll make mine and users' lives easier.
Think about it: With their garbage collectors and referencing systems working for us, you can just create a ds_list, forget about it, and in a few steps, it'll just be gone! To ensure that users don't accidentally reuse a destroyed list, the integer-id (probably between 0 and 20) will cease to exist along with it, meaning you can no longer set any variables to it. So, if you said, for example:
a = ds_list_create();
ds_list_...
But then just stopped using "a"'s list for a while (like if you had it in an alarm that was taking a really long time to execute and so probably never would), list 1 would be freed. So what would happen if you were to pass "1" to ds_list_find again? That's the beauty: You can't! When list "1" is freed, so is the constant "1" from the game. That means that from now on, you can't use "1" anywhere in your code, and ENIGMA will make sure that you don't accidentally add anything to obtain "1". Also, make sure not to divide by it, as doing so may cause an error (don't worry though, each of these languages has great exception handling).
This can be accomplished by keeping everything stored as pointers, especially constants. Instead of "1" just being an integer in memory, it will be an integer pointing to an integer, and then another integer to verify that our integer points to an integer. Simple, yes? Efficient, too: modern processors are making it so no one will even notice the effects of doing so.
I haven't seen any Java games for Wii, yet, but maybe they could be played through the Wii's browser. On the other hand, I have seen one C# program for the Wii, and I'm sure it has reached shelves of hard-core gaming fanatics everywhere; just look at it. Although I don't think development with C# for non-Windows systems will be supported by Microsoft, they have agreed not to sue for it.
Because of that, C# is looking like a really good option. Plus, using C# would give us access to Microsoft's powerful .NET framework on Windows, which end users would simply have to download. It's only a few hundred megabytes. The Mono team has been working very hard to get that framework running on other operating systems, too; it should be mostly supported.
I can't wait to hear your comments on this. I feel we'll need a new logo to go along with it, possible something with gears and happy faces.
XOXOXOXO
<3<3<3
something about unicorns
Okay, enough of that now. On to serious matters.
Upon further consideration, it has appeared to me that C++ just isn't right for ENIGMA; despite my best efforts, I don't think I can pull off all the things Game Maker does without a better system. Specifically, one with such goodies as dependent typing and a good garbage collector, so users can use ds_list_create and just forget they did so without worry, and so late at night when it's hard to keep track of what I'm doing, I'll be fine. I won't have to fear that I've made a mistake in my coding; something else will let me know or just take care of it for me. We all want that, right? Switching to a better language could definitely improve development speed, in that respect.
Besides, it's time to give the project's organization some serious rethinking. POD has become, though efficient, too confusing when looking at the bigger picture: we're better off calling things by reference. Doing so makes sense, and will help the garbage collector and any debugging implementations as well.
I was looking at C# or Java, maybe even with some Haskell. All of those languages are gaining popularity quite quickly; chances are they'll work on all the platforms we want ENIGMA to compile for within the next ten years. Those languages don't each offer all of the features I mentioned above, but they'll make mine and users' lives easier.
Think about it: With their garbage collectors and referencing systems working for us, you can just create a ds_list, forget about it, and in a few steps, it'll just be gone! To ensure that users don't accidentally reuse a destroyed list, the integer-id (probably between 0 and 20) will cease to exist along with it, meaning you can no longer set any variables to it. So, if you said, for example:
a = ds_list_create();
ds_list_...
But then just stopped using "a"'s list for a while (like if you had it in an alarm that was taking a really long time to execute and so probably never would), list 1 would be freed. So what would happen if you were to pass "1" to ds_list_find again? That's the beauty: You can't! When list "1" is freed, so is the constant "1" from the game. That means that from now on, you can't use "1" anywhere in your code, and ENIGMA will make sure that you don't accidentally add anything to obtain "1". Also, make sure not to divide by it, as doing so may cause an error (don't worry though, each of these languages has great exception handling).
This can be accomplished by keeping everything stored as pointers, especially constants. Instead of "1" just being an integer in memory, it will be an integer pointing to an integer, and then another integer to verify that our integer points to an integer. Simple, yes? Efficient, too: modern processors are making it so no one will even notice the effects of doing so.
I haven't seen any Java games for Wii, yet, but maybe they could be played through the Wii's browser. On the other hand, I have seen one C# program for the Wii, and I'm sure it has reached shelves of hard-core gaming fanatics everywhere; just look at it. Although I don't think development with C# for non-Windows systems will be supported by Microsoft, they have agreed not to sue for it.
Because of that, C# is looking like a really good option. Plus, using C# would give us access to Microsoft's powerful .NET framework on Windows, which end users would simply have to download. It's only a few hundred megabytes. The Mono team has been working very hard to get that framework running on other operating systems, too; it should be mostly supported.
I can't wait to hear your comments on this. I feel we'll need a new logo to go along with it, possible something with gears and happy faces.
XOXOXOXO
<3<3<3
something about unicorns
2185
Proposals / Re: Tierable Systems
« on: April 01, 2010, 12:07:29 pm »
The hope behind adding a new graphics system (such as GX for the DS and Wii) is that doing so doesn't change any of the tiers; we're striving to allow lossless cross-compilation. Obviously we'll be sacrificing some things between consoles and the PC (namely the keyboard, at least for the DS) and we will be adding some functionality (such as managing viewports with the DS; I'm not sure how it handles multiple screens). Fortunately, most of that will not have to do with locals and will not even need to interface with the tier system.
I do see where components would be handy; I don't think ENIGMA is such a case.
As for debugging, many of the projects I've seen let you compile a debug configuration and a release configuration. Storing a separate object file for each is an option. If I need a notification on write to a variable, I will add such a directive to "var," which, unfortunately, is the tiers' default type. That will require the recompilation (or storing of a second object file) of one source. Two for types such as hspeed, vspeed, direction, and speed, whose assignments are already special-cased to interact with one another. Making the decision to leave var behind can indeed end up being costly of compile time; the hope is to make that happen only the first time and to keep the object files from there.
I'd also like to point out that the tiers are not to be included by most files; only those that truly need to interface with local variables. For example, that includes a good deal of the collision system, but not the collision testing code. Ludamad won't even include a tier, because his system will operate independently of them. There will be a go-between file that I intend to author that will make calls to his system based on active instances.
I do see where components would be handy; I don't think ENIGMA is such a case.
As for debugging, many of the projects I've seen let you compile a debug configuration and a release configuration. Storing a separate object file for each is an option. If I need a notification on write to a variable, I will add such a directive to "var," which, unfortunately, is the tiers' default type. That will require the recompilation (or storing of a second object file) of one source. Two for types such as hspeed, vspeed, direction, and speed, whose assignments are already special-cased to interact with one another. Making the decision to leave var behind can indeed end up being costly of compile time; the hope is to make that happen only the first time and to keep the object files from there.
I'd also like to point out that the tiers are not to be included by most files; only those that truly need to interface with local variables. For example, that includes a good deal of the collision system, but not the collision testing code. Ludamad won't even include a tier, because his system will operate independently of them. There will be a go-between file that I intend to author that will make calls to his system based on active instances.
2186
Proposals / Re: Tierable Systems
« on: March 31, 2010, 10:09:47 pm »
Your instance_change argument had me reconsidering the implications of your proposal for a few seconds before I remembered what it would look like for an event to access any of your component-ized locals. I assume this is where your proposed accessor comes in, which I said before wouldn't really be needed: I could parse in a "componentname->" before each local. However, I don't want to do so, and I don't believe anyone else does either. I was discussing this with Luda; he asked what the point was. I referred him to your independence and instance_change arguments (those were your good ones; coincidentally, they were your only two that were worth a second glance). He then remembered that instance_change existed, he decided it was ugly. I agree, of course. It looks great from a distance when you start forgetting about the lower components you're cursing.
The reason I don't want to parse in componentname-> is not even to do with the amount of work. First off, Luda thought dynamic allocation was ugly; I think requiring a list of what's in each component is ugly. To add that in before the correct variables, I'd need to know what variable is in what component. We have no C++ way of signifying what's a component, so I'd need to keep a list of locals again, or read them from some messy INI. I refuse to do that.
I wanted the system to be extensible from the low level more than the high, really; easy to add more systems to using C++. I have been doing some serious reorganization towards that in every system.
And again, my tier hierarchy is designed to try to emulate true dependence. Consider this; In order to check collisions (the highest tier in my system), I require the following:
- IDs and Object Indexes from object_basic (tier 0)
- Coordinates on the screen from object_planar (tier 1)
- Image Index (to tell which mask to use) from object_graphics (tier 2)
- Bounding boxes and bit masks from object_collisions (tier 3)
That's every tier. If you want to use a DLL like Ultimate3D instead of the built-in drawing systems, but utilize Ludamad's collision system as well, that doesn't really make a bit of sense; Luda uses bitmasks based on sprites. Mutually exclusive tiers can be included just that way, and a source file only has to utilize the one it was designed for. For example, it'd make more sense to use some physics library like Newton instead of Colligma to accompany Ultimate3D. So, a Newton tier could be engineered to only require the first two tiers. This'd be a total of two combinations, really; I'll bet you can't really afford to swap out the planar system if you know how many coordinates you need.
Anyway, I'm proceeding with the tier system until further notice. If you can convince Luda, serp, Ism, ...anyone other than your brother, really, I'll investigate it a bit further. Until then it's better I stick with what's now implemented.
We also discussed how instance_change isn't really used a lot. Normally I'd hate to use that as an excuse, but the function is an oddball. You picked up on that as well. It's one of the very few functions that approached justifying an interpreted language. Also, it's one of the few things R3 randomly lacked that no one even asked about. Despite me not thinking highly of it, I would include an option to employ a component system just to improve any game seriously whoring that function (though neither Luda nor I can think of a good reason for a game to do so), but the choice for this system has far too deep-rooted consequences. It's one of the new backbones of the project; perhaps that's why you're so avidly proposing the components.
Ultimately, too, most of the flexibility issues with removing tiers from my system would manifest as similar problems in moving them from a component system; except we'd just be removing one pointer rather than changing entire chunks of data. The size of the change really doesn't matter; it's that it changed that throws off other systems.
The reason I don't want to parse in componentname-> is not even to do with the amount of work. First off, Luda thought dynamic allocation was ugly; I think requiring a list of what's in each component is ugly. To add that in before the correct variables, I'd need to know what variable is in what component. We have no C++ way of signifying what's a component, so I'd need to keep a list of locals again, or read them from some messy INI. I refuse to do that.
I wanted the system to be extensible from the low level more than the high, really; easy to add more systems to using C++. I have been doing some serious reorganization towards that in every system.
And again, my tier hierarchy is designed to try to emulate true dependence. Consider this; In order to check collisions (the highest tier in my system), I require the following:
- IDs and Object Indexes from object_basic (tier 0)
- Coordinates on the screen from object_planar (tier 1)
- Image Index (to tell which mask to use) from object_graphics (tier 2)
- Bounding boxes and bit masks from object_collisions (tier 3)
That's every tier. If you want to use a DLL like Ultimate3D instead of the built-in drawing systems, but utilize Ludamad's collision system as well, that doesn't really make a bit of sense; Luda uses bitmasks based on sprites. Mutually exclusive tiers can be included just that way, and a source file only has to utilize the one it was designed for. For example, it'd make more sense to use some physics library like Newton instead of Colligma to accompany Ultimate3D. So, a Newton tier could be engineered to only require the first two tiers. This'd be a total of two combinations, really; I'll bet you can't really afford to swap out the planar system if you know how many coordinates you need.
Anyway, I'm proceeding with the tier system until further notice. If you can convince Luda, serp, Ism, ...anyone other than your brother, really, I'll investigate it a bit further. Until then it's better I stick with what's now implemented.
We also discussed how instance_change isn't really used a lot. Normally I'd hate to use that as an excuse, but the function is an oddball. You picked up on that as well. It's one of the very few functions that approached justifying an interpreted language. Also, it's one of the few things R3 randomly lacked that no one even asked about. Despite me not thinking highly of it, I would include an option to employ a component system just to improve any game seriously whoring that function (though neither Luda nor I can think of a good reason for a game to do so), but the choice for this system has far too deep-rooted consequences. It's one of the new backbones of the project; perhaps that's why you're so avidly proposing the components.
Ultimately, too, most of the flexibility issues with removing tiers from my system would manifest as similar problems in moving them from a component system; except we'd just be removing one pointer rather than changing entire chunks of data. The size of the change really doesn't matter; it's that it changed that throws off other systems.
2187
Proposals / Re: Tierable Systems
« on: March 31, 2010, 07:13:32 pm »
More precise code reuse-
Shouldn't matter in a compiled system; anything unused that's declared in a structure will simply be ignored. Just include the highest tier you need shit from.
Minimal recompilation-
As I said, I'd rather double or even triple the compile time when a recompile is necessary (it will be necessary at about the same time for both systems) than double the clocks needed to look up a local. Even if doubling it is as little as one more dereference.
Better organization-
No, the tiers do that, too. Each tier gets its own header and, if necessary, source file.
Possibility of runtime configuration-
Not even slightly interested. I don't see how it helps instance_change, either: with the tier system, instance change is a memcpy(y,x,sizeof(highest tier)) followed by more specific code that the component system wouldn't avoid. In fact, component system makes instance_change slightly more complicated (The compiler would likely take care of the complications, though, if we had a method in each one that could be inlined).
Decorators-
What could possibly stop me from doing that with the tier system?
It seems the key difference between us is that you want to move as much as possible to run time, where I want to do just the opposite.
Shouldn't matter in a compiled system; anything unused that's declared in a structure will simply be ignored. Just include the highest tier you need shit from.
Minimal recompilation-
As I said, I'd rather double or even triple the compile time when a recompile is necessary (it will be necessary at about the same time for both systems) than double the clocks needed to look up a local. Even if doubling it is as little as one more dereference.
Better organization-
No, the tiers do that, too. Each tier gets its own header and, if necessary, source file.
Possibility of runtime configuration-
Not even slightly interested. I don't see how it helps instance_change, either: with the tier system, instance change is a memcpy(y,x,sizeof(highest tier)) followed by more specific code that the component system wouldn't avoid. In fact, component system makes instance_change slightly more complicated (The compiler would likely take care of the complications, though, if we had a method in each one that could be inlined).
Decorators-
What could possibly stop me from doing that with the tier system?
It seems the key difference between us is that you want to move as much as possible to run time, where I want to do just the opposite.
2189
Proposals / Re: Tierable Systems
« on: March 31, 2010, 05:27:54 pm »
How can you specify a blank draw component? Just a pointer to a dummy?
In either case, the tier system is implemented and doing a fabulous job. Rebuild for an additional tier or two isn't much to ask when you already have to rebuild one, especially considering the total build time for the entire project, fully optimized, isn't far past 20 seconds. At this point, I don't see much to gain, even at the cost of only a pointer (That system shouldn't require an accessor if it's including its own structure; I'm still not even considering accessors).
Also, I never claimed that GM games all run at 7fps. I showed that that's what can happen. 5,000 isn't an unreasonable number of lines; GM couldn't manage it 10 fps, ENIGMA wasn't even phased by it. It doesn't matter how they'd be accomplished in GM; GM users are used to working around its incapability. I started a 3D Metroid clone once; couldn't import my model; found a way to, but it ran at 2FPS because of it (where it rendered at 60 in the editor). Ended up rendering it ahead of time and drawing it as a cheap overlay. Looked horrible. All the walls had to be flat... It was sad. But I was happy with it, because it was the best I could do in GM.
miky:
The way I see it, the amount of flexibility I'd gain from this system over the tier system isn't really enough to justify any sort of speed loss whatsoever. Maybe the extra pointer dereference if it really brought anything to the table in the long run. I'd much rather put the doubling of workload on the compiler.
In either case, the tier system is implemented and doing a fabulous job. Rebuild for an additional tier or two isn't much to ask when you already have to rebuild one, especially considering the total build time for the entire project, fully optimized, isn't far past 20 seconds. At this point, I don't see much to gain, even at the cost of only a pointer (That system shouldn't require an accessor if it's including its own structure; I'm still not even considering accessors).
Also, I never claimed that GM games all run at 7fps. I showed that that's what can happen. 5,000 isn't an unreasonable number of lines; GM couldn't manage it 10 fps, ENIGMA wasn't even phased by it. It doesn't matter how they'd be accomplished in GM; GM users are used to working around its incapability. I started a 3D Metroid clone once; couldn't import my model; found a way to, but it ran at 2FPS because of it (where it rendered at 60 in the editor). Ended up rendering it ahead of time and drawing it as a cheap overlay. Looked horrible. All the walls had to be flat... It was sad. But I was happy with it, because it was the best I could do in GM.
miky:
The way I see it, the amount of flexibility I'd gain from this system over the tier system isn't really enough to justify any sort of speed loss whatsoever. Maybe the extra pointer dereference if it really brought anything to the table in the long run. I'd much rather put the doubling of workload on the compiler.
2190
Proposals / Re: Tierable Systems
« on: March 31, 2010, 04:58:37 pm »
"Maybe you should pay a little more attention to things before you start mouthing off in defense of your big brother."
lolirony
lolirony
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 »