Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Quasar

Calico

Recommended Posts

Since late last year I have occasionally been using some of my scant free time to plug away on a back-port of Jaguar Doom to the PC. As of the last couple of weeks it is now capable of dry-running all of the gamesim and most of the renderer (there is no screen output quite yet, but it's close), opening an SDL rendering context with hardware upscaling capability, and accepting very basic input (such as getting the window to close).

To finish this I have to reverse engineer the remainder of the GAS assembler files for the Tom and Jerry ASICs (most of this is done already), get key bindings working, get sound working, and finish translation of the CRY-16 framebuffer contents into an RGB 32-bit texture for display.

It can load either a Jaguar Doom ROM of any format, or the extracted jagdoom.wad file from inside it, and accepts either format as the argument to -iwad.

The Github project is at https://github.com/team-eternity/calico-doom if you want to keep tabs on the development blow-by-blow.

Here's a cute screenshot of it running the demos as fast as possible without any graphics output yet ;)

Share this post


Link to post

Once this is finished, I wonder when and if someone will try to get the other Jagdoom based games (32x (with or without Jagdoom level patch), GBA, 3DO, and especially PSX and Saturn) as accurately as can be reasonably done.

At the very least, there's a good chance that it will be more accurate than Eternity Engine's psx support.

Share this post


Link to post

Great news. I always liked the jag graphics, hope your backport will render them as accurate as possible.

Share this post


Link to post

Walls rendering, in gloriously drab, depressing CRY16. There's a problem with some walls at certain angles that I'll have to track down.

Share this post


Link to post

Haha I love novelties like these!

But what are the gameplay-related changes? Maybe it's a little early but what should a Doom player know before embarking on a Jaguar port binge?

Share this post


Link to post
Quasar said:

Walls rendering, in gloriously drab, depressing CRY16. There's a problem with some walls at certain angles that I'll have to track down.


Looks promising, the tint of the graphics seems to fit.

Share this post


Link to post
cybdmn said:

Looks promising, the tint of the graphics seems to fit.

Simulating the Jag hardware lighting makes all the difference. Jag Doom takes the sector light and turns it into a value for the Tom GPU's B_IINC register, which acts as an increment to the CRY intensity channel. If I were to just output everything like PC Doom does, using an 8-bit palette, it wouldn't even be close - the values in the internal 8-bit to CRY lookup used by the renderer don't even match the normal PLAYPAL exactly. Seems they were very deliberately rebalanced with respect to hue.

Share this post


Link to post

Very nice project! I'd like to do this kind of reverse-engineering, but stuff like this is too complex for me.

Share this post


Link to post
Quasar said:

Simulating the Jag hardware lighting makes all the difference. Jag Doom takes the sector light and turns it into a value for the Tom GPU's B_IINC register, which acts as an increment to the CRY intensity channel. If I were to just output everything like PC Doom does, using an 8-bit palette, it wouldn't even be close - the values in the internal 8-bit to CRY lookup used by the renderer don't even match the normal PLAYPAL exactly. Seems they were very deliberately rebalanced with respect to hue.

Interesting. Does your renderer emulation use the exact same CRY lookups, or are you empirically adjusting your renderer by eye? (I'm wondering where your knowledge of the Jag hardware comes from, and how well it is documented, and just how much down-and-dirty reverse engineering you had to do.)

Share this post


Link to post

The current Github shows that it's currently just doing a lookup table of every possible CRY value into RGB, but my extremely limited research suggests this is not accurate to what the real Jaguar did.

e:

The chroma goes into a 256x24-bit lookup table. This table is listed on page 28 of the TRM. Each color value is then multiplied/interpolated by the intensity (255-0), and the top 8-bits of the result are used for R, G, and B, output.


So it sounds like the CRY colors were effectively just multiplied by a value from 0 to 1 based on intensity. I don't know how this worked with non-saturated colors though, since they had to already be multiplied by some arbitrary luminance to get to a color close to the one you wanted.

Share this post


Link to post
Linguica said:

The current Github shows that it's currently just doing a lookup table of every possible CRY value into RGB, but my extremely limited research suggests this is not accurate to what the real Jaguar did.

e:
So it sounds like the CRY colors were effectively just multiplied by a value from 0 to 1 based on intensity. I don't know how this worked with non-saturated colors though, since they had to already be multiplied by some arbitrary luminance to get to a color close to the one you wanted.

Is it that 0 would just be black, and 255 would be the possibly unsaturated color? CRY blows my mind to begin with - RGB just seems orderly and sensible to me. I'm sure I'm missing something though :)

Share this post


Link to post
Linguica said:

So it sounds like the CRY colors were effectively just multiplied by a value from 0 to 1 based on intensity. I don't know how this worked with non-saturated colors though, since they had to already be multiplied by some arbitrary luminance to get to a color close to the one you wanted.

The lookups I'm using *are* the ones from page 28 of the technical reference manual, though. The Y component is the "luminance" and the CR are the cyan and red color components. The B_IINC register adds or subtracts from the luminance, not multiplies, and was meant for gouraud shading. Doom sets up the blitter so that the negative increment value applies across the column or span being drawn.

Share this post


Link to post

Ok but in the original jag code, is each pixel being drawn as a CRY16 value with the Y component further being being decremented as necessary, or what? Like take a dark red in Doom which I assume is internally represented with a saturated-red chroma and a luminance of 33/256 or whatever. Does the darkening effect result in the red being initially multiplied by 33/256(to get to the normal dark red color) and then further darkened by some sort of second operation?

e: although I guess if it's slinging CRY16 values then the luminance of the color is already there anyway. I'm so used to the 8 bit renderer that it can be hard to wrap my mind around something else.

Share this post


Link to post
Linguica said:

Ok but in the original jag code, is each pixel being drawn as a CRY16 value with the Y component further being being decremented as necessary, or what? Like take a dark red in Doom which I assume is internally represented with a saturated-red chroma and a luminance of 33/256 or whatever. Does the darkening effect result in the red being initially multiplied by 33/256(to get to the normal dark red color) and then further darkened by some sort of second operation?

e: although I guess if it's slinging CRY16 values then the luminance of the color is already there anyway. I'm so used to the 8 bit renderer that it can be hard to wrap my mind around something else.

Since the gouraud registers say they only work in CRY color mode, I have to assume the luminance adjustment requires the pre-separated luminance and color components that this color space offers - because the Jaguar can do RGB color as well, just outputting it straight into the video signal encoder - but not with all of the features of the hardware. Right now I'm literally adding B_IINC directly to the scaled up Y component, because this is the best idea I can come up with to make it work. Nobody has actually documented exactly what the hardware does with B_IINC, not even the Jaguar tech documents bother to explain it, and none of the half-finished Jaguar emulators that exist implement it either.

If I find it looks wrong once the game is functional enough to tell what's going on, I'll make adjustments, but so far my results match very well with real screenshots of the game.

Share this post


Link to post

Got the status bar working, and the gameplay view is now properly offset for the overscan region.

Share this post


Link to post

Is this going to follow the Doom 64 EX or the Chocolate Doom approach? Will it be a limit-removing non-buggy Jaguar port recreation? No music?

There should be a community map project for this when it becomes available. I recommend "Eye of the Jaguar" as title :D

Share this post


Link to post
VGA said:

Is this going to follow the Doom 64 EX or the Chocolate Doom approach? Will it be a limit-removing non-buggy Jaguar port recreation? No music?

There should be a community map project for this when it becomes available. I recommend "Eye of the Jaguar" as title :D

Chocolate Doom. Just a straight backport with minimal bug fixing for stability. Limit removal isn't even useful since there's no way to load PWADs. I feel like a limit-removing variant of it should be done as a fork and not be part of the core project.

Share this post


Link to post

This really looks quite nice, so far, I can't wait to see what it will look like in its first release. :)

Share this post


Link to post

Aren't there maps in jagdoom.wad? In vanilla format?

So can't I edit the iwad with new maps, sounds etc, like I do with ports that don't support merging or pwads? Like Doom 95 and the Doom Classic port of the BFG edition.

Share this post


Link to post

I'm not sure what the Jaguar's pixel aspect ratio is, but it's worth looking into for accuracy's sake. Based on what other Atari hardware did, my guess would be 6:7, though that could be wrong for all I know.

VGA said:

Aren't there maps in jagdoom.wad? In vanilla format?

They use a slightly different format IIRC.

That being said, I don't see why custom IWADs wouldn't work.

Share this post


Link to post
kb1 said:

Is it that 0 would just be black, and 255 would be the possibly unsaturated color? CRY blows my mind to begin with - RGB just seems orderly and sensible to me. I'm sure I'm missing something though :)

It's actually quite straightforward for how old CRTs and television standards worked. Video formats trend to still store pixels in the format, both for historical convenience and how camera sensors pick up light...

Share this post


Link to post

CRY mode on the Jaguar basically meant that you could only use the following colors, either at full saturation or faded to black by an arbitrary amount:



If you wanted any other color, you were out of luck.

Share this post


Link to post
Blastfrog said:

They use a slightly different format IIRC.

I don't think there were any differences, actually. I remember the GBA version had a different nodes format, but I'm looking at the Calico map loading source and I'm not noticing any differences.

In any case, I'm really interested in this project. The jaguar version's always appealed to me for some strange reason, if only because of the novelty of the source code being released at all. Interesting to see that much of the ASM game logic wasn't all that different from the stuff that was later found in the 3DO version (and I guess Doom 64, but in that case the reverse engineering was simply done in advance)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×