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 »
2221
Proposals / Re: Tierable Systems
« on: March 29, 2010, 01:07:19 pm »
> Virtual accessor functions?
Could work, then I'd have to hope they were always inlined. I'll look into it if I need. They won't help much since they'll need to be given a certain type as well, but they could allow for multiple inheritance. I'll see if they come in handy.
> What about invisible walls?
Not sure what you're referring to.
Could work, then I'd have to hope they were always inlined. I'll look into it if I need. They won't help much since they'll need to be given a certain type as well, but they could allow for multiple inheritance. I'll see if they come in handy.
> What about invisible walls?
Not sure what you're referring to.
2222
Proposals / Re: Tierable Systems
« on: March 29, 2010, 09:44:29 am »
I considered it (it was in fact my first thought), but then indexes could end up different between files, and thus a file could end up reading the wrong block of memory to fetch its variable.
Like using int vs a variant type for x and y: changing the size based on multiple inheritance could totally fuck up collision code, as it would suddenly be reading 12 bytes further than where it should be for each variant that became an int.
The solution would be to include the settings file to understand which size it was looking at, but doing so would require recompile, and that is exactly what this tier system is designed to avoid.
Edit: let me clarify.
Each new step in the tier must assume as few sizes as possible from the previous ones. We want systems to be removable or swappable, but allowing a system to be changed can likely impact the behavior of other parts of the system. In this hierarchy, the affected parts will all be lower tiers. For instance, if you removed graphics, the assumption is that you'd have no further need for collisions.
The instance functions can make use of tier one, needing only ID and object index. They'll never even notice if the collision system is removed or changed.
There is still some need for recompile, but with completely linear tiers it becomes seldom or trivial enough to where a new source file can be made to accommodate each change to a lower tier. Multiple inheritance could vastly screw that up.
Like using int vs a variant type for x and y: changing the size based on multiple inheritance could totally fuck up collision code, as it would suddenly be reading 12 bytes further than where it should be for each variant that became an int.
The solution would be to include the settings file to understand which size it was looking at, but doing so would require recompile, and that is exactly what this tier system is designed to avoid.
Edit: let me clarify.
Each new step in the tier must assume as few sizes as possible from the previous ones. We want systems to be removable or swappable, but allowing a system to be changed can likely impact the behavior of other parts of the system. In this hierarchy, the affected parts will all be lower tiers. For instance, if you removed graphics, the assumption is that you'd have no further need for collisions.
The instance functions can make use of tier one, needing only ID and object index. They'll never even notice if the collision system is removed or changed.
There is still some need for recompile, but with completely linear tiers it becomes seldom or trivial enough to where a new source file can be made to accommodate each change to a lower tier. Multiple inheritance could vastly screw that up.
2223
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 09:41:48 am »
> since you need less runtime checks to be safe
Last I checked, C++ doesn't make any of those, either.
> "Compile-time verification has nothing to do with runtime performance. In fact, it can enhance it,"
lolwut
And yes, it can enhance performance for you if you've paid attention to nothing you've been doing with your types.
>PHP is a horrible example of a type system.
I was talking only of PHP's continue behaving entirely different than in other languages. I expect the same to happen with compiler-determined types. Like when Dylan templated fuck-everything in ENIGMA and we started getting problems when dividing int/int. I would hope Haskell is a little better at resolving a type for that, being less afraid to waste memory, but I don't really want to give it a chance to make life hard for me. Explicitly stating types has never caused me grief. Now, array bounds are another story...
Last I checked, C++ doesn't make any of those, either.
> "Compile-time verification has nothing to do with runtime performance. In fact, it can enhance it,"
lolwut
And yes, it can enhance performance for you if you've paid attention to nothing you've been doing with your types.
>PHP is a horrible example of a type system.
I was talking only of PHP's continue behaving entirely different than in other languages. I expect the same to happen with compiler-determined types. Like when Dylan templated fuck-everything in ENIGMA and we started getting problems when dividing int/int. I would hope Haskell is a little better at resolving a type for that, being less afraid to waste memory, but I don't really want to give it a chance to make life hard for me. Explicitly stating types has never caused me grief. Now, array bounds are another story...
2224
Proposals / Tierable Systems
« on: March 28, 2010, 10:16:04 pm »
Some people don't want a huge-ass graphics system or collisions system. Different systems can require more variables to operate than others. Switching out systems means incorporating different variables.
Solution:
In the local directory of each graphics system:
Of the collision system, which we assume to require graphics system:
Then finally, in the IDE Editable headers in which code is stored:
struct parent_locals :
This is being implemented for testing *now.*
Note: I left out X and Y for brevity. They will be assumed to be needed before collisions but after graphics.
Solution:
Code: [Select]
struct parent_basic {
const unsigned id;
const int object_index;
parent_basic(): id(0), object_index(noone) {}
parent_basic(unsigned x, int y): id(x), object_index(y) {};
};
In the local directory of each graphics system:
Code: [Select]
struct inherit_graphics_GL : parent_basic {
int sprite_index;
int image_index;
inherit_graphics_GL() {}
inherit_graphics_GL(int x, int y) parent_basic(x,y) {}
};
Of the collision system, which we assume to require graphics system:
Code: [Select]
struct inherit_collisions_colligma : inherit_graphics_GL {
int mask_index;
inherit_collisions_colligma() {}
inherit_collisions_colligma(int x, int y) inherit_graphics_GL(x,y) {}
};
Then finally, in the IDE Editable headers in which code is stored:
struct parent_locals :
Code: [Select]
#if USE_GRAPHICS
#if USE_COLLIGMA
#define high_tier inherit_collisions_colligma
#else
#define high_tier inherit_graphics_GL
#endif
#else
#define high_tier parent_basic
#endif
struct parent_locals: high_tier
{
var health;
var lives;
var otherworthlessthings;
//...
parent_locals() {}
parent_locals(unsigned my_id, int my_object_index): high_tier(my_id,my_object_index) {}
};
This is being implemented for testing *now.*
Note: I left out X and Y for brevity. They will be assumed to be needed before collisions but after graphics.
2225
Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 07:56:14 pm »
Not perfect, just beautiful. I like explicitly stating things; it shows me I'm still in control of something. The modern movement is towards throwing performance to the wind and letting the compiler do everything for you. That was the spark of so many errors in GM, I decided to avoid it entirely. Not to mention it's the little 'helpful' things like that which end up seeming unintuitive, at least to me.
I remember the first time I wrote anything useful in PHP. I didn't know continue; was the same as break; in a switch statement. Well, learned that one the hard way.
The only reason I don't have a type-related example of how I got really burned on not seeing a certain behavior coming is that I never gave it the chance.
To me, C++'s types are beautiful because they do my work for me in a manner I could predict from a coma. I never have the surprise, pleasant or otherwise, of a new feature. That to me, is beautiful. If you want to explain to me how that isn't beautiful or shouldn't be beautiful to me, go ahead.
I remember the first time I wrote anything useful in PHP. I didn't know continue; was the same as break; in a switch statement. Well, learned that one the hard way.
The only reason I don't have a type-related example of how I got really burned on not seeing a certain behavior coming is that I never gave it the chance.
To me, C++'s types are beautiful because they do my work for me in a manner I could predict from a coma. I never have the surprise, pleasant or otherwise, of a new feature. That to me, is beautiful. If you want to explain to me how that isn't beautiful or shouldn't be beautiful to me, go ahead.
2226
Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 07:25:27 pm »
Oh, but they're just universally fleeting in the eyes of any beholder who has experienced a functional language?
Certainly I'd hate them if I ever got an amazing implicit list type.
It's wonderful if you like other languages. Please quit pretending that everyone does/will accordingly. <_<"
Certainly I'd hate them if I ever got an amazing implicit list type.
It's wonderful if you like other languages. Please quit pretending that everyone does/will accordingly. <_<"
2227
Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 12:57:29 pm »
The idea is for this to require very little effort. It'd be almost entirely code-generated code. But yes, I could find better things to spend time on.
2228
Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 12:28:42 pm »
Hah, true. Don't worry though, this isn't to be implemented yet. I added that C compiler because I don't want more mediocrity; GM users are content with that for now, but I want my beautiful C++ types. And I like the idea of structures. So I just went all-out.
This, however, does not appeal to me. So I will let it sit here until it gets eroded smooth by anyone who posts on the matter.
This, however, does not appeal to me. So I will let it sit here until it gets eroded smooth by anyone who posts on the matter.
2229
Announcements / Re: Collisions
« on: March 28, 2010, 10:04:10 am »
Actually, are you sure that casting that initializer as var will properly allocate them? (I'd cast as variant anyway, but...)
2230
Proposals / Re: Idea for var
« on: March 28, 2010, 09:58:29 am »
I want the new var to offer casts to all scalars, optional overloads for iostream and fstream, and a copy-on-write system for arrays (allowing arrays to be passed as function parameters and script arguments).
To preserve speed, we sacrifice memory. It's always been that way with ENIGMA since I found a clue what I was doing. I thought of methods that would make var eight bytes, but I don't want to implement them as they waste instructions.
To preserve speed, we sacrifice memory. It's always been that way with ENIGMA since I found a clue what I was doing. I thought of methods that would make var eight bytes, but I don't want to implement them as they waste instructions.
2231
Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 09:54:25 am »
Only on C++ things that aren't in GML. Since execute_string is more for compatibility, I'm not concerned with having it support C, really.
2232
Announcements / Re: Collisions
« on: March 27, 2010, 10:09:54 pm »
Man, that's hackish even by my standards. I'll do it.
2234
Announcements / Re: Collisions
« on: March 27, 2010, 12:32:18 pm »
Bahaha, yes, all of those things.
2235
Announcements / Re: Collisions
« on: March 27, 2010, 09:06:24 am »
Game_boy:
Not at present; I could generate one, but I don't think some of the systems I coded are all in there. Like text file manipulation and DLL's.
The 11th plague of Egypt:
Assuming you're talking about ds_lists, they are global. Don't worry, this new system won't break ds_list; it'll supply an alternative to them. Lists are stored somewhat like sprites; a global array of things GM users don't understand, which they can access by an integer from absolutely anywhere. So, a=ds_list_create() will add to that list, "list a;" won't.
Not at present; I could generate one, but I don't think some of the systems I coded are all in there. Like text file manipulation and DLL's.
The 11th plague of Egypt:
Assuming you're talking about ds_lists, they are global. Don't worry, this new system won't break ds_list; it'll supply an alternative to them. Lists are stored somewhat like sprites; a global array of things GM users don't understand, which they can access by an integer from absolutely anywhere. So, a=ds_list_create() will add to that list, "list a;" won't.
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 »