Archive for the 'Programming' Category

Pick-o-Mania puzzle game in alpha

December 30, 2010

Hope you all had a great Christmas, and I’m looking foward to next year. I’ve already managed to roll out my first game this year, just before the year is over. It’s Pick-o-Mania, a straightforward puzzle game on matching colored pieces. It’s still in an early alpha stage for now…there’s no scoring system and menus aren’t in place yet. But most of the interaction is there, and I want to have it tested to see if it works properly (no crashes) with other people. Aside from what I just mentioned, some other game rules would be added, and graphics will surely be different in the final product.

This game was made on my graphics engine, which I will continue to develop as I learn more from this experience. Some of the features that the game uses from the engine are:
– Incremental loading (3D models are loaded as smaller chunks to keep a consistent framerate in loading screens)
– Entity handling and smooth movements of 3D models
– Per-instance culling (although it’s barely used in a game like this)
– Support multiple shader effects
– Color picking system (entities have unique ‘invisible’ color IDs that get detected when the mouse clicks on them)

Pick-o-Mania puzzle game

Wanna try it out? Download it here:

Simply click on the pieces that match two or more of the same color to remove them from the board. In the play screen, press “enter” to go back to the starting screen, and load the game again with a different set of pieces.

It’s for Windows only, and uses DirectX/Direct3D for graphics. So you may want need to download the Visual C++ 2008 runtime library, but I didn’t include it in order to save download time for those that already have it.

Hardware instancing in effect

December 18, 2010

Right now I am just testing the efficiency of the rendering code with thousands of instanced objects, and half of them being updated individually in rotation and position in each frame. There are over 770,000 polygons in the scene. At 854 x 480 resolution, my ATI HD 4650 card runs it at a reasonable 87 frames per second with all objects in view.

Currently, the engine is capable of hardware instancing, and frustum culling per instance. Which means only renders objects that fall into the camera’s view. No further scene optimization has been done yet.

In a future post I will go more in-depth on the components the engine currently uses. Meanwhile here’s a cool picture showing part of a scene of 4000 instanced objects.

Culling test


Quick summary of engine in progress

December 18, 2010

This game engine in progress is based on a few things I’ve worked on before:

– State management framework
– Various small Direct3D programs

The engine uses SDL for windowing and input, and Direct3D for graphics.

The state management framework is a simple way to keep track of discrete application states. Initially it was made to manage a stack of multiple states, but I found it unnecessary for my needs and simplified it to just have one state in memory and swap itand it has been made to only handle one at a time. It can be API independent, but I’ve currently written it to work with SDL, for initializing and shutdown, and for the GameState abstract class in handling input during frame updates.


Ah, a new start

December 18, 2010

I am reviving this blog for game development purposes. From now on, The 32 Bit Shell will be a game development blog until I move to another blog or change its name. And for starters I don’t like the name much anymore, but it will stay until I am set on something better…

What am I starting out with for now? As you may notice from posts a few years ago, I was exploring “rolling marble” games. I consider them a great blend of platforming action and puzzles. Well for a couple months now I have been working on a game framework to make one just like that.

Along the way, however, I may release other, more basic, games to tack on more progress and experience with making games. Developers too often get burned out by working on the same projects and sticking with the same goals. Making other simple games would be a good way to show progress of my coding and design process with game engines. The next post will be going into more detail in the actual start and progress so far with my work.

First video of Roll ‘Em Out

December 20, 2007

Having been busy with finals and other projects, I haven’t put much time into working on Roll ‘Em Out, but to keep things going, here’s just a short gameplay video of a still early debug build of the game. The score display is just a mockup- I won’t actually be using this in the final game.

The .obj file format, demystified

November 27, 2007

If you have ever thought of doing any 3D games programming, your first thought might be how the graphics are done. From the highly polished Final Fantasy games, to the abstract look of Geometry Wars, the answer varies. But more often than not, you would need to use visual assets that were made with other programs. For 3D modeling programs the formats widely vary, but out of all these, the .obj (or object) file format is the most generally accepted. Think of it like the PDF for 3D modelers. Most popular packages will support this format, so it’s easy to pass along without worring too much about what software others are using. The following text is an introduction for people that are not yet familiar with this format.

The .obj file format is one of the easiest to work with in programming 3D games, since .obj files are all text and the data is organized in a very straightforward manner. A typical .obj file would contain the following:

  • Vertex locations in x, y, and z coordinates
  • Texture mapping in u and v coordinates (optional)
  • Orientation of normals in x, y, and z coordinates (optional)
  • Face represented by a set of one or more indices

