T2D Isometric?
by John Vanderbeck · in Torque Game Builder · 03/26/2005 (5:13 pm) · 24 replies
Sorry if this is a dumb question but up until about 5 minutes ago I hadn't payed much attention to T2D. My plate is full enough as it is and while it sounded excellent (Does Melv ever do anything that isn't?) I just didin't have any interest in a 2D game.
But about 5 minutes ago while working on one of my design documents, I realized that the game I was designing would fit well in a basic 2D isometrical style.
Is this possible in T2D? The game would be pure 2D but draw in the isometric style. I have absolutely ZERO experience with tile based games, or even isometric based games. All my exp is 3D (or text based if you go that far back p) so i'm not sure the specifics really on isometric, but i'm picturing it as a basic 2D tile since you can't alter the viewpoint any.
Am I making any sense or rambling? :p
But about 5 minutes ago while working on one of my design documents, I realized that the game I was designing would fit well in a basic 2D isometrical style.
Is this possible in T2D? The game would be pure 2D but draw in the isometric style. I have absolutely ZERO experience with tile based games, or even isometric based games. All my exp is 3D (or text based if you go that far back p) so i'm not sure the specifics really on isometric, but i'm picturing it as a basic 2D tile since you can't alter the viewpoint any.
Am I making any sense or rambling? :p
#22
06/07/2005 (11:55 am)
Ok i think i follow that a bit better. Seems a bit out of my league ATM. Good luck with it though!
#23
The screenshots in the CW snapshot (by me) were carefully arranged so as not to point out the fact I'm not done with Z-ordering...lol : ).
I was thinking about using some sort of bubble-sort method on sprite collision, using some sort of GetLayerDrawOrder() function (which doesn't exist, AFAIK -- this is a subtle suggestion...), and that would work without having to monopolize all 31 layers.
06/07/2005 (11:58 am)
@Gary:The screenshots in the CW snapshot (by me) were carefully arranged so as not to point out the fact I'm not done with Z-ordering...lol : ).
I was thinking about using some sort of bubble-sort method on sprite collision, using some sort of GetLayerDrawOrder() function (which doesn't exist, AFAIK -- this is a subtle suggestion...), and that would work without having to monopolize all 31 layers.
#24
Thus far, I've only run into two problems. First, I built all of my objects (ground, walls, props, and actors) out of fxStaticSprite2D. This means that I get a framerate issue when I get too many items in the world. For instance, with a flat ground (no walls, props, or actors), I get about 90fps with 64x64 tiles. However, I get around 8fps with 128x128 tiles.
This seems odd to me, because if only 20x20 tiles can be shown on screen, it shouldn't matter whether there are 10,000 or 100,000 tiles in the world. Are they not being culled? Or is this not a rendering limitation?
Anyway, I saw some movies on a GG plan file that showed thousands of tiles animating, so I'm lead to understand that future versions of T2D will have better support for a huge polycount.
The only other problem I have is the sorting (which has already been mentioned). I get around it mostly by building in just the right order (for some reason, objects built before others always clip correctly, even when they aren't sorted). So, by making the ground before making the walls, props, or actors, nothing renders beneath the ground (and the ground doesn't overlap itself).
However, once you start moving actors and props over it, they will overlap each other. I wonder . . . what if you set the sort order for each one based strictly on it's row. Like Sortorder = y % 31; Out of every N rows, you would have N/31 that overlapped, but that might be worked around . . . . Hmmm . . .
Anyway, I started rambling, but I hope this helps somebody. :)
09/27/2005 (4:20 pm)
As it happens, I'm working on an XCOM-Iso game engine as well. I'll try to put up some screenshots when I get home.Thus far, I've only run into two problems. First, I built all of my objects (ground, walls, props, and actors) out of fxStaticSprite2D. This means that I get a framerate issue when I get too many items in the world. For instance, with a flat ground (no walls, props, or actors), I get about 90fps with 64x64 tiles. However, I get around 8fps with 128x128 tiles.
This seems odd to me, because if only 20x20 tiles can be shown on screen, it shouldn't matter whether there are 10,000 or 100,000 tiles in the world. Are they not being culled? Or is this not a rendering limitation?
Anyway, I saw some movies on a GG plan file that showed thousands of tiles animating, so I'm lead to understand that future versions of T2D will have better support for a huge polycount.
The only other problem I have is the sorting (which has already been mentioned). I get around it mostly by building in just the right order (for some reason, objects built before others always clip correctly, even when they aren't sorted). So, by making the ground before making the walls, props, or actors, nothing renders beneath the ground (and the ground doesn't overlap itself).
However, once you start moving actors and props over it, they will overlap each other. I wonder . . . what if you set the sort order for each one based strictly on it's row. Like Sortorder = y % 31; Out of every N rows, you would have N/31 that overlapped, but that might be worked around . . . . Hmmm . . .
Anyway, I started rambling, but I hope this helps somebody. :)
Torque 3D Owner Matthew Langley
Torque
using the apposing grid numbers I could set the objects layer directly to that... so if I did some sort of generation loop to generate this tile layer and assign each tile the appropriate layer number I could just check collision against the tile whenever a character moved and assign the proper layer to set...
Torque 2D depth works using layers and then ordering within layers... the advantage of this is you get a huge efficiency boost when checking for collision (or object picking) by masking only certain layers (as well as group options)...
for a fairly restricted game or simplistic one I can imagine I could do work arounds to restrict movement etc to keep the system from overlaping incorrectly etc. Though in the game I'm working on I'm really trying for a powerful system, so I need to plan out a s ystem that will do proper ISO ordering when the objects (like players and enemies) are moving
(extending the default 31 layers seems like it would create a very effective solution) though other ideas I've been throwing around would be doing seperate collision layers based on a tile setup, so all the collision will fit in accordingly with the layer movement, so I would just set up a system where I could paint in collisions