Category: Uncategorized

World Warrior

A couple of years back I had uploaded a gameplay video of World Warrior, an unreleased Amiga (AGA chipset) game of mine, and every now and again, I get requests to make it available online. I finally did! World Warrior was originally a working title, and the game is to Street Fighter 2 what Blaze is to Sonic: a blatant rip off. Admittedly, as a kid, copyright law was never my forte.

Notwithstanding the ample representation the beat ’em up genre finds on the Amiga, it is undeniable that the SF2 port is a train wreck. Having played the game in the arcades and on console, the Amiga version always made me throw up a little in my mouth, until one day, in a fit of rage, I shaved my hair, smashed the game floppies and ground them to ash, poured the ashes on my head, Naruto-ran all the way down to the local shrine, and swore before the gods a solemn oath: that I would write my own beat ’em up. In assembly language. OK, this might not be exactly how it happened, cause I still have the disks lying around, but, well, memory is a stranger and history is for fools.

Having gained some experience from writing Blaze, I set out to write proper tools to help me design the character composites, animations, hit-boxes and so on, before even writing a single line of game code. In the end, I had developed a powerful animation system, where each character frame was composited from tiny pieces, tightly packed into a sort of texture atlas. I had opted for this approach for two reasons: first, I wanted to reuse character bits and pieces throughout animation frames, and second, well, memory constraints. I had also learned a nifty trick to scroll the screen at 50 Hz, even though the game was running at a lower frame rate (25 Hz, I believe). It’s possible that the atrocious flickering that plagues the game is due to a bug in the scrolling, which I had later fixed; the patch but was lost with the binaries and sources when my hard disk gave up the ghost.

The requirements I set for the animation system were simple: it was to recreate SF2 and FF characters and their dynamics faithfully, including the slowdowns and vibrations that occur when a player lands a hard hit on an opponent. SF2 used a six-button configuration, three for punches and three for kicks, graded in order of strength: low, mid and hard. It was hard to port over this control scheme to the Amiga with its single-button controllers, so I dropped the mid-strength moves and used a button press in conjunction with a joystick push in a cardinal direction to provide a low/hard punch/kick system. To this day, I still can’t say whether this was a good decision. Having neither friends nor computer AI players to play against, I never really got to test the control scheme properly.

Looking at game’s graphics, I must admit they look like puke strewn on the screen (dat green!), but, hey, I was never a graphic artist. My uncle had a video camera which I borrowed to help me digitise the backgrounds before retouching them in Deluxe Paint and compositing them for the game. The background is built from bits of video capture of the bastions near Porte des Bombes and original artwork.

Run brother! The large green puke of doom is coming for us!
This is what the bastions near Porte des Bombes look like today, courtesy of Google.

I’m still not sure why anyone would want to play this flickering mess, but if you do, you can download it from here. It’s even more unfinished than Blaze; the option screen doesn’t work and you can only play against another human player… and the round goes on forever as there’s no health system.


The effects system : Take 3?

I made a u-turn and totally scrapped the idea of having an effect expose a collection of cameras in order to have visibility sets generated for additional views. Instead, I opted for an effect interface which supports both external and internal potential visibility set generation; external generation reuses the visibility information from the effect subtree culling process vis-a-vis the main camera. Internal generation allows an effect to manage its culling strategy and come up with its own visibility set(s) given an instance of the currently active culler. In doing so, the determination of visible elements for additional drawing passes (such as shadow map generation) is fully customisable and active only within the scope of the effect. Moreover, the main culling process, which is concerned with culling objects which are not in the main camera frustum, needs not be concerned or involved with specialised culling instances. While pondering on how to actuate an all encompassing design, it struck me that some effects may actually be optimised through the provision of precomputed visibility sets. Being in control of the culling process, I could now apply local optimisations to the culling process, instead of having sets generated for me by a delegate which is potentially ignorant of any such optimisations.

This new scheme brought its fair share of woes, nevertheless. Since internal culling is now an offshoot and no longer managed externally, sorting visibility sets does not come for free anymore. Therefore, being stuck with an unsorted set, I chose to provide the effects framework with an interface by which sorting can be managed internally too. Again, although the set can be sorted straight away by a call to the currently active sorter instance, some local optimisations can be carried out which a generalised solution cannot provide, which one might as well take advantage of.

This new setup provides a flexible and extensible foundation for effects. Of course, the proof is in the pudding; I will be able to fully assess the ramifications of the current design only once I’ve actually built some complex effects and had them integrated within the scene graph (the first of which I’m off to build is effectively shadow mapping).

RIP 7900 GTX

It seems like the next update will have to wait – my laptop’s video card is busted! It was during a perfectly normal Windows session, that, all of a sudden, the desktop froze and the only way out was rebooting the machine. When the BIOS screen came up, it was evident something was not quite right – a display overlay of green vertical stripes is usually not a good sign. Well, to cut a long story short, I could boot neither Vista nor XP except in safe mode. I tried re-installing the video card driver but to no avail – the vertical stripes from hell have made a comely abode out of my display.

Since the last post, I have been working on a scene graph system and a high level pipeline for culling, sorting and rendering it. The pipeline consists of fully customisable modules, which can be extended or replaced at will, through the plug-in system. The culling module, for instance, is input a node of the scene graph and outputs a set of potentially visible entities. The culling strategy is up to the user to decide; so far, the core culling module only provides frustum culling of bounding volume hierarchies. Eventually, there will be implementations for various space partitioning schemes.

From the culling stage to the sorting stage: the entity set output from the culling stage is not optimally ordered or sorted for rendering. During this stage, the visibility set is sorted to provide a queue optimised for drawing operations. The basic implementation of the sorting module organises geometry, grouping it together using its material properties (render state changes, shader programs and textures), and comes up with a number of batches which, when rendered in the specified order, reduce the number of state changes. Although various sorting strategies will be made available, if none satisfy specific user requirements, the framework empowers the user to write his own sorting plug-ins.

The rendering module may take its input from the sorting stage or directly from the culling stage. Basically, when drawing from the sorting stage, entities are batched, grouped by specific criteria. On the other hand, drawing directly from the culling stage implies that no optimisation is performed on the input set, and accordingly entities are rendered one by one. So, fundamentally, the high-level rendering interface supports two modes of operation: batch and immediate. Being fully customisable, rendering modules allow a great deal of control over how scenes are rendered. It will eventually be trivial (I hope) to switch between, say, forward and deferred shading.

The next stage of development is the effects system, which is very much inspired from David Eberly’s Wild Magic engine ( With the effect system in place, I will have a framework within which to implement multi-node effects such as shadow mapping or planar reflections.

With my XPS out of the way, I thank the good Lord for providing me with a machine I can do some development on, until my trusty laptop is back home.

Meson : Vistas

Finally I got around posting a short video of Vistas on youtube. At this stage, there isn’t much to show bar some simple parallax-mapped primitives illuminated by a point light. As it stands, I have completed the driver abstraction layer, shader and geometry sub-systems and am currently working on the scene graph system. I should be able to post some more complex scenes pretty soon, if everything goes according to schedule.