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

About this blog

A journey through the trials and tribulations of a figure with no depth coding in 3D

Entries in this blog


A bit of design

So I've got my current implied architecture which, as I've said before, is pretty ugly. This is largely due to me putting very little design effort into the project before diving into code - the design that is there is usually only there because it seemed like a good idea at the time, and not because it was worthwhile in the bigger picture. Below is a new attempt at a generalized inheritance diagram for the framework I'll be developing:

Still ugly, but better than before

The idea is to push the "platform specific" stuff out as far as possible, so that we can worry about algorithms at a higher level. The above diagram doesn't necessarily do this properly (I envision a large number of revisions to this diagram over time), but it's at least a step in the right direction.

I've worked a bit on the application side over the past month or so, but a lot of my efforts have been on the scene graph side. This scene graph isn't really anything fancy - it's more of a glorified tree structure than anything else - but it'll help with organizing my scene in the long run, I think. Below is an incomplete class diagram of what I've got so far:

Scene graph goodness

This misses some things that are pretty important for drawable objects (like the material library, which is a static std::vector of materials owned by GraphicsObject), but gets the general point across. I've got the basic structure implemented already - the problem I am fighting now is trying to see why doing so killed my textures and display lists.

So, list of tasks for the time being:

1 - Fix texturing
2 - Eliminate all references to display lists (kind of done already)
3 - Implement vertex buffers/face buffers/tex buffers/normal buffers
4 - ensure objects are rendered as triangles
5 - Add simple radius-based collision detection
6 - Add dynamic LOD through use of multiple models
7 - Add support for collision model (simplified to collide quickly, and implemented with flexibility in mind. This may warrant its own inheritance diagram by the time I'm done)
8 - Add a model for shadow casting (simplified to draw quickly, currently using only planar projection shadows)
9 - Add support for multitexturing
10 - Revamp the object loader a bit so that it supports additional maps and shaders (far in the future).
11 - Add better shadow casting methods (Shadow maps?)




More on the project

So first off, this'll be post # 3 today. I highly doubt I'll be this active all the time, but I had a lot I wanted to get down and some spare time to do it in, so... w00t! Anyway, last post I promised a screenshot of my helicopter sim. Here it is, in all of its ugly glory:

A helicopter simulator (no link yet)

As I'm currently reworking my web warren into something more, well, presentable, I don't quite have a page for this gem yet. That'll be rectified when (if?) I find some free time. The rotors on the sim spin based on the amount of throttle applied, and application works with joystick input (throttle on the "Z" axis of a joystick, buttons 1 and 2 control collective, and 3 and 4 control throttle - I think) and is challenging to control - just like a real helicopter!

As I mentioned earlier, this was an extension to the earlier code for Adventures in Evil Stick Land, but the code itself ended up being... unclean. The project was written in under three weeks on top of another class and a full-time job (much like all of the code I write), so I wasn't so much designing a solution as I was flailing about wildly in visual studio hoping that I can get it working well enough that it doesn't break during the demo. The result, as you can imagine, was somewhere between a well-documented application framework and spaghetti with garlic bread, but it worked.

After I finished that course I had to do some cleanup and improving before I could even think of showing it to someone else (see the color scheme above? I hadn't yet figured out 3ds materials - that changed right quickly). So I made some improvements to the code base and did a hell of a lot of commenting. The drawing code itself was fairly compartmentalized, and didn't need to be touched too much (until the need to load a model with multiple components arose), so at the very least I had that going for me.

I know, I'm digressing a bit from the original topic of this post, which was... well... to be honest I didn't really have one. I want to venture a bit now into some design aspects of the application framework I am working with. I'll be using the day-night application mentioned below as my testbed app for the time being, to be improved as I find the need. The development of that resulted in a fairly messy program architecture.


I spent two years or so as a .NET architect, so I tend to resort to diagrams to get across my points. However, I'm out of practice - my diagrams may not follow any standards, nor are they academically... accurate, so to speak. Not to mention that Visio 2003's use of UML is atrocious - Why do I need to create a BS project to make a class diagram when all I want is to indicate a composite relationship? In any case, if my diagrams aren't clear, feel free to ask for clarification! Alternatively, feel free to offer corrections.


The end result of that coding effort is the architecture below:

New (and improved?) version

This is, to put it simply, bad. I'm being generous by calling my mishmash of code hidden in main.cpp an implied application class, and I'm also being generous in calling my std::vector of graphics objects an implied scene. I've left out auxiliary classes - the material library and the 3ds loader, among others - but I was only trying to get my idea across: the architecture needs some serious rework.

I've done some work in the meantime on adding a scene graph (very basic, more or less a tree of graphics objects), and defining an application base class, with a child derived for GLUT displays. I've also done away with display lists, as they are... extremely touchy. Not to mention that even the simplest of abstractions caused the display lists to stop working properly, as well as the textures (I'm still tracking this down). I took out the movement code, pending abstraction into a camera and player class, so the scene itself is pretty boring. In any case, here's the "improvement" in all of its glory:

New (and improved?) version

More to come as I work on the project, but for now I need me some sleep. I'll try to post an inital shot at my new architecture tomorrow - I have something in mind, but it has yet to be put on paper.





Hey all!

Welcome to my first real post in what I hope will become an inspiring journey of progress through the morass that is game development. Or, at the very least, a somewhat entertaining journey through the morass that is procrastination. In any case, let's run through the basics:

Who am I?

My name is Matt Billock. I live in Chicagoland in Illinois, I spend my days writing code for slot machines, and my nights as a graduate student at DePaul University, finishing up a master's degree in Computer Graphics and Animation. I am not a great coder, but I try. I've always wanted to work in games, and have taken every opportunity that's come at me to learn how to make games. The problem, however, was that starting in the early days I had an unhealthy focus on the graphics side of things, being more concerned with bringing up a window and drawing pretty pictures than actual functionality. I'm hoping to change that over time.

What am I working on

At the moment, I've embarked on a quest to create a quasi-complete game framework. I'm not thinking anything insanely huge like torque or ogre, but more something that I can use and combine into my own side projects and games. As I work on this, I'll be steering the project towards a simple driving game centered on pizza delivery, but that focus won't come for several more months, at least. I still have a significant amount of work to do on the basic engine architecture, not to mention needing some actual focus in terms of targeted API and system. For the moment, though, I'm doing everything in C++, using OpenGL, targeting the PC realm. Over time, as my experience grows, this may change (most notably to DirectX and D3D), but for the time being I'll stick to what I know.

What am I starting with?

I'm starting with a set of code that, at first glance, was an unruly warren of methods and classes, with a heavy approach on the procedural side. Below is a screenshot from the first thing that I wrote using some of this code:

Adventures in Evil Stick Land

As I have matured as a coder, I've moved far beyond the coding skills demonstrated by the fairly-simple 3d RPG shown above, but I still look back with both pride and fondness on this code, as it was the first 3D project I completed on my own. It is, however, long overdue for an overhaul.

As time has elapsed, the code base has evolved. I spent about two years working on other stuff, mostly due to the rigors of my Master's, but around last year I got the opportunity to pull out that old code base, dust it off, and give it another go. This was thanks to one of my more recent classes, which was focused on animation. I had the opportunity to add a bit more object orientation to this new code, as well as incorporate a simplistic mesh structure and a 3ds model loader. The code was still kind of ugly, due to the effort I put in for the assignment, but the result was all that mattered. For that project I implemented a helicopter simulator in C++, using fake physics and allowing for joystick input.

screenshot of helicopter simulator pending, need to locate a good screenshot

Overall, while technically lightyears ahead of the original code for the 3d RPG, this simulator still suffered from Really Ugly Syndrome, or RUS for short. I spent some time working on it a bit over the next few months, but without the impetus of a project there wasn't as much motivation as I would have liked. I was able to make a lot of improvements, though - especially to the model loader which, in the helicopter simulator, was unable to load materials or models with multiple objects successfully.

The next project I worked on helped me to grow the code base by leaps and bounds. It was for a seminar course that was focused on advanced lighting, but otherwise was wide open in terms of work target. I partnered up with a fellow classmate, forced my burgeoning code base on him, taught him how to work with it, and we pounded out some good stuff. See below:

From Dusk 'til Dawn

This is a day-night cycle simulator, with moving shadows and transitioning light and sky. The goal was to do it in real-time, with a target FPS of 32 (which we hit on the demo machine - the above is from my significantly underpowered laptop). It's written in Visual Studio 2005, so it includes the .NET framework (only because I can't get the IDE to not compile the framework in), and uses GLUT for window management. It's from this point that I am starting, working on making the code as abstract as possible.


I understand that there are already dozens of projects on the web doing what I hope to do, and many of them are much better than I can ever hope to make mine. That won't stop me from doing it anyway. The end goal of all of this is to make myself a better game developer, and if reinventing the wheel does it, then so be it. If all else fails, I'll still have a pretty hefty code base to show off in interviews and the like.

Where am I headed now?

My current task is to decouple all of the API-specific stuff from the general interface, making it a more object-oriented kind of environment. And let me tell you - there are some really ugly hacks necessary to use vanilla GLUT in an object-oriented environment. The current class I'm taking (my last, w00t!) is another seminar course with a final project, based around real-time optimizations and shader programming - for the next three months or so, it'll be my goal to incorporate the stuff I learn in this class into my code base, and hopefully do it in such a manner as to not make it overly challenging to abstract the code base to DirectX or to remove the GLUT code. Time will tell how successful I'll be, but you can be sure I'll do my best to post my results here for accountability.

Oh, and in case you're wondering, I'm hoping to make the pizza delivery game be my final project for this course. I don't envision it being complex enough (in terms of graphics requirements) to meet the requirements, nor do I delude myself into thinking I can finish the sheer amount of work necessary for that undertaking, but I do plan on moving the code base closer to this end result through modification of the existing day-night simulator, which I will be using as a test app for my framework for the time being.

In any case, I'm out for now.



Sign in to follow this  
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!