Today I kind of had some time to work on “Gateway”, so I started working on loads of bugs I’ve found while working on the prototype. Most of the ones I tackled today were pirate lair related… It was some bad spawns, the whirlwind laser wasn’t hitting the player, cannons were firing on the wrong […]
Today I squashed an old bug… I had a cave planet whose generation ended up being this: So the player couldn’t get out of the initial drop zone! I have a lot of code to try to prevent this sort of thing, but sometimes some stuff falls through the cracks… That’s actually one of the […]
Or sort of… I came to the Netherlands to finish some work for my previous employer, just tying loose ends, so I don’t have much time during this week to work on the game… Still, I’ve been making some progress, and most of the stuff called out on the Game Dev Camp are fixed and/or […]
Busy squashing bugs… Most of them are quite small stuff that was more nuisances than actual bugs, but in the last couple of weeks I’ve found some “big” stuff. One of these was some conditions where the story planets couldn’t be generated properly, which meant the game would get stuck in the generation phase… That […]
So the problem ended up being the fact that the z-buffer associated with the render target wasn’t the same size, so it got clamped… It still smells of driver bug in fact, since depth testing, writing, etc, was turned off, but it was more or less simple to fix: just create a 1024×1024 depth buffer […]
I think the problem I’m having is driver related… Or at least this driver is a bit more strict than normals and I’m using OpenGL wrong… So, the game window is 1600×900 (when I’m developing, you can choose when playing). When I use 1024×1024 SSAO, you get the problem below: When I use a 256×256 […]
I’ve been away for a few days… During that time, I sorted some of the issues from my Game Dev Camp, but mostly I spent my (very little) time trying to figure out a graphical bug in the game. It only happens on OpenGL on my laptop, but it’s still super annoying: You see that […]
Well, it seems the bug is almost fixed… As I suspected, it was a buffer overflow somewhere, but the place was unlikely: the particle system… In particular, this was the offending piece of code: if (!_vb) { _vb=create_vertex_buffer((int32_t)(_particles.size()+PSBUFFER)*4); _ib=create_index_buffer((int32_t)(_particles.size()+PSBUFFER)*6); _allocated=(int32_t)_particles.size()+PSBUFFER; } else { // Check if they have space if ((size_t)_allocated<_particles.size()) { size_t n_part=_allocated*2; // […]
That might be a bit of an exaggeration, but I’m having real problems identifying the source of this problem… I think it has been present for a long time, but wasn’t visible, since I went back almost 100 revisions in the source code, and I can trigger it… So, this is what I know so […]
No real update for today… Spent about 3 hours trying to figure out where the heap corruption is happening, with very little success… The only thing I’m sure is that this must be OpenGL-code related, since it doesn’t happen in D3D (or if it happens it’s later)… I can consistently trigger this in OpenGL, but […]