Dr Typo interview -Fallen Angels-

[JagChris]

1.This is just a demo? Of something upcoming?

 

It is a demo of my next game, "Fallen Angels". There is more to come.

Basically it's a remake of "Rescue of Fractalus". There is still a lot to do:

- flying saucers

- scary aliens

- several levels of increasing difficulty

- intro and cutscenes (escaping the mothership, landing on the planet...)

 

2.Can you tell us about this 'voxel-ish' engine. My understanding there are two or so different types of pixel height mapping engines that arent quite 'voxel'. Can you elaborate on what this is? Is it true voxel? Is this your first engine of this type? How well does the Jag seem to lend itself to this type of engine?

 

It isn't a true voxel engine. It is more a kind of height-mapping engine. I don't know much about true voxel engines but the few I've seen required modern computers (>1GHz processors, 100s of MB of RAM). Early 90's machines would do very blocky stuff.

For the kind of engine I implemented, I guess the Jaguar compares well to its contemporaries (486 DX PC, 3DO...).

 

3.In this demo can you give us a breakdown of what chips are doing what in what we see here?

 

The Object Process is just displaying the framebuffer. There is not much to do for this coprocessor in this kind of game.

GPU & Blitter are used to render the "voxel" and zoomed sprites.

DSP is hanlding the sound engine.

68K is doing the game logic.

 

4.What improvements could be made if you could start over 'knowing what you know now' type of thing?

 

I don't think of many improvements I could make. I experimented of lot before working on "Fallen Angels". There is still work to do on the game logic, glitches to solve but I don't think of any obvious improvements so far.

 

5.How has your skill increased as a Jaguar programmer?

 

I'm getting more confident with GPU programming. It isn't extremely hard to program it takes some getting used to.

I also learnt a bit about the Blitter. It has a lot of possibilities but isn't very well documented. Some experimentation is needed...

 

6.Before you stated something to the effect of 'I don't fully understand what I did. I shuffled instructions around, like I did countless times before and got, once again, a performance boost.' Has time and experience on the Jag helped you to better understand why these things came about?

 

I have a better grip on this stuff now, but it is still a bit hard to predict which sequence of instructions is the most optimal. There are rules regarding pipelining, RAM access patterns... I still try random shuffling when I'm out of ideas. Usually I don't gain anything. I've had a few good surprises but these happen less and less.

 

7.You do much of your work in C. How much of a performance boost do you think you'd get if you had a GPU C compiler and could move all your C code there in something like this? Care to speculate?

 

In the case of "Fallen Angels", and "Tube SE" for that matter, I don't expect any performance boost if the whole code was moved to the GPU. Actually I would expect a performance loss.

I think the "evil" of the 68K has been way overstated. It has the lowest priority on the bus so it won't hinder the GPU & Blitter that much.

While I was developping Tube, I made a few tests regarding this.

To render the tunnel effect, the GPU has to access memory rather intensively.

I mesured the performance with the 68k polling the GPU memory to know when the GPU is done.

So we have both the GPU and the 68k accessing the bus intensively.

Then I tried with the 68K turned off. I got a +15.5% performance gain. Not bad, but it's not +300% like you could believe.

And this is close to a worst case scenario. In actual gameplay code, the 68K will execute more complex instructions (long jumps, complex addressing modes) and will be off the bus more often, leaving more cycles for the GPU.

In the case of Tube, the gameplay code is very light. When I remove it, the gain is less than 1%.

The problem is when you give too much work to the 68K. For example, in a advanced 3D game, if you compute all the physics calculations with the 68K you may end up in a situation where the GPU is waiting for the 68K to complete its work.

 

In the case of "Fallen Angels", I made a benchmark to see if it was worth the trouble to do some of the gameplay code using GPU in main.

To do this benchmark I wrote a box collison routine. It isn't very "GPU in main" friendly because it involves frequent jumps. But it is pretty typical to the kind of code I was going to need.

In the benchmark there are 200 collision tests done.

The result are:

voxel rendering alone, 68K turned off: 107 ticks

voxel rendering 68K turned off then the 68K does 200 collisions test: 134 ticks

voxel rendering then 200 collision tests by the GPU in main, 68K turned off the whole time: 124 ticks

voxel rendering with the 68k doing 200 collision test in parallel, then 68k off : 108 ticks.

 

I made more recent tests by removing most of the gameplay code... the gain is microscopic (less than 1%). So that's why I think moving the whole gameplay code to the GPU would result in worse performance.

 

Maybe the DSP could help a bit but it's already used by the sound engine. Anyway I think the gain would be very small.

 

8. Are you approaching the performance levels of Phase Zero which you were so impressed with? Or do they have you scratching your head a bit still?

 

It's hard to tell. It seems we're rougly in the same ballpark framerate wise. The textures in phase zero are more colorfull and higher res but the filtering seems not very clean. I think we're not doing the same thing...

 

The other night I had a fantastic time just flying around down through the canyons and back up etc. Did that for, um, well longer than I should of if I had had any real level of maturity lol. Great work again Typo. The community will surely enjoy your latest efforts.

[Vintagebreed]

Nice cant wait to see this in action.

[wozencl]

Thanks for sharing this, some very interesting points.

[JagChris]

OK tell us about the lightsourcing. The other night when flying around and basically going whee! whee! like a little kid I noticed the light sourcing and the shadowing. It seems that if you head into between 60 and 90 degrees of the compass you are going into the light source so ahead of you you see the shadows more pronounced. Tell us about this and the lighting in general please? What did you learn doing this?

 

I'll explain how the landscape is produced since lightsourcing depends on it.

The heightmap is not dynamically generated. I render it using GIMP, by applying various filters and hand drawing. I haven't yet found a filter that generates good data directly.

The heightmap is a 64x64 bitmap. It only uses 4KB so I include several different heightmaps in the game.

 

At level generation, the heightmap is expanded to 256x256 using a bilinear filter. A 64x64 pattern is added otherwhise it would look a bit bland.

Then the shadows are generated by applying an emboss filter on the heightmap data.

So you end up with both height data and intensity data for each pixel of the map.

 

The voxel renderer is sampling through this map, applying a bilinear filter on both height data and intensity data.

 

Well I didn't learn anything while doing this. I'm using stuff I already know.

 

 

How did/from where did you grab the sounds we hear in the game? Pilot running to ship, banging on door, engine sounds etc?

 

I used a sound search engine: http://www.findsounds.com/ISAPI/search.dll