Star developer diary

Star developer diary

About Star

Star is an hobby game developed by me for the purpose of improving my game development skills with OpenGL and C++. It's using the SDL library.

It's an arcade game where the player controls a spaceship and dodges incoming asteroids on its way to Earth. The latest playable version can be found in my portfolio.

3D-feel Starfield

CodingPosted by Marie Mon, April 30, 2012 12:40:09
In Star, I'm using three layers in order to create a feeling of 3D-depth in a 2D game:

* Front stars, moving fast and pulsating, large size

* Middle stars, moving fast, medium size

* Background stars, moving slow, small size

The depth feeling comes from the two last layers, when you see the "closer" (larger) stars moving past the "distant" (smaller) ones.

But lets talk and let me show you some code on the first one, the pulsating front stars. This layer if made up by three different textures, that each is transparent except for a few white painted stars.

I only show one of the three front star textures and once, and toggle which one is used, with a pause in between. When a texture is being used, I will gradually change the transparency to make a fade-in-fade-out pulsating effect.

I also move the layer to the left and paint it anew to the right as the side-scrolling game progresses.

Code sample from the pulsating stars:

Time window versus delta time

CodingPosted by Marie Wed, April 25, 2012 22:54:24
A few days ago, I had a friend who is also an old demo coder over for code reviewing. I showed off the game and got some feedback.

One thing I had chosen earlier was to use a constant timebox for my game loop that updates coordinates and draws them. It would only draw if it had enough time left after update (about 5 ms) or at least every 5th loop. Each timebox was 20 ms. This kept the game on 50 FPS (1000 ms / 20 ms = 50).

However, what we noticed when looking closer was that the game had slight 'lag' feeling on the asteroids that moved forward. My friend mentioned that upon switching screen buffer (replacing the current image shown on screen with whatever new image has been drawn until then), in some graphic libraries that function delays and waits for the graphic card to draw. I figured that was the cause of the lag.

The problem was that the graphic card was set on updating the screen with 60 Hz (60 times per second) while the game only generated 50 FPS (50 images per second). That meant, that 10 times per second, the same screen was shown again, which the player experienced as "lag". It's also why first trailers of the game was even more laggy (it had even ANOTHER frame rate that was totally out of sync).

I've now changed the implementation completely by adding delta time in all update functions. The functions multiply the movement per millisecond by the number of millisecond elapsed since the last update.

The game flows great now, without lag, and will have the same speed no matter which computer or refresh rate is used. And I've learnt to choose delta time before time window next time.

Code sample:

Graphics resource management

CodingPosted by Marie Wed, April 25, 2012 22:19:22

I recently found a new solution for my resource management system:

The system asks the graphicsystem singleton to retrieve a pointer to a sprite by giving an enum as id. The underlying implementation relies on an X-macro (yes, I know they are blunt, pollute, hard to debug and overwrite stuff, but also most useful). By asking for an enum, it won't even compile unless a correct enum is given. Way better than using the other sprite info available (the sprite path url), that would show errors first when getting runtime exceptions.

Another advantage was that I could automate the resource loading. All resources specified in the X-macro will be loaded automatically by looping the enum. More info about the X macro solution I used can be found on DrDobbs website.

Code sample: