22 January, 2007

Big Improvements

In the past few weeks the engine has seen lots of improvements. The framerate for all of my test applications has increased by roughly 80%. I don't have exact numbers in front of me right now, but the "zazaka" program is now significantly faster than the HGE version.

Vertex and pixel shaders are now fully supported. The engine defines a default vertex shader that it uses to render with extremely fast! on initialization (this also means the engine requires a video card that supports vertex shader version 1.1 at least).

With pixel shaders, though, the sky's the limit for cool effects.
Want your entire game to be rendered embossed or add blur effects, read from multiple textures or add any other number of special effects? It's all possible now.

Shaders go through the exact same resource management as all other resources, and are extremely easy to load, set, and use. For example, below is an example of how to load and start using a pixel shader:
ps := PixelShaderResource get: 'my_ps.pso'.
GameEngine current render pixelShader: ps.
As you can see from the above example, the actual rendering has been pulled out of the engine finally into its own class: GameRender. This was done for two reasons: simplify the engine class and if in the future I wanted to do 3D, this is where it would be done - subclassing GameRender into an immediate 2D render class and a batch 3D render class.

The GameActor class is now exactly how I want it - as just a node in the scene. It controls translation, rotation, and scaling. Actors can be parented to other actors, allowing for complex transformations (eg, a particle emitter attached to a sprite). The GameActor class now is subclassed into SpriteActor, which controls rendering of a sprite somewhere on the screen.

A pretty simple and well-featured particle system. Creating new particle effects in game and playing them is very simple and fast. There are 3 main classes which make up the particle effect system: GameParticleSystem (defines how particles will be emitted), ParticleEmitterActor (subclassed from GameActor), and ParticleActor (subclassed from SpriteActor). This has been the most flexible method of doing particles so far, as one GameParticleSystem can be used within many emitter objects very easily.

Spritemaps are now supported as a new resource type. They are extremely similar to fonts. An XML spritemap file is read off disk, which gives information about a texture and all the sprites inside of it. The spritemap object will create sprites that can then be referenced by SpriteActors by the name given to them in the XML file.
map := SpritemapResource get: 'sprites.xml'.
ship := SpriteActor fromSprite: (map sprites at: 'ship').
Right now spritemaps are very convenient for organizing data, but later when I add scrolling, tiled backgrounds they will be worth 10x as much as they are right now.

The last, simple, yet nice addition is the ability to set different blending modes. The engine supports additive, multiplying, solid, and alpha blending modes.

That about covers most of the recent changes and additions. Next I hope to clean up some more code and centralize more of the rendering code to be more flexible and easy to use, add render targets to the mix (this will open another level is visual effects), and I need to start planning how I'm going to do user interface widgets.


Flatlander said...

I'm currently working on something similar with Common Lisp and it's very interesting to see how these things work with Smalltalk, so please keep blogging about your experiences :)
I have previously looked at Dolphin (and a bunch of other STs, Smalltalk is something I keep coming back at regular intervals) and it seemed like a nice environment but I'm a bit worried about numerical performance. Have you done any benchmarks regarding that, like doing some basic physics and collision detection with a reasonable number of objects?

Jeffrey Massung said...

I've been doing constant benchmarks as I add features to the engine. It's no big surprise right now, but all the test games I've been making are heavily CPU bound. I'm just not pushing the graphics card hard enough for rendering to be a problem. But, I never expected to with a 2D game engine.

I assume you've looked at earlier posts where I compared sample programs written in a C++ engine to mine. I have been extremely happy with Dolphin and Smalltalk.

In the asteroids game that I've been using as a testbed for an "actual" game, having hundreds of sprites on the screen colliding with each other runs at a smooth 200+ FPS. And that's with the absolute worst collision detection routine imaginable - O(n^2) AABB tests.

The future looks very promising...