Square Tile Conundrum
Ok Square Tile engine. With a diamond tile system we know when
to draw sprites. Occlusion is basically for free when we render
in the correct order. However a Square tile system has the block
filled in. It could have a bit of floor and a wall or just
about anything.
Ok we can load up our map and use vectors to describe the
various height''s and so on. We could then clip our sprites against these vectors. However compilcated items like a tree
with lot''s of pixel gaps and our sprite just so happens to be
walking behind it would not suit a vector system. So some
kind of overlayed Zbuffer.
Baldurs Gate II is obviously a square tile system. Do they
export the Zbuffer from the renderer and use this? Looked at
MiniVerse they use vectors for collision and so on but not sure
how the occlusion is handled.
1. So basically paint my tiles into the buffer
2. Check intersection of my sprite with the vectors
3. Clip them
4. If intersected a Zdepth sprite then clip it to the zmask
(slow)
Or use a full Zbuffer from the blocks. (Memory intensive).
Could cache the tiles from disk. Surely Baldurs Gate II can''t
be holding the entire data in memory so a cache would seem
to make sense.
Oh and the reason that I''m choosing square tiles is that we
have got one hell of a rendering setup. Maya II. Basically the
artist is creating one beautiful large picture. I split it into
tiles and then cache it (not proven yet )
Sorry it''s a long post but this is driving me nuts and I would
appreciate any thoughts.
Cheers
The shape of the tiles is not the issue, the viewing angle is. In a top-down engine, the only simple way you know what obscures what is to have some sort of z-ordering for each object. Obviously you can just draw your basic terrain first, but overlays would go in order.
I would suggest you take a look at the "Pre-Rendered Bitmap" thread in the graphics forum. We''ve been talking about these issues for a few days now.
quote: Original post by Kylotan
>The shape of the tiles is not the issue, the viewing angle is.<
I didn''t really explain myself properly. Basically there is
no overlay in this system. It''s just a picture. Basically you
have to supplement the flat 2d screen with extra info like
vectors and the such like which describe depth.
It''s a bit like composting software. All the compositor has
is the picture and a zbuffer. You supply it with another picture
and a zbuffer. That way you can interleave the two images.
The major benefit is that the artist can practially draw what
they like. The downer is entering the depth info after.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement