I haven't done a whole lot with my game engine stuff over the past week (been focusing on implementing GPU splatting for my research), but I decided to capture a video today. It's a little low quality, but it shows off the basics. For the most part, there's enough functionality in there to start working on a game, but I want to make the code simpler and easier to work with. Anyways, here's the video:
Currently I'm using Bullet for Physics, CEGUI for the in-game GUI, DevIL for loading images, OpenGL for rendering and a whole lot of boost to make my life easier. The windowing (Cocoa, Carbon, X11 or Win32) is my own. Eventually I might do the same for the image loading and in-game GUI so that there are less dependencies, but for now I don't really care too much about that. I'm planning out a simple game to make eventually, so look forward to that in the future. Perhaps not the very near future, but quite possibly by the end of the year.
Modeling 101
Okay, this is far from me giving you a 101 class on modeling, because when it comes to drawing/modeling/things of that nature I suck pretty bad. Nevertheless, I amazed myself at how quickly I could whip up a "stick man" model with a basic skeleton using Blender.
He's in a sitting pose, waving I think. Yeah, I have skills *cough*. Anyways, other than a crash here and there, Blender is a pretty decent piece of software. Some of the keyboard shortcuts are non-intuitive but once you get them down you'll be unstoppable.
That screenshots also shows off my integration of CEGUI into my WIP. I struggled with two issues that I'll share with people. The first issue was that you need to have the OpenGL viewport set up correctly when initializing CEGUI. Unfortunately my initialization was occurring before I called glViewport, but that was easily resolved. The second thing was that having any VBOs/VAOs bound messes up CEGUI (for now). Be sure to release any bound buffers/arrays before rendering things.
CEGUI is a pretty hefty library, but it looks to be incredibly robust and still actively developed. I loved how I could manually inject input events into the CEGUI system, which meant easy integration into my own windowing system. I noticed that some other systems used existing input libraries or hooked into something like GLUT or SDL. I also love the ability to use describe things in XML. I think CEGUI and I will get along quite fine until I decide to write my own UI system.
There was a bit of messing around getting things to link properly, but I managed to get everything working in the end. I'll finish off by pointing out qmake. I use it for my Makefile generation and I absolutely love it, mainly because it's incredibly simple. CMake is another option if you happen to be looking for one.
He's in a sitting pose, waving I think. Yeah, I have skills *cough*. Anyways, other than a crash here and there, Blender is a pretty decent piece of software. Some of the keyboard shortcuts are non-intuitive but once you get them down you'll be unstoppable.
That screenshots also shows off my integration of CEGUI into my WIP. I struggled with two issues that I'll share with people. The first issue was that you need to have the OpenGL viewport set up correctly when initializing CEGUI. Unfortunately my initialization was occurring before I called glViewport, but that was easily resolved. The second thing was that having any VBOs/VAOs bound messes up CEGUI (for now). Be sure to release any bound buffers/arrays before rendering things.
CEGUI is a pretty hefty library, but it looks to be incredibly robust and still actively developed. I loved how I could manually inject input events into the CEGUI system, which meant easy integration into my own windowing system. I noticed that some other systems used existing input libraries or hooked into something like GLUT or SDL. I also love the ability to use describe things in XML. I think CEGUI and I will get along quite fine until I decide to write my own UI system.
There was a bit of messing around getting things to link properly, but I managed to get everything working in the end. I'll finish off by pointing out qmake. I use it for my Makefile generation and I absolutely love it, mainly because it's incredibly simple. CMake is another option if you happen to be looking for one.
We got monkeys!
Yep, we do have monkeys. Blender monkeys, to be exact. I whipped up a simple loader for Wavefront OBJ models. Only loads the basic geometry now, so I have to work on the material stuff. One problem is my lack of a shader that does more advanced illumination, so that's something I have to work on. The two screenshots I've posted only do per-pixel lighting with Lambertian reflectance. I also want to make it so that my OBJ loader doesn't reproduce verticies with the same position + normal + texture coordinates.
I have also gotten things working with Cocoa. I do the event loop myself to make things easier, but it's all good. Full screen mode works in Cocoa too, but not in X11/Win32 because I haven't had the chance to do so yet. And with Cocoa I'm briefly gonna bring up the PIMPL pattern and how I made use of it.
The PIMPL pattern is a way of hiding an implementation from translation units other than the translation unit that implements some class. This is possible because you can have a class member that is a pointer to a type that has only been forward declared.
So why did I need this? Well I needed to store Objective-C pointers (i.e., NSWindow *) in my Window class. The problem here is that everything works wonderfully in Objective-C files, but everyone else chokes when including Window.h because they get confused by the Objective-C code in <Cocoa/Cocoa.h>. I couldn't really forward declare these Objective-C classes either, because again I have the same problem: Objective-C in a C++ file just doesn't work (as far as I know?). Enter the PIMPL. I forward declare a struct that will hold these Objective-C pointers and define that struct in my Objective-C implementation of the Window class. Problem solved, whahay!
I have also gotten things working with Cocoa. I do the event loop myself to make things easier, but it's all good. Full screen mode works in Cocoa too, but not in X11/Win32 because I haven't had the chance to do so yet. And with Cocoa I'm briefly gonna bring up the PIMPL pattern and how I made use of it.
The PIMPL pattern is a way of hiding an implementation from translation units other than the translation unit that implements some class. This is possible because you can have a class member that is a pointer to a type that has only been forward declared.
So why did I need this? Well I needed to store Objective-C pointers (i.e., NSWindow *) in my Window class. The problem here is that everything works wonderfully in Objective-C files, but everyone else chokes when including Window.h because they get confused by the Objective-C code in <Cocoa/Cocoa.h>. I couldn't really forward declare these Objective-C classes either, because again I have the same problem: Objective-C in a C++ file just doesn't work (as far as I know?). Enter the PIMPL. I forward declare a struct that will hold these Objective-C pointers and define that struct in my Objective-C implementation of the Window class. Problem solved, whahay!
Game Design
So, one thing that I've been working on over the past week is reviving my "game engine" that I started working on a couple of years ago. It's not far, but I'm currently happy with the way things are going:
Pretty simple, I know. Shows off some basic texturing and per-pixel lighting, but that's about all I got for now. Currently this is all done in OpenGL, but I've abstracted many of the concepts in such a way so that I could easily swap in a DirectX renderer. This is done at compile-time though, so that I avoid dealing with dynamic libraries.
It's pretty easy to get something up and running too. I just extend an application class, which takes care of some nitty gritty details for me (e.g., the game loop). With the help of some compile-time polymorphism, I just override three methods: initialize, update, and render. Also, input handling (keyboard + mouse) is currently implemented using mappings to boost::functions. These mappings are registered at runtime, generally in the initialize method one specifies.
There's plenty of work to be done, but I think it's a good start. Some things I need to work on:
Of course, there's a lot more than that -- Terrain LoD, Character Animations, GUI Rendering, Game Logic, Physics, etc -- but it's a start!
Pretty simple, I know. Shows off some basic texturing and per-pixel lighting, but that's about all I got for now. Currently this is all done in OpenGL, but I've abstracted many of the concepts in such a way so that I could easily swap in a DirectX renderer. This is done at compile-time though, so that I avoid dealing with dynamic libraries.
It's pretty easy to get something up and running too. I just extend an application class, which takes care of some nitty gritty details for me (e.g., the game loop). With the help of some compile-time polymorphism, I just override three methods: initialize, update, and render. Also, input handling (keyboard + mouse) is currently implemented using mappings to boost::functions. These mappings are registered at runtime, generally in the initialize method one specifies.
There's plenty of work to be done, but I think it's a good start. Some things I need to work on:
- Resource Management. Currently all resource management is done through boost:shared_ptr. In other words, there isn't really any "management" happening. I need some form of a manager that can load various assets, caching things as necessary to help with efficiency.
- Higher-level Primitives. Currently I send triangle primitives to the renderer, which is a little too low level for my liking. I'd like to pick a set of base primitives that are at a higher-level (e.g., triangular mesh, model, terrain)
- Deferred Rendering. I've always wanted to take a stab at implementing deferred rendering. I'd just love to play around with shaders in general and getting some fancy stuff on the go.
Of course, there's a lot more than that -- Terrain LoD, Character Animations, GUI Rendering, Game Logic, Physics, etc -- but it's a start!
Subscribe to:
Posts (Atom)