Archive for February, 2010

Gravity and lighting

Saturday, February 6th, 2010

I added some basic lighting and…. quite frankly it looks terrible, but lighting isn’t the point of the exercise. It’s enough to have a point light that visually aids the 3d perception of the spheres.

The end idea is that a number of balls need to bounce around a box, colliding off each other and off walls until they come to rest. A few of my prototypes in order…

  • Display a Sphere in the world.
  • Gave the Spheres concept of velocity. The Sphere would move down (y-axis) forever.
  • Added a ‘ground’ stopping point. If the Sphere’s y position was 0, it would stop. This does not take into account different sphere radii.
  • Inverted the Sphere’s velocity when it hit ground. Now it would drop, bounce, and fly upwards forever.
  • Time for gravity! Add a 9.81 velocity every second to the Sphere (spread out over frames of course). The Sphere would now accelerate towards the ‘ground’, and slow its ascend.
  • Modelling this as an inelastic collision, some energy will be lost. To keep the model simple, the Sphere rebounds with 80% of its initial velocity.
  • As another test, started the Sphere with an initial velocity of 0. That is, it will fall to the earth naturally through gravity.

It’s proving to be a fun model so far. Next, going to put some primitive planes in place so that the box will be visible and allow it to bounce off each one.

Physics simulation refactored

Friday, February 5th, 2010

Sadly I was unable to put as much work into the simulation last night as I’d have liked. However with a little time to myself this morning and a clear head, I managed to neaten up the code from Wednesday. The current design consists of a Simulation which constructs  a Window object, and a Renderer object. The nitty gritty of directX is all packaged up in the Renderer. Presently, still as a prototype, the Renderer creates and owns one sphere for testing purposes.

Next, the sphere can become a class that the Renderer knows how to draw.

Basic physics system

Wednesday, February 3rd, 2010

Earlier today, I received a request to create an appropriate application and so put project Rogue aside for this week. My task, a simple physics system consisting of bouncing balls. Whilst I am experimenting with SDL on Rogue at the moment, I feel more comfortable using C++ and DirectX for this task.

Recalling back when I was first learning rendering at university, decent tutorials and example work using DirectX was not easy to come by. My hope is to produce a simple, clean example that I can share in the future. Looking ahead, I set my sights for the evening on building a simple application that rendered a single sphere.

Having been working extensively with Java over the past few years, I have become very used to object oriented programming and it feels natural to follow this style in C++ as well. The evening’s work is successful, and my sphere renders as a simple wire-frame, no lighting, nothing else. It’s a good baseline for the work to begin in earnest tomorrow, first starting with some refactoring to more clearly split responsibilities into better defined classes.

There does seem to be substantial overhead setting up the required components in DirectX for such an example. Perhaps tomorrow I can extract the more common routines out to something a little more reusable.

Project Rogue

Monday, February 1st, 2010

In this place you will find a few collected thoughts in my casual development project, as well as a general progress log.

First, a current progress report. A while was spent setting up my IDE and experimenting with a few external libraries. I needed some variation of Curses for implementing text input/output, and I also wished to develop using automated unit tests. I eventually settled on using TinyCurses and UnitTest++ as they seemed the most lightweight and simple implementations.

Development started with keeping things simple. Rendering a hard-coded map, accepting user inputs, driving a simple ascii @ around the text-based maze, and eventually a basic system that would present game-world messages to the user. I was impressed with the simplicity of TinyCurses in assisting with these basic tasks, although by default did not register numpad input. My general development cycle of unit test, implement, refactor, repeat served me very well. I was pleased at how my experiences with Unit Testing at work in Java translated back to C++.

So after the briefest of summaries, I have the most basic skeleton of a  roguelike. The next step is to ensure all of the code is of an acceptable standard and refactored into a comfortably usable state. Then, develop the map proper, changing it from a set of hard coded strings to a layered map that allows for user interaction.