Jump to content
IGNORED

Does Jag Doom run in highcolor mode?


kool kitty89

Recommended Posts

 

Would you call 1999 "recently" ?

 

No but at least many silicon generations later. If you can't understand the actual point

I was making I don't know what else to tell you. I think I made my self rather clear.

Recently is still not so far off because the GFX cards for at leat a decade are still polygon

based. It takes quite a processor of a few Gigahertz to out perform a Jag because the hardware

STILL is not capable of voxels as with the blitter and it must be done in software. I dont care

if you have games in 1999 since that is not the point. Im talking games that completely blow

the doors off of what a 27 mhz console from 1992 was doing in terms of voxel rendering.

Can a PC from 1999 do it? Im sure it can with a lot of work using a lot of assembler or

a very optimized compiler. Just try using Open Gl even on todays machines and see how unsuited

the monster 3D cards are at pixel and line and voxel rendering. You'd do much better using the

host processor to do all those extra-polygonal effects. Only in the last 8 years are the GFX

cards really making a better effort at pixel rendering.

Edited by Gorf
Link to comment
Share on other sites

No but at least many silicon generations later. If you can't understand the actual point

I was making I don't know what else to tell you. I think I made my self rather clear.

Yes, I understand that point for sure, but the original claims you made were a bit exaggerated is all. ;) (I mean, if the Jaguar had been more successful and the hardware had continued to be built upon, the Jaguar 2 would certinaly been even more daunting for other platforms to attemt to replicate its strengths -not to mention anything that may have come after that) The Dreamcast and PS2 would probably barely be able to push out that kind of rendering on the Jag's level, all CPU rendering of course. (and of course, any polygons would be way easier to handel, but voxels would have to use the CPU to render, the Gamecube might be a bit better with its CPU, not sure about the Xbox's PIII/Celeron derivative -Jaguar level at leas though given Outcast ran perfectly on less -and didn't rely on hardware acceleration for the polygons even)

But yeah, the unique features are what make the Jaguar so impresive when you get down to it, and again, a shame they were little taken advantage of. (not just the limited number of games developed in general, but the majority of 3D games focused on polygons, and often flat shaded at that, so really sidestepping the strengths of the platform -and for a raycasting game AvP seems pretty unoptimized, especially given Doom)

 

Just try using Open Gl even on todays machines and see how unsuited

the monster 3D cards are at pixel and line and voxel rendering. You'd do much better using the

host processor to do all those extra-polygonal effects. Only in the last 8 years are the GFX

cards really making a better effort at pixel rendering.

Definitely, if hardware acceleration had focused a bit more on flexibility, I'm sure we'd have seen a lot more vaired game rendering styles over the years. (as it was, any who wanted to had to rely on CPU resouse to do so -with video accelerator cards finally starting to put more emphesis on that as you mention)
Link to comment
Share on other sites

P5 were released in 1993 anyway..the official release year of the JAguar.

75-120 mhz pentiums were released in 1994, the same time as Jag Doom. Phaze Zero was

not slated for release until at least 1995. That is when the 233mhz pentiums were

indeed released.

Hmm, while soemwhat tangent to your main point, I think those figures are a bit early as well. The Pentium was out in '93, but only the 60/66 MHz versions from what I can tell, then 75/90/100 Mhz in '94, 120/133 in '95 -skip to the Pro with 166/180/200 in 1995, finally in 1997 with the Pentium II there's 233/266/300 MHz ones released. (with AMD's K6 at up to 233 Mhz that same year)

 

 

Yes DOOM is the best versions of this game by far for it's time considering

the flawed console it had ran on. PSX is not high color like the Jag version

so even though we lack in game music(which I find lame anyway after the first

few times)

I thought Doom on PSX did run in highcolor mode (5-5-5 RGB), and did use more advanced shading than PC which was stuck with 256 colors (th edeault VGA palette if I'm not mistaken) for the entire palette and only 8 shades (and a lot of posterization). Crazyace mentioned that the PSX doesn't even have a 8-bit indexed color mode, just the 16-bit and 24-bit modes. (with textures using 256 indexed colors -which is a hell of a lot more color than in mose 256 color PC games -in doom you often get ones with not many more than 16 unique colors)

So on PSX you could use the PC quality textures and probably have proper gouraud shading without the very visible steps and posterzation in VGA.

Link to comment
Share on other sites

P5 were released in 1993 anyway..the official release year of the JAguar.

75-120 mhz pentiums were released in 1994, the same time as Jag Doom. Phaze Zero was

not slated for release until at least 1995. That is when the 233mhz pentiums were

indeed released.

 

Hmm, while soemwhat tangent to your main point, I think those figures are a bit early as well. The Pentium was out in '93, but only the 60/66 MHz versions from what I can tell, then 75/90/100 Mhz in '94, 120/133 in '95 -skip to the Pro with 166/180/200 in 1995, finally in 1997 with the Pentium II there's 233/266/300 MHz ones released. (with AMD's K6 at up to 233 Mhz that same year)

 

KK, please read what I actually wrote instead of just simply cut/paste quoting it and you will see

I said nothing different. The fact is that is DOES go directly to my point, regarless of year or speed.

The Jaguar was doing what they could not untill at least 3 years or so later.

 

Yes DOOM is the best versions of this game by far for it's time considering

the flawed console it had ran on. PSX is not high color like the Jag version

so even though we lack in game music(which I find lame anyway after the first

few times)

I thought Doom on PSX did run in highcolor mode (5-5-5 RGB), and did use more advanced shading than PC which was stuck with 256 colors (th edeault VGA palette if I'm not mistaken) for the entire palette and only 8 shades (and a lot of posterization). Crazyace mentioned that the PSX doesn't even have a 8-bit indexed color mode, just the 16-bit and 24-bit modes. (with textures using 256 indexed colors -which is a hell of a lot more color than in mose 256 color PC games -in doom you often get ones with not many more than 16 unique colors)

So on PSX you could use the PC quality textures and probably have proper gouraud shading without the very visible steps and posterzation in VGA.

 

Funny though, because from the looks of it, they did a straight port and I see nothing on PSX DOOM that 'blows away'

Jaguar Doom. I see very blocky textures and nothing looks like it is more than 256 colors. The Lighting on the Jag

version is smoother and superior, regarless of the lack of a few extra textures.

Link to comment
Share on other sites

Funny though, because from the looks of it, they did a straight port and I see nothing on PSX DOOM that 'blows away'

Jaguar Doom. I see very blocky textures and nothing looks like it is more than 256 colors. The Lighting on the Jag

version is smoother and superior, regarless of the lack of a few extra textures.

 

The lighting on the jag is nicer - CRY works wonders for the DOOM monochromatic lighting. But you're an idiot if you only see 256 colours on the PSX :)

Nothing really blows away the jaguar version though - most people wont pick up on the higher resolution and frame rate.

Link to comment
Share on other sites

Funny though, because from the looks of it, they did a straight port and I see nothing on PSX DOOM that 'blows away'

Jaguar Doom. I see very blocky textures and nothing looks like it is more than 256 colors. The Lighting on the Jag

version is smoother and superior, regarless of the lack of a few extra textures.

 

The lighting on the jag is nicer - CRY works wonders for the DOOM monochromatic lighting. But you're an idiot if you only see 256 colours on the PSX :)

Nothing really blows away the jaguar version though - most people wont pick up on the higher resolution and frame rate.

 

Idiots believe a geometry engine is useful for AI and game logic... but anyway :roll: .

I dont really see 15 bit color. The blockiness is not helping it either.

Link to comment
Share on other sites

Idiots believe a geometry engine is useful for AI and game logic... but anyway :roll: .

I dont really see 15 bit color. The blockiness is not helping it either.

No problem - at least you seem to understand there's more than 256 - that's a start.

The Jaguar doom has almost a 24 bit feel, as you have 256 shades of each colour - that's why it looks so good.

Link to comment
Share on other sites

Idiots believe a geometry engine is useful for AI and game logic... but anyway :roll: .

I dont really see 15 bit color. The blockiness is not helping it either.

No problem - at least you seem to understand there's more than 256 - that's a start.

The Jaguar doom has almost a 24 bit feel, as you have 256 shades of each colour - that's why it looks so good.

 

Indeed...especially in the one room on the second level in the one dark spot, after you find the red key, some

where in the back right by the secret door that you shoot to open,you can really see where CRY mode makes all

the difference over the other versions. The jag is much more of a machine than many gave it credit for and moreso

than 99% of the developers who did not bother to take full advantage of it.

Link to comment
Share on other sites

Are all the colors and shades in CRY mode actual 24-bit RGB values? If so, the shades/colors can't be exact as there would only be 256 shades of black/white, red, gree, blue, cyan, magenta, and yellow (and all the darkest shades will be pure black). So does CRY use separate luma control, or approximate shades for other from a standard 8-8-8 RGB palette?

Link to comment
Share on other sites

Are all the colors and shades in CRY mode actual 24-bit RGB values? If so, the shades/colors can't be exact as there would only be 256 shades of black/white, red, gree, blue, cyan, magenta, and yellow (and all the darkest shades will be pure black). So does CRY use separate luma control, or approximate shades for other from a standard 8-8-8 RGB palette?

 

 

My guess is they are interpolated from a tru RGB palette.

Link to comment
Share on other sites

My guess is they are interpolated from a tru RGB palette.

This is correct. 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.

 

As Kitty concludes, this means not all CRY colors map to unique RGB values, and many many CRY colors map to black. This side effect helps simplify some kinds of shading, and is also the reason so many Jaguar games "fade to black" to hide pop-in. Black is the only color that any CRY pixel can smoothly fade to.

 

That fade-to-black tendency is also clear in VLM and Tempest's melt-o-vision, along with other common effects. DOOM's sole lighting effect fades only toward black, so it's a perfect fit for the Jaguar hardware.

 

On RGB consoles, you can usually blend with equal smoothness toward any one of 8 primary colors: Black, red, green, blue, yellow, cyan, purple, white. On the Jaguar, the blitter and OP can only blend toward 5 colors: Black, blue, yellow, cyan, red. Only black can shade smoothly. The other colors shade in jagged blocks.

 

This limitation becomes a liability when mimicking certain common graphical effects, such as transparent explosions, lens flare or clouds -- all of which blend toward white/saturation on other consoles, even the SNES. And sadly, the Jaguar lacks the ever-present white fog seen in all other 90s games. ;)

 

- KS

Edited by kskunk
  • Like 1
Link to comment
Share on other sites

On RGB consoles, you can usually blend with equal smoothness toward any one of 8 primary colors: Black, red, green, blue, yellow, cyan, purple, white. On the Jaguar, the blitter and OP can only blend toward 5 colors: Black, blue, yellow, cyan, red. Only black can shade smoothly. The other colors shade in jagged blocks.

 

This limitation becomes a liability when mimicking certain common graphical effects, such as transparent explosions, lens flare or clouds -- all of which blend toward white/saturation on other consoles, even the SNES. And sadly, the Jaguar lacks the ever-present white fog seen in all other 90s games. ;)

 

- KS

Wait, what about the Jaguar using one of its RGB moses you mentioned in your previous post (#99), can't the blitter shade in 16-bit RGB mode, 24-bit RGB, or variable color mode?

What does Phase Zero run in? (24-bit?) The didtance fog looks pretty bright and smoothe. (rather like fog in other games, distance fog at least -like many lucass arts games on the N64 -or PC contemporaries for that matter -Rogue Squadron comes to mind)

Link to comment
Share on other sites

On RGB consoles, you can usually blend with equal smoothness toward any one of 8 primary colors: Black, red, green, blue, yellow, cyan, purple, white. On the Jaguar, the blitter and OP can only blend toward 5 colors: Black, blue, yellow, cyan, red. Only black can shade smoothly. The other colors shade in jagged blocks.

 

This limitation becomes a liability when mimicking certain common graphical effects, such as transparent explosions, lens flare or clouds -- all of which blend toward white/saturation on other consoles, even the SNES. And sadly, the Jaguar lacks the ever-present white fog seen in all other 90s games. ;)

 

- KS

Wait, what about the Jaguar using one of its RGB moses you mentioned in your previous post (#99), can't the blitter shade in 16-bit RGB mode, 24-bit RGB, or variable color mode?

What does Phase Zero run in? (24-bit?) The didtance fog looks pretty bright and smoothe. (rather like fog in other games, distance fog at least -like many lucass arts games on the N64 -or PC contemporaries for that matter -Rogue Squadron comes to mind)

 

 

It looks like CRY to me - and its not as smooth as you'd think, particularly colourwise - you'll see some pretty obvious shifts in colour at specific distances

 

I'm not blaming them its pretty much impossible to avoid with CRY - i think they did a first rate job

Edited by Atari_Owl
Link to comment
Share on other sites

Wait, what about the Jaguar using one of its RGB moses you mentioned in your previous post (#99), can't the blitter shade in 16-bit RGB mode, 24-bit RGB, or variable color mode?

16-bit shading in the Object Processor and Blitter work only in CRY mode, although I'm sure they generate some psychedelic effects in 16-bit RGB. ;) In variable color mode, you could mix unshaded RGB with shaded CRY. But you still can't shade a 16-bit RGB pixel.

 

Only the blitter can shade RGB, and only 24-bit RGB (using TOPNEN). Because 24-bit RGB uses 32-bit pixels, it uses twice the memory while cutting frame rate roughly in half (since you need 2x the bandwidth for everything).

 

Also, if you want texture mapping in this mode, there are two problems: First, there is no color lookup, so your textures are gigantic (32-bits per pixel). Second, correct shading for textures uses a multiply, but blitter "shading" uses an addition. This is fine for CRY mode, because the multiply occurs when CRY is converted to RGB. (That's the whole reason CRY exists, 3 multipliers in the output path replace 12 in the blitter.) Because of the lack of multipliers in the blitter, "shading" in RGB is probably only usable for smooth-shaded polys, not multi-colored texture polys.

 

I'm guessing there are no games that use 24-bit RGB smooth shading on the Jaguar due to the performance impact and poor texture support. But it would make very colorful and silky smooth shaded polygons if you really didn't want the textures.

 

What does Phase Zero run in? (24-bit?) The didtance fog looks pretty bright and smoothe. (rather like fog in other games, distance fog at least -like many lucass arts games on the N64 -or PC contemporaries for that matter -Rogue Squadron comes to mind)

I assume it's CRY. Also note that the shading only applies to the non-textured non-polygonal heightmap (aka voxel) terrain. The enemy sprites have no such shading. I'm not trying to diminish their work -- it was probably a difficult effect to pull off, possibly using lookup tables or event some GPU math on a per-"voxel" (height pixel) basis, to calculate the interpolation factors to get to "white".

 

The guys who did Phase Zero have some mad skills. I've had a couple of conversations with the guy who did the heightmap engine in Phase Zero, but I'm afraid to ask too many questions about it. He already thinks I'm a total nut for still knowing or caring about the Jaguar. :D

 

- KS

Edited by kskunk
Link to comment
Share on other sites

There's another Jaguar video mode I found a long time ago while poking around with BJL. In the Jaguar docs there are some "gaps" where registers "should" be, such as between F00054 (HEQ) and F00058 (BG). If you set bit 2 in the undocumented register F00056, you get "black and white CRY" mode.

 

In this mode, C chooses a grayscale shade from 0-255 and I shades that intensity. This mode is well-supported by the blitter (using TOPNEN) and can produce a few interesting shading effects not possible in normal CRY mode. The downside is, obviously, no color. :D

 

- KS

Link to comment
Share on other sites

I assume it's CRY. Also note that the shading only applies to the non-textured non-polygonal heightmap (aka voxel) terrain. The enemy sprites have no such shading. I'm not trying to diminish their work -- it was probably a difficult effect to pull off, possibly using lookup tables or event some GPU math on a per-"voxel" (height pixel) basis, to calculate the interpolation factors to get to "white".

Isn't pure white one of the colors available int he CRY palette? (by the discription, I'd have assumed that there would at least be 256 shades of black/gray/white -which are indeed available in 24-bit RGB)

 

The guys who did Phase Zero have some mad skills. I've had a couple of conversations with the guy who did the heightmap engine in Phase Zero, but I'm afraid to ask too many questions about it. He already thinks I'm a total nut for still knowing or caring about the Jaguar. :D

 

- KS

Yeah, a real shame that game never got finished/released (even in as limited distribution as Battlesphere was). And PZ does use normal sprites for enemies? (gorf seemed to give the impression they were voxel models earlier in this thread -I'd assumed they were sprites originally)

 

And, of course, voxel based games shouldn't have been limited to such masterful prgrammers at the time either, others may not have produced as amazign results, but that still doesn't mean it wouldn't have been preferably to plygons for a lot of things. (like the terrain in Cubermorph/battlemorph among other things)

A port of Comanche would have been pretty awesome. ;) (apparently that was even planned for the SNES using the Super FX2 coprocessor -can't immagine how cut-down that might have been though)

 

Non polygon based rasterization would be more preferable in general, like raycasting. (Doom seems to be a much better example than AvP, but the added disadvantage to voxels would be greater use of texture mapping)

 

There's another Jaguar video mode I found a long time ago while poking around with BJL. In the Jaguar docs there are some "gaps" where registers "should" be, such as between F00054 (HEQ) and F00058 (BG). If you set bit 2 in the undocumented register F00056, you get "black and white CRY" mode.

 

In this mode, C chooses a grayscale shade from 0-255 and I shades that intensity. This mode is well-supported by the blitter (using TOPNEN) and can produce a few interesting shading effects not possible in normal CRY mode. The downside is, obviously, no color. :D

Neat! Doe it still use 16-bit pixels, or 8-bit? (as it is only 8-bit grayscale) And is shading still limited to blending toward black alone, not the reverse?

Edited by kool kitty89
Link to comment
Share on other sites

I assume it's CRY. Also note that the shading only applies to the non-textured non-polygonal heightmap (aka voxel) terrain. The enemy sprites have no such shading. I'm not trying to diminish their work -- it was probably a difficult effect to pull off, possibly using lookup tables or event some GPU math on a per-"voxel" (height pixel) basis, to calculate the interpolation factors to get to "white".

Isn't pure white one of the colors available int he CRY palette? (by the discription, I'd have assumed that there would at least be 256 shades of black/gray/white -which are indeed available in 24-bit RGB)

 

The guys who did Phase Zero have some mad skills. I've had a couple of conversations with the guy who did the heightmap engine in Phase Zero, but I'm afraid to ask too many questions about it. He already thinks I'm a total nut for still knowing or caring about the Jaguar. :D

 

- KS

Yeah, a real shame that game never got finished/released (even in as limited distribution as Battlesphere was). And PZ does use normal sprites for enemies? (gorf seemed to give the impression they were voxel models earlier in this thread -I'd assumed they were sprites originally)

 

And, of course, voxel based games shouldn't have been limited to such masterful prgrammers at the time either, others may not have produced as amazign results, but that still doesn't mean it wouldn't have been preferably to plygons for a lot of things. (like the terrain in Cubermorph/battlemorph among other things)

A port of Comanche would have been pretty awesome. ;) (apparently that was even planned for the SNES using the Super FX2 coprocessor -can't immagine how cut-down that might have been though)

 

Non polygon based rasterization would be more preferable in general, like raycasting. (Doom seems to be a much better example than AvP, but the added disadvantage to voxels would be greater use of texture mapping)

 

There's another Jaguar video mode I found a long time ago while poking around with BJL. In the Jaguar docs there are some "gaps" where registers "should" be, such as between F00054 (HEQ) and F00058 (BG). If you set bit 2 in the undocumented register F00056, you get "black and white CRY" mode.

 

In this mode, C chooses a grayscale shade from 0-255 and I shades that intensity. This mode is well-supported by the blitter (using TOPNEN) and can produce a few interesting shading effects not possible in normal CRY mode. The downside is, obviously, no color. :D

Neat! Doe it still use 16-bit pixels, or 8-bit? (as it is only 8-bit grayscale) And is shading still limited to blending toward black alone, not the reverse?

 

Assuming it uses 8 bit shades and then a seperate intensity value, 16 bit is probably the case.

Link to comment
Share on other sites

kskunk : your post reminded me of something, but I couldn't remember what...

Now I've found it : it's explained in the net files for Tom (the file is Vid.net to be exact) :

(* The test register

 

bit 0 enables the vertical and horizontal counters

bit 1 starts object processing

bit 2 disables the CRY ROMs for testing the multipliers

bit 3 latches the vertical count

bit 4 enables nand tree output onto xintl

 

*)

Link to comment
Share on other sites

Graphically, in action, SS does not even come close and that one bit of color the CRY mode

of the Jaguar has over the 15 bit mode garbage is not only twice the colors but CRY is a special

mode of the Jaguar in that it comes closer to looking like TRUE color because if the way the

palette and color logic work.

 

I'm going to disagree slightly here in that whilst CRY does have some strengths (its EXTREMELY good for smooth intensity gradients) it has some very annoying limitations - in that because there are only 256 colours (predefined - they can't even be tuned - each with 256 intensities) its ability to do smooth colour gradients is quite poor compared with even a 15bit RGB mode. (Not that that has any bearing on SS of course)

 

The guy from HVS is saying that he was using RGB on the Jag rather than CRY for Dactyl Joust. Is this hard to do on the Jag? Can the Jag switch back and forth between RGB and CRY?

 

Sure enough, it existed. It was far from finished, however. You could fly about the arena and bop, lance and fireball things. There was some rather simple enemy AI, sound and a few keen special effects. One of the nicer things was that it was RGB based, not CRY, and therefore rather pretty. Very careful manipulation of the shading let me still do some depth cues and use the green channel for some pretty wacky field effects. The game was probably half a year of solid work from completion.

 

Original page: http://www.cyberroach.com/jaguarcd/html/dactyl.htm

Edited by JagChris
Link to comment
Share on other sites

kskunk : your post reminded me of something, but I couldn't remember what...

Now I've found it : it's explained in the net files for Tom (the file is Vid.net to be exact) :

(* The test register

 

bit 0 enables the vertical and horizontal counters

bit 1 starts object processing

bit 2 disables the CRY ROMs for testing the multipliers

bit 3 latches the vertical count

bit 4 enables nand tree output onto xintl

 

*)

 

I saw something similar in the Midsummer pdf for Jaguar 2 ( TEST1 register at f00056 ) - Bits 0 to 4 match your description.

Link to comment
Share on other sites

I guess Kskunk already answered my question. :)

 

16-bit shading in the Object Processor and Blitter work only in CRY mode, although I'm sure they generate some psychedelic effects in 16-bit RGB. ;) In variable color mode, you could mix unshaded RGB with shaded CRY. But you still can't shade a 16-bit RGB pixel.

 

Only the blitter can shade RGB, and only 24-bit RGB (using TOPNEN). Because 24-bit RGB uses 32-bit pixels, it uses twice the memory while cutting frame rate roughly in half (since you need 2x the bandwidth for everything).

 

- KS

Link to comment
Share on other sites

Isn't pure white one of the colors available int he CRY palette? (by the discription, I'd have assumed that there would at least be 256 shades of black/gray/white -which are indeed available in 24-bit RGB)

It's the math behind the color scheme that's the problem. Let's say you want to add a sunny yellow (lens flare) to a bright daytime blue. What do must games end up with? Blinding white.

 

In RGB, you add #FFFF80 (sunny yellow) to #80C0FF (sky blue). The total? #ffffff (white) Note that color channels stop at their limits (ff and 00).

 

Let's try that in CRY. #BAF0 (sunny yellow) plus #F (sky blue). The total? #ffff (neon yellow) The major problem is that the neon yellow has no blue in it at all, so the sky has been erased! It's not even a warm sunny yellow like we had before, now it's a freakish electric yellow. This is not how real light is perceived by humans. The various wavelengths of light are "summed" across 3 color "channels" in your eyes, just like my RGB example.

 

To get to white, you have to go to #88ff in CRY. In RGB, to shade from some arbitrary color toward white, just add how much white you want -- #808080 for some white, #c0c0c0 for more white, etc. In CRY, to shade from some arbitrary color toward white, you must first compute the distance between that pixel and white on a per-pixel basis. That's expensive and there's no support for it -- you need to do it in the GPU with math or lookup tables.

 

Neat! Doe it still use 16-bit pixels, or 8-bit? (as it is only 8-bit grayscale) And is shading still limited to blending toward black alone, not the reverse?

The grayscale CRY mode is 16-bits. It can shade toward white more easily and the shading behavior is more like 24-bit RGB, except with no color. This is literally because the same color is output on R, G, and B.

 

Zerosquare's analysis makes perfect sense. This is a test mode that lets you try every possible combination of 65536 "shades" on each CRY multiplier. The only big problem is that all CRY multipliers run with the same shade, which is fine for grayscale but equals monochrome for games. ;)

 

It probably would have just as cheap to do an RGBA mode compared to this test mode. It would be just as useful for testing but allow amazing color effects. Sadly, it would also use so much bandwidth that it wouldn't help the Jag's framerate problems much...

 

- KS

Edited by kskunk
Link to comment
Share on other sites

The guy from HVS is saying that he was using RGB on the Jag rather than CRY for Dactyl Joust. Is this hard to do on the Jag? Can the Jag switch back and forth between RGB and CRY?

 

Sure enough, it existed. It was far from finished, however. You could fly about the arena and bop, lance and fireball things. There was some rather simple enemy AI, sound and a few keen special effects. One of the nicer things was that it was RGB based, not CRY, and therefore rather pretty. Very careful manipulation of the shading let me still do some depth cues and use the green channel for some pretty wacky field effects. The game was probably half a year of solid work from completion.

 

Original page: http://www.cyberroach.com/jaguarcd/html/dactyl.htm

From earlier in this thread:

The Jag supports the following video modes:

 

16-bit CRY

24-bit RGB

Custom (requires external hardware)

16-bit RGB

15-bit CRY + 15-bit RGB or "Variable Mode"

In this mode, you can switch from RGB to CRY mode on a pixel by pixel basis

I.e., some sprites could be RGB and others CRY, or background RGB with CRY sprites, etc...

 

All modes except RGB work with color look up, so you can use 1/2/4/8 bit sprites.

plus:

16-bit shading in the Object Processor and Blitter work only in CRY mode, although I'm sure they generate some psychedelic effects in 16-bit RGB. ;) In variable color mode, you could mix unshaded RGB with shaded CRY. But you still can't shade a 16-bit RGB pixel.

 

Only the blitter can shade RGB, and only 24-bit RGB (using TOPNEN). Because 24-bit RGB uses 32-bit pixels, it uses twice the memory while cutting frame rate roughly in half (since you need 2x the bandwidth for everything).

 

Also, if you want texture mapping in this mode, there are two problems: First, there is no color lookup, so your textures are gigantic (32-bits per pixel). Second, correct shading for textures uses a multiply, but blitter "shading" uses an addition. This is fine for CRY mode, because the multiply occurs when CRY is converted to RGB. (That's the whole reason CRY exists, 3 multipliers in the output path replace 12 in the blitter.) Because of the lack of multipliers in the blitter, "shading" in RGB is probably only usable for smooth-shaded polys, not multi-colored texture polys.

 

I'm guessing there are no games that use 24-bit RGB smooth shading on the Jaguar due to the performance impact and poor texture support. But it would make very colorful and silky smooth shaded polygons if you really didn't want the textures.

 

 

Oh, and kskunk, when you said lookup doesn't work in RGB, is that only for 24-bit RGB or all RGB modes?

And there is no hardware shading suport for the 15/16-bit RGB modes? (even limited -like 8-shades/intensity gradients -which would seem to be rather straightforeward in 5-5-5 RGB using any base colors from 9-bit RGB space -all having at least 8 shades in 15-bit RGB, no interpolation needed)

Link to comment
Share on other sites

Oh, and kskunk, when you said lookup doesn't work in RGB, is that only for 24-bit RGB or all RGB modes?

And there is no hardware shading suport for the 15/16-bit RGB modes? (even limited -like 8-shades/intensity gradients -which would seem to be rather straightforeward in 5-5-5 RGB using any base colors from 9-bit RGB space -all having at least 8 shades in 15-bit RGB, no interpolation needed)

Sorry, I meant to say color lookup is only available in 16-bit modes (including 16-bit RGB). 24-bit RGB gets no lookup sadly. They have all the hardware for it too! The CLUTs are a full 32-bits wide, but you must write the low and high 16-bits to the same value. :-/

 

I guess it depends on your definition of "shading". There's no multiplier so traditional lighting effects don't work at all (i.e., you can't make a RGB texture half as bright with the blitter, but you can with CRY).

 

You also can't really gouraud shade in any useful way, since the fractional parts of the gouraud shader work either on 4 or 8-bit boundaries, and the RGB boundaries are 5-bits. Another way to think of that is that you might be able to smoothly shade green and blockily shade red (with 16 shades), but blue can't be shaded at all -- not very useful for common colors such as white. ;-)

 

You also can't easily blend colors because saturation is also 8-bits, thus you end up with your math all screwed up, with colors wrapping around in unpredictable ways (i.e., bright green + bright green = black, which makes no sense).

 

- KS

Edited by kskunk
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...