Archive for category Programming

Voxel Game : Shader bugs!

An amusing bug occured today when I somehow linked the main shader to the UI system by accident, resulting in this:

In other news, the entire Entity system is now XML driven.  Entities, their behaviors, polymodels, allowed actions, and statistics are now loaded from an XML file when the main game state engages.  It’s made the code a lot cleaner, and will make it very easy to generate new units and scenarios.  The XML currently doesn’t handle the world setup except for determining the size of the terrain, but I plan to add that.  I’ve also added some actual models beyond simple spheres/cylinders, but they’re still pretty simple.

I’ve attempted to introduce Frustrum Culling, but my algebra is still a bit rusty and it usually ends up culling the entire world out, instead of just the things outside the Frustrum.  The game also now has a win condition! If all the non-player Entities are eliminated, then a popup shows up saying you’ve won.

Tags: , , , ,

Voxel Game : Collision System

A few more things are hooked up in the UI to allow spawning entities for testing.  The attributes system is now able to handle a variety of values for each Entity including it’s HP, collision damage, if it collides at all, and if it is controllable by the player.  An optional Behavior is now in charge of creating the illusion of gravity, instead of all entities always being evaluated.

voxel_collisionsThe collision system is now implemented and optimized with an Octree, with actual collisions being evaluated using an Axis-Aligned Bounding Box for each Entity.  It’s much more efficient than a n-to-n comparision, but I still feel like it could be faster.  Perhaps collision spheres instead of AABB.

Voxel Game : UI Added

After a lot of fussing with TWL to get a UI working, I decided to create my own.  I hesitated to do this, as a UI system is practically an entire project unto itself. However the complexity of TWL combined with it only drawing in direct mode led me to engineer my own solution.  The custom solution takes advantage of Vertex Arrays and buffers the data rather than directly drawing the quads to the screen every frame.  A simple nesting pattern with individual offsets and event processing has allowed me to create a very basic UI with blocks of color.  Once the design of the game evolves further and the needed functionality is clearer, I plan to texture buttons and menus to make them look more elegant.


Part of implementing the UI was making a bitmap font that was renderable using Vertex Array Objects.  The BMFont format from has a simple and detailed XML output file that pairs with a generated PNG file.  After some experimenting with alpha blending and kerning, it turned out quite nice.  I allowed the code to scale the font to whatever size it needs, but bitmap fonts generally look best when they aren’t stretched or shrunk.  So currently there is some artifacting, which will be eliminated once the UI design evolves a bit further.

I also spent a good amount of time creating an ANT script that will correctly compile and package everything into a JAR along with the needed assets (textures, sounds, shader files).  All the assets are kept in a separate package structure, separated from all the class files, which helps me keep it organized more easily.  It took some trickery with classpaths to get things to run correctly both in Eclipse and in the compiled JAR.  In the end including the root of the project “/” in the classpath in Eclipse fixed most problems.

Other things that where done since the last update :

  • Added an audio system in a separate thread
  • Added OBJ file loading for loading polygon models
  • Increased flexibility of Entity attribute system
  • Added main menu, game creation, and in game UI

Voxel Game : Entities and UI

Several new features added! An entity system now tracks some little cylinders that throw off projectiles that damage the terrain. A particle system with a separate shader now renders when a projectile impact occurs.  The TWL UI library is being used to display some debugging information, and the camera can now be freely rotated.

Voxel Update : Terrain and Lighting

After a lot of trial and error and googling, I managed to get directional and point light shaders set up.  Somewhat simpler, implemented a Perlin Noise terrain generation algorithm. Next step, add some entities!voxelgame02

New Project : Voxel Game

I have spent a number of hours in the past few months learning the ins and outs of OpenGL via LWJGL.  It’s not as straightforward as drawing things to a Swing canvas, but it is magnitudes faster.


After I spent some effort redesigning my Silicon Life game for OpenGL, I decided to start on a voxel-based game.  I hope to make it an RTS, rather than a RPG or Minecraft clone.  So far I have the basic engine established, including VAO rendering of voxels, and grouping voxels into chunks for better handling.  The chunk rebuilding is multithreaded so as not to tie up the main thread when a lot of voxels change at the same time (which I anticipate).

Further optimizations include consolidating quads where possible to decrease the amount of data in GPU memory, but for now I’m pretty happy with the speed of it.

How not to do collision detection

Among other optimizations that need to be made, collision detection was one of the ones at the top of the list.  Doing it the brute force way is very crude.  The brute force way being take the list of objects on the screen, and compare it to every other object on the screen to see which ones collide.  This creates a rapidly escalating number of comparisons the program has to execute every cycle, which rises by the power of the square (n^2).

Last night I implemented the QuadTree algorithm to sort out objects and reduce the number of objects that have to be compared by determining which objects are close enough that they might intersect.  Things on opposite sides of the screen, for instance, can’t possibly intersect, so we can skip computing their collision.  It reduced the time it took for a cycle of the collision thread to complete from ~20-30ms for 200 creatures, down to an average of 4ms with 300 creatures.

Then I came into work this morning, where I had left a previous version of the program running over night to see how it handled extended running.  This version was using a ExecutorService and thread pool to help compute collisions in a brute force manner.  I’m still not entirely sure what happened, but this was the result when I came in this morning.  Note the execution timers in the top left.  The collision thread is now taking over 1,000,000ms to complete!  (that’s 16 minutes!)


Tags: , , , , ,

Silicon Evolution

Since working at Menlo Innovations, I’ve had the opportunity to greatly increase my programming skills, especially in Java.  As a result, I’ve spent weekends tinkering with new programming projects.  One of the things that has resulted from this is a little program that takes no user interaction, it just simulates a bunch of polygon “creatures” as they live, grow, reproduce, and die in a simulated world.  I was inspired by the classic “Game of Life“, and decided to make a life simulator.  I chose to make mine a little more complex, and it has some very basic natural selection and mutation added.

Here’s a screenshot:

Pretty happy with it so far. There is a separate thread for the FX, creatures, food bits (green), and the collision detection.  Each thread draws screen frames independently, which are then composited together to make the final frame for display.  Future plans are to make a wider variety of behaviors that the creatures can express depending on their individual “genetics”.  I also hope to add some more things to give this simple world of lines seem a little more depth.

Tags: , , ,