I've been working on lots of interesting side projects lately, which are great for developing useful skills or experimenting with [potentially bad] ideas that you might not be able to justify during work on larger projects.
I did another Ludum Dare game jam competition entry. Each time I want to try something new and challenging. This time I wanted to try a bigger collaboration rather than some new technical thing. I teamed up with my friend Fintan to do a Dublin-Luxembourg collaboration for a strategy game based on a Monty Python skit. My home Internet wasn't stable or reliable enough to cope with calls, which was a major problem, so we ended up more or less working on separate projects and magicking them together at the end.
Text rendering was a pain in the hoop - I found out here that smaller font resolutions with outlines don't really work well - you get one or the other. I ended up upgrading my font creating tools during this project, and experimenting with Valve's signed distance fonts algorithm - which is okay, but not really a solution to any problems I wanted to solve.
I got really worn out this time by the second day and it was an effort, but amazingly, we got it to work! You can play it online.
Some items on my "skills I feel like I'm missing list" that I'll try to work on:
Most of these things come out of little play-around libraries I build on Github or from other side projects. Basically I think I need to get some expert-level books to give me strategies for the cache and memory stuff I'm interested in, but they're not easy to find! If I remember way back, waaaay back to my 2006/7 grid computing job, the perf tool (and some related tools?) could give this kind of information.
I feel like there are better cache reporting tools out there, but I have no in-depth knowledge of what I can use. My profiler and debugger experience is pretty basic. I write pretty simple un-fragmented C code, which insulates me against most bugs requiring a debugging step-through, so it's rare that I find a debugger that useful. There's nothing as convenient as Visual Studio's debugger outside of Windows, so it's usually not worth the time investment of actually starting a clunky debugger like gdb.
I started experimenting with malloc wrappers for tracking leaks, and am curious about pooling and memory management. It's very easy to make mistakes once you dynamically allocate in many different parts of your code. Having access to run-time diagnostics of all types is always good.
There are platform-specific libraries for asynchronous I/O, but that's no good to me as I exclusively do OS-independent code. I don't mind compiler-dependent code so much. The GNU project has a family of these asynchronous IO functions in libc - aio_read() etc. I'll try these first, but it would be nice to have a human-written overview or subjective guide (GNU project pages read like they've been automatically generated by a very confused robot) before I start hacking at random functions. I may have to just try them all and see what happens.
A lot of older games spent a great deal of time with custom file compression strategies. I'm just curious about this for the sake of it. Disk space isn't really an issue any more. Although, diagnosing my OpenGL memory use - it's all textures in the GPU memory. Everyone is obsessed with compressing vertex buffer memory, but in my programmes that memory is absolutely negligible. I had trouble using texture compression extensions reliably on Apple OpenGL, but it's worth checking out I think. I'm no longer sold on DDS-format textures - I couldn't care less about the hard-disk space used by textures, and the lossy compression and plug-in crap required by paint tools are all a huge pain. Image loader libraries outside of DirectX do a terrible job of importing DDS files. However, compressing them on the graphics card would be handy if it works.