Dude... Affine Triangles like ... Suck!

So we’ve talked about the project up to 2007 – It was at this point that I finally put a realistic texture on the object you see in the 3rd post instead of the image from previous screenshots. Then we noticed…

Dude - affine* texture mapping on triangles looks freakin' terrible. (Sorry I've been watching a lot of Lost recently - just watched the episode Tricia Tanaka is Dead, 'He has a name dude, it's Roger Workman'). Anyway two main problems were obvious:

1. For a quadrilateral object, the textures on the two triangles often didn't line up by a pixel or so...so you had an offset along the diagonal of a wall for example - not a problem close up, but bad at a distance (as above - if you look at the doors you can see the effect most clearly)
   
2. As the angle to the poly became more slight, the diagonal shifted so that for a quad you get one fat and one thin tria. This is probably ok with perspective correct texture mapping** but with affine mapping* has the effect of shifting textures up and down the 'wall' for example - mmmmm nice... windows that slide up and down walls!

• ** Perspective correct texture mapping takes into account the distance of the part of the polygon being drawn from the viewpoint, thus as the polygon recedes, the texture gets tighter and smaller, with * affine texture mapping, the distance of the pixels being draw is not considered, but mapped onto the polygon as if everything was simple 2D.
  

A panic set in - this far down the road and it looks ghastly?! Nearly as bad as Black Ice/White Noise in fact.

After the panic came depression - it was going to be a LOT of work to put that right. I experimented like crazy for a couple of weeks, splitting trias, re-ordering nodes, etc., nothing fixed it. I became kind of despondent and left the project alone for quite a long time - too much work was no longer useful - really wondering if it was worth continuing with something so ugly.

For the first time, I did not attend JagFest UK, and was seriously considering quitting.

After a while Raven and I did some talking and thinking about it, and decided to have a go at fixing it, if I could do so fairly quickly. So, I bit the bullet and went into a re-write of the poly renderer (the part of the code which converts the mathematical definition of the 3D polygon projected onto the 2d plane of the screen into actual pixels) from scratch again, no longer concerning myself with just triangles, and using what I'd learned from the first engine.

Then came 2008, which was a difficult year for us. There's no need for details, but sometimes life just gives you something far more important to worry about than Video Games. (My elderly mother contracted cancer and passed away in November - Raven)

2009, on the other hand has eventually seen a return to coding, new demos of which will be shown at JagFest on the 19th.

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

A Start

Hello Everyone

Well I guess its finally time I made a start on telling people about the homebrew project.
Some of you may know I've been around the Atari scene for a while, firstly with the Falcon and CT60, and then the Atari Jaguar (Atari's Last Gaming Console), but keeping rather quiet.

I started coding the Jag a few years back but didn't really know what I was intending to do, I knew I wanted to do 3D but that was about all. I therefore began thinking what kind of graphics engine would be suitable. In coding parlance, the graphics engine is the part of the computer code which determines what is to be shown on the screen, in a 2D program this will be layers of oimages, in a 3D program this will be geometric objects transformed via perspective calculations into images suitable for display on a TV or monitor. In modern game developments these sections of code, these "Engines" are often licensed from other devlopers, you will frequently hear for example that a game is based on 'the Unreal engine'. This means that the major part of the code determining what will be displayed is a licensed version of that contaned in the game 'Unreal Tournament", theree are also many other examples. For the Atari Jaguar there was example 3D supplied to official developers, but when I began coding i did not have a copy of this, and so I began to write my own.

In the end, impressed by Phase Zero on the Jaguar, I started on a voxel engine (from scratch) - for those unfamiliar with the term, Voxel is short for Volumetric Pixel, I could give a lot of background but the essence that you need to know is that it's an extremely efficient method for displaying convincing, shaded, rolling landscapes such as that shown in the attached screenshot.

Shortly after that I began coding a 3D polygon engine (also from scratch as I had not seen the Atari demo code). The Polygon engine is what current gameplayers will be most familiar with, essentially it is a section of code which uses a large number of geometric shapes (usually triangles) to simulate the shapes of the objects, characters and vehicles seen in the game world, it will simulate the direction of light on these objects and their ability to reflect this light, it will also draw pictures onto these, to give them texture, which may be skin, or rock, scales or hair, bricks or slime, anything the game producer desires.

For a while both pieces of code (engines) ran entirely separately, but I demo'd the voxel engine on its own at JagFestUK in Rochester in 2004. Finally the polygon code was added to the voxel engine and they merged successfully in time for JagFest 2005. I'm attaching a picture of what was shown then, including a coloured voxel landscape, fogging and a whopping big textured triangle in the foreground poking out of the voxel landscape.

I hope this finally starts to answer a few of the questions that people have been asking about the project and as time rolls on (and depending what we show at JagFest this year) I'll talk about it some more.

Cheers,
Atari Owl