Josh @ Dreamland
|
|
Posted on: March 28, 2010, 10:16:04 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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:
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:
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:
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 :
#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.
|
|
« Last Edit: March 29, 2010, 08:14:00 am by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #2 Posted on: March 29, 2010, 09:44:29 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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.
|
|
« Last Edit: March 29, 2010, 09:59:40 am by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #5 Posted on: March 29, 2010, 01:07:19 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
> 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.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #7 Posted on: March 29, 2010, 01:33:17 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Well, that settles that, then.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #10 Posted on: March 29, 2010, 01:41:28 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
> Anything invisible that affects the collision system. "visible" is part of the graphics tier.
retep: extern is a great keyword
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Rusky
|
|
Reply #12 Posted on: March 29, 2010, 01:51:53 pm |
|
|
Joined: Feb 2008
Posts: 954
|
retep, what on earth does that do? Josh, why would you limit the ways you can remove stuff? That seems rather counter-intuitive. What if you wanted to make an invisible wall by entirely removing the graphics system?
It would make even more sense to give objects GrahpicsComponents, CollisionComponents and OtherSystemCompoents. It would make different system changeable at runtime (e.g. for instance_change or game options), definable by DLL's, distributed as extremely reusable "behaviors", etc. If you designed a good interface between them you would need less explicit member access, and all the functions that are doing more general things (built-in systems, for example) wouldn't have any speed problems.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #13 Posted on: March 29, 2010, 01:52:14 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Remove all those #ifdef #define pairs I can't find another explanation for. If they were so other systems could check if the variable has been implemented, that goes against the purpose of tiering (we'd have to go back over everything and recompile).
Rusky-- And every third instruction would be CALL. Not happening. Furthermore, "wouldn't have any speed problems..." Do you have ANY research to back this up? Hello, you want me to throw in a function call every time I want object.x? When object is already a pointer? What the FUCK? I'm to the point where I'm unhappy about busing a DWORD back and forth from the RAM, and you want me to make a CALL for it instead. We're talking 6x the number of clocks, easily. That statement genuinely pissed me off this time.
If you want a text-based game with a collision system operating in a terminal window, I'm not programming for you. Same for if you want to change your fucking mind about what operating system the game is for at runtime. Jesus.
|
|
« Last Edit: March 29, 2010, 02:07:57 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|