An .obj file can have either texture or normal data, but it must always carry vertex data. They are represented as an array of values, each line being a new entry in the array. This line starts with “v” followed by the coordinates. Optionally, you have lines for the vertex texture data (starts with “vt”) and vertex normals (starts with “vn”). Near the end of the file, the face data is represented, as a group of integers. Each line starts with “f”, and each number corresponds to the item on the data list in the order that it’s displayed. A line containing the numbers “1 4 3” correspond to the 1st, 4th and 3rd entries of that data group. There’s something important to note here: There is no index numbered “0”, so keep this in mind when parsing .obj files.

Each line contains indices for exactly one face, whether a triangle, quad, or other convex polygon. Furthermore, the indices can be grouped as single numbers, pairs, or triplets. The grouping depends on whether any texture or normal data is given. The following groups are possible:

"n n . . . n" - vertex location only
"n/n n/n . . . n/n" - location plus texture, or vertex plus normals
"n/n/n n/n/n . . . n/n/n" - location, texture, and normals

It should be clear that in a set of pairs or triplets, the location indices are listed first. Following that are the texture mapping coordinates and then the normal coordinates.

Finally, there might be some relevant information about grouping polygons into sets (lines starting with “g”) and usage of materials specified by the program that made the file (lines starting with “usemtl”). These may be used for programming model renderers, but they are not really crucial for displaying the geometry, so we won’t talk much about them here.

Well, that’s it for understanding the structure of .obj files. In a future post, I will show you how to apply this information to create your own .obj file parser.

Wanted: A Good Mapmaker

November 22, 2007

No, I’m not making a post about looking for good game mapping talent (though that wouldn’t hurt), but what I am talking about is the need for a way to make maps for my upcoming quick reflexy action-puzzler. My game has finally come this far to crave this need. So it’s time to do some extensive gameplay bug testing, which would be far easier if I can make any sort of game levels without having to go back every time to code in some more polygons and re-compile. It will be my first time making a game level editor of any sort, since my past projects weren’t complex enough to really need one.

I can take two approaches:
– Script the levels with my own easy-to-read syntax in a text editor
– A fully graphical editor, with a GUI, that produces the files (either text or binary will do)

Whatever way I choose I’ll have to build the file parser first. The graphical editor is more exciting but will take some more time. I’ve looked into CEGUI as a possible solution to building a level editor, which will then take advantage of having everything rendered in OpenGL and it will blend with the game as well. I really don’t want to tinker with the obfuscated (in my opinion) Windows API to handle the interface.

So I’ve already downloaded CEGUI and hoping to play with it soon enough. If anyone has any more suggestions, I’d like to hear ’em!

Some graphical goodness

November 17, 2007

Here’s a scaled-down screenshot of how the game is looking on the PC side of things. Looking more like a Monkey Ball game, right?


Collision detection is still buggy on the edges and on angled surfaces, but angled surfaces need a different way to handle movement. But for flat surfaces the game looks totally playable, and that gives me enough progress to move on to working on the graphics a bit. So I’ll be handling that with OpenGL on the PC. Porting OpenGL functions to the PSP’s own GU graphics API would take more time, as there are some slight but important differences. Setting it up is not too different, but there are some things OpenGL does better than GU, and vice versa. I’d really like to see what visual effects the PSP is capable of.

I want to release this game on both the PC and PSP platforms, so eventually I would have to separate the platform-specific code from the game code. Using a flag to change macros before compile time sounds like the best choice for doing this, and cutting down on development time. This way I can use the same code for compiling both versions and all that would be needed to do is change one flag. It’s a lot better than updating two separate projects, and the separate compilers I use for each won’t really know the difference!

Other stuff along the way

November 13, 2007

While working on my PSP game, I’ve been thinking of continuing a few not-so-related projects.

First is PSPMyAdmin, which was supposed to be a tool to help you manage MySQL databases. Due to the lack of having a server on the PSP, the program uses SQL files and parses them to produce an image of the database structure. So it’s like editing an actual database, without the need to login or access a server. I’ve put this off a couple months ago but I could be returning to it, and use the Danzeff OSK with it. It would really cut down on time to make an interface for the program. I haven’t played with the source yet, but hopefully it should be easy to change its appearance to blend in with my program a bit more.

The next thing I’ve been working on is a simple OBJ parser. It’s based off the code from PSPMyAdmin so I got a head start there. Currently I’m working out some bugs with producing some vertex information, but it is almost done. This tool would actually be useful in helping others produce 3D homebrew games.

Code snippet – frame of collision

November 8, 2007

I whipped this little program in about an hour which helps you find the collision point of a circle to a line, and the normal in which it reflects. This principle works the same in 3D. You must have Java enabled in your browser to view the applet. The blue points connect the shortest distance between both lines, and the light blue circle shows the point of impact projected from the current path. Refreshing the applet makes a new random surface.

View applet

You can view the source files here: CircleLineCollision.pde Vert.pde
The code is written in Processing, but it’s easy to adapt to most common programming languages.