[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]

/agdg/ - Amateur Game Development General

AGDG - The Board
Name
Email
Subject
REC
STOP
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
Archive
* = required field[▶Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options
dicesidesmodifier

Allowed file types:jpg, jpeg, gif, png, webp,webm, mp4, mov, swf, pdf
Max filesize is16 MB.
Max image dimensions are15000 x15000.
You may upload5 per post.


Welcome to AGDG, keep working on your game anon!
See also: /ideaguy/ | /vm/

File: 419df72c43fd97a⋯.png (29.04 KB,800x332,200:83,OpenGL_logo_(Nov14).svg.png)

f38ee6 No.31335

I'm pretty good at OpenGL and engine dev. I've been working on a city builder game in the style of Sim City 2000.

Does anyone know a good efficient way to make a mousemap for an isometric engine?

I've done it by writing integer values to a second color attachment that correspond to the tile index in a map array. But I can't help but think there's a simpler way.

____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

905efb No.31339

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" ?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

f41352 No.31342

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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

905efb No.31347

>>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).

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

f38ee6 No.31348

>>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?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

905efb No.31350

>>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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

f41352 No.31351

>>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?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

905efb No.31354

>>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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

f85576 No.31355

File: 728c1556cb7e469⋯.png (11.25 KB,396x262,198:131,ClipboardImage.png)

>>31354

I must be daft.

My drawing routine looks like:


for(std::size_t y = 0; y < m_city.m_mapSizeY; ++y)
{
for(std::size_t x = m_city.m_mapSizeX-1; x != static_cast<std::size_t>(-1); --x)
{
auto tile = m_city.GetTile(x,y);
// calculate the drawing position then draw
}
}

I guess, I don't understand how I could iterate through tiles? Would I instead start with the Red Quadrant, and draw it, then the Green, then Yellow and then Blue? And basically if a Quadrant has sub-regions, I would draw them in that same order?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

905efb No.31356

>>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.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

905efb No.31357

>>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

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

f38ee6 No.31358

>>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?

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.

905efb No.31361

File: 749d3300ac83558⋯.gif (4.83 KB,348x348,1:1,quadtree.gif)

>>31358

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

Yeah, so if every tile was different it would be wasteful. If the terrain is too noisy, then the quadtree will take up more space. If you have low detail terrain surrounding your city, then it would make sense. As long as you have enough groups of similar tiles, it saves space. For example, a map of a desert, or water tiles.

Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.



[Return][Go to top][Catalog][Nerve Center][Random][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / random / 93 / biohzrd / hkacade / hkpnd / tct / utd / uy / yebalnia ]