Atari Jaguar Homebrew - Gouraud Shading (TECHNICAL)

The Atari Jaguar Blitter has rather a lot of facilities for Gouraud shading.

One question that sometimes arises is how is the data setup up for the intensity. In the blitter one should consider a pixel as 32 bit for calculation of which only the top 16bits are written out to the screen data

• 8bits - colour
• 8bits - integer intensity
• 16bits - fraction of intensity.

Thus the pixel is 8bit colour 8.16bit intensity.

The main registers of interest are
B_Iinc - $f02270 - this 32bit register contains the amount each pixel is incremented by on every inner loop (*4 if in phrase mode)

Source Data - $f02240 - this is two 32bit registers containing the four fractional parts of the intensity i.e. 16bits of pixel one.16bits of pixel two in $f02240 and similarly for pixels three and four in $f02244.

Pattern Data - $f02268 - this is also two 32bit registers, they contain the top 16bits of each pixel, i.e. 8 bits of colour and the 8 integer bits of intensity.

Now if one has calculated the colour and intensity it can be quite awkward and time consuming to separate the top 16bits off to one set of registers and the lower 16bits off to another.

The Jaguar therefore has another set of registers
B_I0,1,2,3 These are an alternative method to specify the intensity and simplify its use by each referring to a pixel on its own.

B_I0 - $f0227c - a 32bit register of the form 8bit unused then 8.16 intensity.

This therefore allows the coder to set up the colour at the start of the polygon, then define the intensity anew for each of the 4 pixels of the first phrase at the start of each line without having to split off the fractional and integer parts.

Next time I shall try to get back onto the Lay off the 68k and GPU in main questions as initially intended.

Cheers,
Joe (Atari Owl)

The Crash of '06

So - what happened then?

Well we had a merged voxel and polygon 3D engine, that worked for a while at least, OK to demo, but not to play.

Then it happened :(.

The virtual Hard Disk I was using to use the Jag Tools on a Modern PC OS - VANISHED?!.

To this day I still don't know how that happened, one day the file was there, the next it was gone. For a while I wondered if my virus software had quarantined it or something but it didn't. We've since had further problems - but a fairly strict backup-regime has been implemented so there should be no more frights like this.

Now I did have back-ups (after I'd lost 2 Real HDs on my Falcon in 1 day - I DID do back-ups) , but I'd got complacent, and not done them as often as I should, so we had CD backups for quite some time before and the redo files locally, I thought it would be OK.

I was mistaken, retrieving the data from the redo files proved very tricky. I ended up extracting all the ascii data I could and putting them into big files and slowly whittling them down to the most up to date version I could reconstruct.

It almost worked. We had almost complete files, the only parts that didn't seem to work anymore were the interrupts (when a component in the computer, for example a timer, can cause the current program flow to be interrupted and jump to another piece of code to deal with the situation before returning to the normal flow). Now Atari had suggested in one of their developer docs that the way to keep the Blitter (the processor in the Jaguar used to copy textures or draw shaded polugons) busy was to form a stack of commands, and just load them into the Blitter each time it finishes itscurrent operation, so thats what I tried.

• Writing the Blitter data to a stack
• enabling the Blitter Interrupt so that as soon as it finished its last operation it interrupted the processor in which the data was being prepared. In this case it was one of the fast RISC chips, the Graphics Processor Unit (GPU), which then picked up the next values stuck 'em in the Blitter and went back to its work.

Now this is great if all you have is large gouraud (a method for providing smoothly shaded polygons) or unshaded textured polygons, but if you have small polygons, the overhead makes it a false economy.

Oh and sometimes JUST sometimes it can mess up a load/store command (to read or write values to/from meory).

And guess what? If it messes up the wrong store, everything can freeze. So I did a quick re-write of the interrupt part of the engine and gained a not inconsiderable amount of performance (perhaps 30% more polys/sec with small polys).

At last... some GOOD news.

It still wasn't fully stable in other respects but the freezing problem was GONE ... so off I toddled to JagFest 06 in Warrington. Where it promptly refused to load from CD and so everybody there at Warrington, sorry but you saw the '05 version again.

What would you have seen? - well it would have looked a little like this.

Did it just get dark?

The Head Up Display (HUD - the buttons, life bars, map, etc) is merely a placeholder and has already been replaced, but it might provide a hint at the kind of experience (obviously reduced in scale) that we'd like to achieve.

Cheers,
Atari Owl