Okay, I''m awake now!

The Z-buffer idea I was talking about is similar to TANSTAAFL''s idea of using a colour map, except that you take advantage of hardware Z-buffering support by using Z writes to store the colour in the Z-buffer surface; this is essentially free on almost any newer graphics card, although it can be a little tricky to setup. It doesn''t let you calculate exactly where you are in a tile, although I''d be inclined to figure out which tile I''ve hit - and then figure out the exact location (pretty much the same way I do precise collision detection).

I don''t have any source code for this, yet. The idea only really struck me a few days ago, and I''ve been busy on other projects! However, the theory is relatively simple.

1. When you make your primary/back-buffer surfaces, also create a z-buffer. This is well documented in the SDK. You''ll want enough bits to be able to uniquely identify every tile on screen; 8 may not be enough for fine-grained maps. Fortunately, most cards support 16-bit Z-buffers natively.

2. When you are setting up your rendering states, make sure you switch off Z-buffer checking (isometric rendering relies on the painter''s algorithm, and you''ll get some odd results if you are specifying z values), but enable Z-buffer writes.

3. When you render a tile, be sure to set the z-buffer write value. IIRC, you can do this with one of the renderstates. You can also do this with a flexible vertex format (worth looking into anyway, since they let you have multiple texture positions in each vertex). Set the Z-buffer write value to a number that uniquely identifies your tile (being careful to take into account the bit-depth of the Z-buffer).

At this point, your Z-buffer surface is a nicely organized map of which tiles are taking up which pixels. If you include Z-writes for objects, walls, etc., you can have a *very* accurate mousemap! (IIRC, you can even have transparency supported properly, since transparent areas don''t have to write to the Z-buffer)

It''ll be a while before I can knock together a demo/example for this, but I thought I''d share the idea.

quote:Original post by Tom
Jussi, that''s a really great idea. It takes Tanstaafl''s color map idea a step farther. With a 3D card, I don''t think there will be any problem rendering twice as many tiles as normal to a separate surface. Grabbing the pixel color only once per frame should produce negligible overhead.

Thanks for the great idea.

Jonny: I think I understand what you''re saying now. Since both you and I are using D3DIM for our engines, you can understand why I like Jussi''s idea better. Still, thanks for the help.

Thanks, but as I said, it wasn''t actually my idea, though applying it to this context was. If you can find Game Developer Magazine''s September issue somewhere, it discusses this in more detail.

Remember, that you have to render the color map only when the map changes or scrolls, so you should copy it to a more safe place from the back buffer. If your map isn''t too big, you could even render the whole map at once and render again only when the map changes! Also, when you re-render, you should only render the parts that have change. That should be quite fast.

Just a note to avoid confusion: My name''s Jussi Lepistö, so Jussi is my first name, not an alias. Selkrank is my alias. You can refer me by whichever you like.

-Jussi