/agdg/ - Amateur Game Development General

You should be using an quadtree or some other compression method for your tiles. You can probably compute some formula to project the mouse coordinates onto the world, since it's just a matter of finding a rotation matrix that can rotate a point on the screen to a point in the isometric plane.

What do you mean by a "second color attachment" ?

I swear I'm OP. Just on different machines all the time.

>What do you mean by a "second color attachment" ?

What I've got is an engine that has:

1. Several variations of a "Blit" function

2. One of these variations features a uint32_t as an "additionalData" parameter. Basically, this is data that will be passed to the second color attachment

3. The result is that the Framebuffer being drawn to has two Color Attachmenets.

The first color attachment is what's drawn to the screen after a second full-screen quad is drawn. I've done this so in future I can do some full-screen post-processing effects.

The second color attachment is a R32UI format texture. It's sole purpose is to take that "additionalData" parameter before and store it at a pixel level.

So. What that means is is that if I draw a tile, all of the non-transparent pixels that end up on the screen have the additionalData stored in that pixel on the second attachment.

The map is stored in a 1-dimensional array. This means each tile in my map has a single index within this array. Each tile is providing it's index when it is drawn.

End result is the texture bound in the second color attachment has a single uint32_t value in place of the usual RGB values for each pixel. This then allows me to "read" the tile index that each pixel belongs to (and some pixels might not be map tiles at all).

So mapping the mouse coords to map-tile-index becomes a single "read this pixel" from the buffer and retrieve the tile-index.

>You should be using an quadtree or some other compression method for your tiles.

Can you elaborate? Why would I need compression at all?

>You can probably compute some formula to project the mouse coordinates onto the world, since it's just a matter of finding a rotation matrix that can rotate a point on the screen to a point in the isometric plane.

I did this initially, but the problem is my tiles are like Sim City 2000 with the elevation. Or basically, I no longer have a flat plane, it's rugged.

>>31342

>Why would I need compression at all?

Why would you want your maps to scale in O(n) size? Lets say I want a map with 2048^2 tiles, and each tile is 16-bits. That's 8.3MB of RAM, which is pretty excessive especially for a kind of small map. If you use a quadtree you can seriously cut down on the amount of memory you're taking up.

Now I understand the problem a bit better: although I'm sure that you could write a simpler system for this, since for just tiles this is kind of excessive, it's not excessive if you want pixel-perfect selection of things like cars and buildings which don't just easily fit into boxes. So since your game will have all of that, it seems like a fine system to use, although I wouldn't have an R32 texture; that's excessive since you probably wont ever have UINT32_MAX click-able things on the screen at once, ever. Maybe an R16 would be better. Also I hope that this is just a buffer in memory and doesn't get registered into OpenGL (unless you are debugging it).

>>31347

I'm still confused about the quadtree.

Is this done so that adjacent tiles that share a type, e.g. "grass" or "dirt" can be stored as one value?

I'm planning on having a tile struct that features everything from type to "has road" or "is a building" (with an index to a building array or something).

In this struct case, every tile is different.

Would it be better to not use a single struct and instead have a series of arrays/maps?

>>31348

>Is this done so that adjacent tiles that share a type, e.g. "grass" or "dirt" can be stored as one value?

Yes, basically.

It's better to have a series of arrays rather than an array of structs if you want to apply DOD principles to your programs.

>>31350

This may not be normal, but I draw my map in a specific order so that isometric tiles "closer" to the camera are after ones "further" from the camera so that they overdraw any height-related things.

I haven't really looked into a quad-tree much yet, but is it easy to traverse in this order? Or would I need to re-imlpement my drawing to take z-order into consideration?

>>31351

There is nothing wrong with using overdraw to get the effect you want. I don't think you would have to re-implement drawing, basically you would have to make drawing work with groups of tiles at a time. Drawing the map as a quadtree would just mean traversing through the tree to find the relevant node for each position, and so it wouldn't have an issue.

>>31355

well you have a "window" onto the map that you can view, so, at each level of the quadtree, you could just continue iterating down the tree in the nodes that intersect with the viewing window, and drawing the tiles in that node if it is a leaf.

Here is some pseudo-code:

typedef struct{
    uint16_t low_x, high_x, low_y, high_y;
}bbox_t

typedef struct qtnode_s{
    int16_t type;
    struct qtnode_s *children; //assume that this array only has 4 elements: its a QUAD tree after all
}qtnode_t;

void draw_quadtree(qtnode_t *node, bbox_t *view_window, bbox_t *bounding_box){
 
    //in this example, a negative type implies that the node is not a leaf of the tree.
    if(node->type > 0){
        //draw the tiles associated with this node if it is a leaf
        draw_tiles(node->type, bounding_box);
        return;
    }
 
    for(uint8_t i = 0; i < 4; i++){

        //create a new bounding box that is one quadrant of the old box
        bbox_t child_bbox = derive_bounding_box(bounding_box,i);

        //iterate deeper into the tree if it intersects the view window
        if(bbox_isect(child_bbox,view_window)){
            draw_quadtree(node->children[i],view_window, child_bbox);
        }
    }
}

Which might give you the right idea, of course since this is a kind of basic example I didn't do an optimization like holding all qtnode_t's in an array, and storing an index into that array. But it should give you an idea of how to iterate through such a data structure even if I didn't explain any of the helper functions in detail.

>>31356

I didn't answer the last question: since you are relying on overdraw to draw your scene correctly, you would always handle the red subtree first and the blue subtree last for all subtrees. So you thought of how it would work correctly

>>31357

Right. I think I got it now.

But this compression really only works where there's sparse detail right?

Oh but different aspects of a tile can each be in their own quadtree.... like types, is a road, etc etc?