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 or 512×512, it disappears… Same happens when I use 1600×900… So what’s the difference? The Y-size… 1024 is larger than 900, so it must have something to do with that… The problem happens on the 124 top lines (which are the 124 lower lines in OpenGL, since Y grows up there). To confirm, I lowered the game resolution to 1280×720, and then 304 lines disappear, so I’m pretty sure the problem is related to that difference… First idea was the viewport, but that’s set correctly, as is the scissor rectangle. So it’s maybe a driver issue, but I can’t find no reference about it anywhere (and it seems to be something people would talk about)…
My current guess is that while the depth test is disabled during that render, there’s still a 1280×720 (or 1600×900) depth buffer bound, so maybe that will cause issues… So tomorrow I’m adding a 1024×1024 depth buffer to that step, maybe that will solve it…
Now listening to “Battle Hymns” by “Manowar”
Link of the Day: This is super awesome, more please!
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 dark area on the top of the screen?
Basically, after a lot of work, I found out the problem is that the top area of the SSAO buffer is black… No idea yet on why/how that happens, but it has something to do with the step in the code where I compute the SSAO term from the normals/depth…
Now listening to “The Divine Wings of Tragedy” by “Symphony X”
Link of the Day: Great video from CppCon, Bjarne Stroustrup talking about good C++14 programming guidelines… A bit slow at the start, but more interesting towards the end…
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;
// Resize buffer
delete _vb;
delete _ib;
_vb=create_vertex_buffer(n_part*4);
_ib=create_index_buffer(n_part*6);
_allocated=n_part;
}
}
Basically, this piece of code initialized the vertex buffer for the particle system… If there isn’t one, it initializes it with the number of particles (plus a fixed number, so it has room to grow). I need 4 vertex and 6 index per particle, so that’s why I multiply there…
Can you spot the error? Tick, tock…
Well, imagine that in the start, you have 40 particles on the buffer… Then on the next update, you have 100… This should grow, right?
Yep, it does, but not enough… Since I’m doubling the size of the array per iteration, instead of looking at the particle count, I’d grow the array to 80 particles, not the necessary 100, but the rest of the code would write 100 particles…
So, buffer overflow… Ideally, this should cause an access violation (because I’d be writing in memory that didn’t belong to my process), but in most of cases in the game flow, I’ll be writing on top of other memory in the same process, corrupting the data structures necessary for the heap to allocated and free stuff properly… So this error would only be detected when an allocation/deletion goes wrong (which might be seconds after the actual corruption takes place)…
The corrected 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=_particles.size()*2;
// Resize buffer
delete _vb;
delete _ib;
_vb=create_vertex_buffer(n_part*4);
_ib=create_index_buffer(n_part*6);
_allocated=n_part;
}
}
This was a nightmare to find… But it’s still not all… I’m pretty sure I still have heap corruption issues, since I still have crashes (it just takes way longer!), so I’ll have to see if I’m not doing this same silly mistake in other places (all hail the twin gods of Copy and Paste)…
Finally some good news… I’ll be away from the Internet for a few days, but I’m taking the computer to continue development, so there might not be a blog post for a couple of days (unless I upload it with my 3G connection)…
Now listening to “Alternative 4” by “Anathema”
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 far:
-
Can only trigger it in OpenGL
-
It has been present for a long time
-
It’s compile dependent: Sometimes I compile the game and it doesn’t happen, but if I do a full rebuild, it always happens (I think that’s why the GameDevCamp build worked fine over there, pure luck)
-
If I comment the particle system code that generates the vertex buffers, it doesn’t seem to happen
My main suspect was the VAO usage, but I commented that whole code (so that I create and destroy the VAO every single draw call) and it still happens… The current suspect is the particle system, but this has been in since the very beginning (there weren’t many changes there), and I’m looking at the code and I don’t see anything wrong with it…
If I had my Linux box available, I could probably use Valgrind to figure out the problem (although I haven’t touched that in ages now!), but as I only have the Windows machine and all the recommended applications don’t give me any information I can act upon, I’ll have to make due…
Now listening to “Iron Maiden” by “Iron Maiden”
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 not on D3D… I’ve focused on the differences, but I can’t see anything that might explain it…
Thought it was the API usage (using something wrong), but tried using CodeXL (AMDs evolution of gDebugger, much nicer), but it didn’t throw anything unusual…
Now I’ve reactivated my SVN server (was disabled because I don’t have space at my home yet for it, it was at the office at my ex-job), and I’m trying to go back to figure out when was the problem introduced, hopefully that will give me some hints on what’s wrong! :\
Now listening to “Haven” by “Kamelot”
As the title indicates, this was a completely wasted day…
Was going to fix more stuff from the feedback list, but instead got a heap corruption bug somewhere that I couldn’t manage to fix…
A heap corruption bug happens when you write to a position that was already released (or out of bounds)… Problem is that it usually it only gets detected when that memory is reallocated, which means you never know who is behaving badly…
This is a recent bug, but none of the code I’ve added explains the bug (I’ve gone through it a lot), so it’s more likely a question of exposing the bug than actually creating the bug…
I’ve tried using something like “Application Verifier”, but it quadruples or so the memory requirements of the application, which means that I’m running out of RAM on my 32-bit application so I can’t test anything with it (without porting the code to 64-bit).
One possible debug option is that I fire this up under Linux and use Valgrind to test it, since it should detect this, but I don’t have access to the Linux machine for now (and in the next couple of weeks)…
My main guess on the source of the problem is the multithreaded code writing on a pointer that’s being deleted… But no idea on how to actually test or find out where!
I’ll keep at this, but I’m getting discouraged again with the game… I feel it will never be ready for my standards! My head is also not fully “in the game”, since I’m looking for a job and I have some proposals already, and I’m not sure they’re what I want at this stage in my life…
Now listening to “Crack the Skye” by “Mastodon”
So today I finished the new and improved initial area, hopefully players will have a better sense of “direction” with this one and will provide a good and entertaining introduction to the game…
Still have a ton of stuff to add based on the feedback received, most of it quite simple, albeit time consuming… Some days should be enough to finish that and get back to my “normal” development…
Now listening to “Watershed” by “Opeth”
Link of the Day: This is very neat… Make your own zombie apocalypse, based on science: http://mattbierbaum.github.io/zombies-usa/
As the title indicates, today I spent my development time working on the new and improved starting area…
Some of my ideas related to it were ok. It was a good idea to get the player started in a more exciting area before dumping him into the exposition, so he has a taste of what’s to come…
The problem that I identified at the Game Dev Camp was that the area wasn’t that interesting, so I took some steps to flesh it out, make it more interesting and challenging and to guarantee the player gets “through” it…
Still need to do some scripting to complete it, and test it out…
Now listening to “Port Royal” by “Running Wild”
So today I carried on with the work from yesterday (and that I’ll probably be doing the next few days!), which is to fix/polish stuff based on the feedback from the Game Dev Camp.
So, quick list for today:
-
Drones now have a larger hit radius
-
Game no longer waits 5 seconds before opening a console (problem was with the fact that GLFW only updates the key state if the message pump is running, which it wasn’t)
-
Log and email consoles are now spread apart (players would get the tutorial message saying to check out the email console and they would almost always use the log console instead)
-
Navigation mesh now gets rebuilt when the forcefield is up (so enemies can no longer pass through it)
-
New game now resets the health points
-
Home beacon now stops working if player dies midway
-
Home beacon stops charging if player jumps
-
On Skydancer, the planet no longer has ugly looking ambient occlusion
This last one was a bit more work than I actually wanted, but it looks way better (top is before, bottom is after):
Now listening to “Carved in Stone” by “Rage”
Today was a bug-fixing day… Most of my time was spent trying to reproduce stuff I saw happening in the Game Dev Camp (some of them were tricky to reproduce, like navigation mesh stuff, others were quite trivial)…
Fixed a couple of crashes on “New game”, some stuff related to memory not being freed correctly when there was a “Game Over” situation and some spawns on inaccessible areas (although there might be more of these)…
Now listening to “Undertow” by “Tool”