For those who are curious, this is an example of that graphical flicker bug I was talking about. It’s as though OpenGL is occasionally just ignoring part of the draw calls I send it.
All of the elements here are static geometry; in fact, the text label is stored as a single array of read-only vertices and submitted to OpenGL as a single unit. Yet sometimes it only renders some of those vertices and ignores the rest (and it always does this exactly 8 quads at a time)
I’ve found very little pattern to when it occurs, though it seems much more likely to happen to the minimap than anywhere else (although when I removed the minimap from the screen, it started happening on other parts of the screen instead…)
I mean, my knowledge of low-level GPU operations is very rudimentary, but I was pretty sure that draw call ordering of overlapping geometry should be 100% deterministic and so it should be impossible for early draw calls not to have occurred while later ones have (if, for example, the buffers were being swapped prematurely). And it should likewise be impossible for only parts of a single draw call to be executed (especially when they execute correctly 99.9999% of the time) and yet here we are….
It didn’t occur at all on my old computer, it seems not to occur on a friend’s computer (though I didn’t have the chance to investigate so thoroughly) and those are about all I have access to to test. It may just be a driver glitch on my system (and certainly the degree to which it’s inconsistent and unreproducible suggest it may not be my fault….) but you’d think I’d see problems with other games if that were the case. It might be a mistake on my end that only produces surface-level effects on this GPU, but is still always ‘wrong’ (but hell if I have even the slightest idea of what this could even theoretically be….)
Figure I outta post some holdover material, so here’s opengl render of the van from the previous ADPAB post. Got lazy on texturing, but I figured the flaws wouldn’t be noticeable from the proper angles and lighting. Plus I’d spent far too long on the model and just needed it out the door.
Just checking in, as I haven’t posted anything in a few weeks, I’m currently in the middle of completely rewriting the game in C++ and it will likely be about a month or so still before visual progress resumes.
To make a long story short, some of you who’ve played the demos in the past may have noticed that the game occasionally stutters, freezing for a split second in the middle of gameplay. This is caused by a memory leak in the collision code for characters that I was putting off, having recently tried to fix it I realized there was no straight-forward way of fixing it without spending weeks studying Bullet and JNI just to get a single physics object to reset its state properly.
It had been my intention to rewrite the engine in C++ after the initial release as it’s the only way I’d consider doing any kind of multiplayer. While I’m still on the fence about whether I’ll actually add any network features, I was never going try doing it with LibGDX. As I’m now rewriting the whole thing anyway, I can plan around this future capability when I’m putting the game back together.
Hlaalu Brassguard got heavily redesigned recently. Hope this would be the last iteration of these guys. I took inspiration from traditional European armors pattern and added some Dunmeric details to it. The most western-oriented house must have most western-oriented armor. A bit of cargo-cult.