Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

General thoughts and observations of gaming - with bits and pieces of game development.

Entries in this blog


Well duh!

I spent some time this weekend working on my little app project at home, which has progressed well - I'm now at the 7th milestone out of the 9 I set myself.

Currently the application is still quite small but is starting to develop the features I wanted from it - basically having written in the OpenGL shader support and then built a material system on top of it, including reusing a file parser utility my Doom 3 model viewer (which I really should finish!!).

Over the weekend though I managed to hit one those moments which had me seriously considering if everything I wrote was correct. Having started the project and just displayed a flat 2D poly to test the shader & material support it was time to move to displaying proper 3D objects ... setup the projection matrix, move the camera ... err ... where is the polygon?!

Queue a few hours of scratching head, putting in a moving camera and generally lots of code reading, only to discover the mistake by accident ...

See - when the app starts up you get a WM_SIZE message, which I handled to setup the viewport & projection matrix for the application ... what I hadn't done was to ensure that the OpenGL context had actually been created before hand. I only noticed this after accidentally resizing the application and suddenly everything appearing correctly on screen. Queue much head bashing on desk, 30 seconds of coding and recompilation ... and suddenly it worked.

Ever just had one of those moments?


Also - as a side note, be careful when trying to use Vertex Buffer Objects or Vertex Arrays with OpenGL. I had a problem today not long after posting this where I couldn't figure out why the app was crashing. Turns out that you need to be careful when specifying what arrays are active - and I'd left one enabled when I shouldn't have ... see - I still have bits and pieces to learn!




No boom today... boom tomorrow.

Captains log - 30/08/3006

For the past 4 days now we have been stuck in deep space, unable to travel anywhere and our power supplies running low. The backups are now running low after the main engines stopped working. Our best technicians are at work trying to correct the problem - but it seems like a mistake in the main operating systems of our ships computer have caused us a problem. Due to overuse of the holodecks we have run out of memory to run vital systems - I would order a purge of the main computer to correct the problem but it seems this would shut down the ship long enough for our air supplies to run out. Damn these people who write our leisure software - they seems to cause us no end of problems with their ever expanding desire to write realistic software. Apparently we would have been fine if we'd managed to get our planned upgrade while in space dock last month though ... but for how long?


One part of my job is to ensure that a game runs on a given platform within the constraints set by the console or our memory specifications. Consoles are easy since you have a limited amount of memory to play with anyway, so you know how much overhead you have to play with. PC's are a little more flexible due to various reasons - but its still nice not to push peoples machines too much - for various performance reasons, but mostly for not having to force people to upgrade their machines just to play a game.

Fighting to ensure that the game data, textures and model data all fit into a limited space is a very delicate job ... but then you have another thing to think about - fragmentation. All together its actually an amasing thing that games can be fit into the memory on some consoles and still have such a high visual quality.

From the start of a project you need to ensure that you have clearly laid out limits for all your data - and stick to it. Memory profiles of layouts and strict checking of exported data is needed - especially when your artists are prone to author textures in massive sizes and then scale them down at export - hopefully, I have seen exported data creep into the game where textures are still at their 2048x2048 original resolution.

Over time we have developed quite an extensive set of memory libraries and tracking tools - both in debug builds and PC side tools that help us to track all manner of allocations, deallocations and fragmentation holes. But it is still alot of work to keep a check on games and ensure they are running smoothly in all areas. Being able to track where and when an item was allocated - or even what deallocated it - is a major asset to identifying and correcting problems.

Its not that much of a problem with homebrew applications/demos, but its still good practice to watch out for the pitfalls and try to code yourselves a good set of libraries and tools to just see what its like to deal with these sorts of problems. Understanding these problems, their causes and solutions makes you much better programmer!

Another thing is that there are libraries/programs out there that can help you to profile your application to see wether you have memory leaks. Direct3D's debugging levels are also useful in that they will report if you have any objects still referenced/allocated when your application is shutdown. Make use of them :)




"And so it begins. You have forgotten something."

Isn't it always the way - you start something, learn alot but in the process, but end up forgeting something important.

Having been in the games industry for around 8 years now - its kind of hard to remember the happy thought I had the day I got my first job offer in the industry. Having finished university and worked for 9 months doing a job I hated, while practicing my coding and working on small demos in my spare time, that work had paid off. Then the actual reality of the job hits - the long hours, the stresses to meet deadlines and the outpouring of your energy into something that earns you little reward or you have little creative control over.

I have to say though, the last 8 years have been fantastic both in terms of what I have learnt and what I have done. I still enjoy working in the games industry, but I don't think I'm quite as enthusiastic about the games I work on. Which is probably why I've come full circle back to working on my own little projects in my spare time - not that I have much!!

I used to work with OpenGL alot before I entered the games industry - recently I've started to write a little application for windows with OpenGL. Now when I used to write programs there were no shaders or multi-texturing (yes - scary), so I've essentially started again from scratch with my knowledge and tried to make sure I don't fall into any pitfalls I remember.

My old projects used to take me a long time to complete because I didn't formulate myself a plan to follow, or objectives to complete. This is one of the things I'm glad I've picked up from my work. I sat down before I started and layed out a simple plan to follow that would be both measurable and have visible results in each step. This has helped me to actually get something up and running quickly - no screenshots, its not at that good a stage yet - and I have an actual goal to aim for with my next step.

So what am I doing here now - well, gamedev has been a massive resource that I have used alot to find out information and keep myself reminded of what I used to do. Now I'm back to pass on hopefully helpful information to others - and try to rediscover what I've forgotten!



Sign in to follow this  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!