Tag Archives: optimization
Sorry about it, guys, but I’ve been really busy with real life stuff, and really incapable of making time to develop the game… Doesn’t help motivation is a tad low at the moment… Anyway, here’s hoping this week I’ll get back to normal! So, one of the complaints I had from the Game Dev Camp […]
What seemed like a simple issue to solve (lack of performance on low-end card because of ambient occlusion) ended up being much more complicated than expected! So, yesterday I decided to add a new system to be able to customize the level of ambient occlusion (in terms of resolution)… I added the system, but while […]
Today I was trying to test the game in fullscreen under Linux and I found a weird performance issue… In the initial cutscene, the game was running very slow (about 30 FPS), but when I moved the player to the left a bit (so more geometry on screen), the game jumped to the normal 60 […]
Today I added one optimization that was on the list for ages now: camera culling… Before you start shouting at me, there was already some camera culling being performed, mainly on the voxels (which is the biggest hit on the rendering), and I don’t believe in premature optimization… Anyway, since this was on the list, […]
Yesterday, while playing around with the beam cannon, I found some bugs on the collision detection, so today I dived right into that… The current method for raycasting on the voxel map is to do sampling: start at the beginning of the ray and walk through it, checking if it is a solid cell. Of […]
Tadam! Found the issue with the frame rate… The game is running at a good framerate, but due to some old code, the frame rate got locked to 50 FPS, which in a normal monitor that refreshes at 60 Hz causes some jumps in the image… “So, Covenant, you just had to change a variable […]
I wasn’t happy with the performance of the game in certain points, with drops to 30 or 40 FPS, as measured by Fraps… So, I decided to dust off my profiling tools and try to figure out where were the bottlenecks, but when I was running the initial benchmarks I got a very strange issue: […]
The shader system on “Cantrip” has some sophistication to it, and part of it is the fact that it generates the specific necessary shaders from a uber-shader (a big shader full of conditions) and a render environment that trims that uber-shader to smaller ones, depending on need… The problem with this approach is that everytime […]
…I got some nasty bugs due to the multithreading… Not totally unexpected, but I thought I was in the clear… I added all the code to clear areas… To be well below the 1Gb RAM used, I store only a maximum of 5 areas in RAM, then I evict them… First I had some problems […]
And another day without a screenshot… Mostly work behind the scenes, but it’s going along nicely… Already can generate areas in the background and they work fine… It’s a lot of work, but most of it has been smooth sailing (which is a bit unexpected)… Need to deal with some crashes (to be expected) and […]