what am i doing
Arcane
- Joined
- Dec 24, 2018
- Messages
- 1,898
My bad, in retrospect my first sentence was ambiguous and it wasn't clear which one had the padding. The extra padding for a 32 bit unsigned integer was taking place on the GLSL side, in the vertex shader code, not the C++ side. So I had a 100 byte struct in C++ (no padding), and a struct that should have been (as far as I knew) 100 bytes in the vertex shaders, but didn't realize the struct in the vertex shaders was actually 112 bytes until I inspected it in RenderDoc. One downside of CLion (otherwise a really nice IDE) is that there aren't really any good GLSL plugins, so far as I know. I've tried a few. I can hover over a struct in C++ and see its size and the offset of its members, but not in GLSL__attribute__((packed)) in gcc, https://en.cppreference.com/w/cpp/language/attributes for the rest. C++ standard allows compilers to insert any padding they want into non-packed structures for alignment purposes, and it can differ between compiler vendors and even versions, causing binary incompatibility. Joys of not having a C++ ABI.While adding basic support for cities I ran into some maddening buffer alignment issues and eventually discovered that glsl has some different struct packing rules from C++; namely, a 32-bit unsigned integer, which takes up 4 bytes, actually causes the addition of 16, and not 4, bytes to the stride of the struct it's part of. I could tell pretty much immediately by the symptoms I was seeing (most objects being positioned incorrectly, which told me the object data buffer wasn't being filled properly), but I thought the problem surely had to be on the CPU side and spent a very long time hunting through my renderer with a fine-toothed comb.
If your code depends on exact size of a structure, you should add static_assert(sizeof(my_struct) == whatever_you_need). If you care about alignment as well, there's alignof.
EDIT:
Added city icons. They use a sampler2Darray and the above mentioned integer to decide which texture to use in the fragment shader (this added render object component may be used later for tile terrain). Currently they can simply be assigned to a tile. Some more work is required to fine-tune them; in particular manual placement of their exact map coordinates would be ideal, and the user also needs to be able to specify whether they are minor or major cities, for generation purposes. I also went back in and tried async loading again; it now works properly, though there is a bit of a pause when loading finishes and the renderer has to do a ton of merging and batching. The pause takes less than a second, doesn't set off Windows "Not Responding" and is only visible because I have an FPS counter running (otherwise the screen is static), so I don't think it's an issue. Though I do think I'll want to consider parallelizing the actual loading/import code itself (it needs to be done in a particular way to keep the IDs assigned to each imported tile deterministic between runs). I'd also like to show the actual progress rate while loading.
The tile overview window is aligned better and also now includes a close button that makes the cartographer class deselect its currently selected tile, instead of having to click outside the map to get it to go away. Minor, but overdue. Also made the climate window work a bit better, though it could use some sort of colour analysis to determine when text should be black instead of white. Actually, I'll need that for coloured buttons in general, so that should probably be a high priority.
Last edited: