109 replies to this topic

[kool kitty89]

I understand why the designers of the Jaguar chose to use a chroma/luma based color format (smoother shading and easier logic design for the shader logic, etc -working only on 4 and 8-bit boundaries), but why did they choose a proprietary color model?

Why not use a derivative of a standard color model that fit the requirements, like YCbCr? (ie 8-4-4 YCbCr)
And why use a luminance scheme that only shaded from normal intensity of colors down to black rather than having normal intensity in the middle with 128 shades towards black and 128 shades towards white?


For that matter, there were other compromises between plain RGB and CRY (or YUV/YCbCr) like using RGBI. 4-4-4-4 RGBI would mean choppier luminance shading than CRY, but a larger array of colors to choose from (as well as fitting perfectly for 24-bit RGB: 4-bits per RGB element and an additional 4-bits setting the intensity within the 8-bits per RGB of 24-bit colorspace . . . albeit not quite perfect if you arranged luminance relative to human perception rather than just RGB intensities). You couldn't even need a LUT (like CRY does) for 4-4-4-4 RGBI, just manipulating 24-bit RGB directly. (again, unless you corrected lumance calibration for human perception)
RGBI would also allow more flexible shading using colors rather than just light/dark. (like normal RGB shading, but with more of a compromise with luminance and working on convenient 4-bit logical boundaries)
So better luminance shading than 15-bit RGB (a la PSX/Saturn) but weaker than CRY or 8-4-4 YCbCr, and weaker colored shading than 15-bit RGB but better than CRY (or YCbCr).

[JagChris]

Atari probably could of done better on a lot of things I'm sure but at least the Jag has an option like CRY and also has the option to do RGB. It has some of the coolest lighting, shading effects compared to its contemporaries. So we should be grateful for that, especially every time we play a game like DOOM on the Jag where the shading and lighting is so much cooler over the PSX and PC versions.

I think time would probably be better served learning how to use CRY to the best of the jags abilities but fantasy threads are just that. Have fun!

kool kitty89, on Fri Sep 23, 2011 8:43 PM, said:

I understand why the designers of the Jaguar chose to use a chroma/luma based color format (smoother shading and easier logic design for the shader logic, etc -working only on 4 and 8-bit boundaries), but why did they choose a proprietary color model?

Why not use a derivative of a standard color model that fit the requirements, like YCbCr? (ie 8-4-4 YCbCr)
And why use a luminance scheme that only shaded from normal intensity of colors down to black rather than having normal intensity in the middle with 128 shades towards black and 128 shades towards white?


For that matter, there were other compromises between plain RGB and CRY (or YUV/YCbCr) like using RGBI. 4-4-4-4 RGBI would mean choppier luminance shading than CRY, but a larger array of colors to choose from (as well as fitting perfectly for 24-bit RGB: 4-bits per RGB element and an additional 4-bits setting the intensity within the 8-bits per RGB of 24-bit colorspace . . . albeit not quite perfect if you arranged luminance relative to human perception rather than just RGB intensities). You couldn't even need a LUT (like CRY does) for 4-4-4-4 RGBI, just manipulating 24-bit RGB directly. (again, unless you corrected lumance calibration for human perception)
RGBI would also allow more flexible shading using colors rather than just light/dark. (like normal RGB shading, but with more of a compromise with luminance and working on convenient 4-bit logical boundaries)
So better luminance shading than 15-bit RGB (a la PSX/Saturn) but weaker than CRY or 8-4-4 YCbCr, and weaker colored shading than 15-bit RGB but better than CRY (or YCbCr).

[kskunk]

kool kitty89, on Fri Sep 23, 2011 8:43 PM, said:

I understand why the designers of the Jaguar chose to use a chroma/luma based color format (smoother shading and easier logic design for the shader logic, etc -working only on 4 and 8-bit boundaries), but why did they choose a proprietary color model

You write these threads just to bait me to answer, right?

The designers explain their thinking in detail in the Jaguar Technical Reference Manual:

Quote

The following requirements were made on this scheme:
1. All two hundred and fifty-six values should represent valid, and different, colours.
2. The colours should be well spread out across the colour space.
3. Colours should be able to be mixed by linearly averaging their colour values.
4. An intensity value of zero must be black.

As the remaining colour space without intensity is two-dimensional, two vectors are required to represent a
point in it. An r, theta scheme was discarded as it would not meet requirement two, and so a scheme based on
two x, y vectors was chosen.

To meet requirement one, the two vectors must describe a point on a square area. As no existing colour space
model is square when viewed along the intensity axis, it was necessary to come up with a new one.

The approach chosen, after considerable experimentation, was to take the view along the intensity axis of the
RGB cube, which is a hexagon, and distort it into a square. This does not quite meet requirement 3, but is close
to it.

Standard color models like YIQ (r, theta) or YCbCr (no even distribution, violating #2) didn't meet their requirements.

The Y in CRY had to be 8-bits, because Flare believed that smooth gouraud shading would be the key to the Jaguar's market dominance. This belief is reflected throughout the design of the Jaguar. Smooth polygon shading wasn't just a feature, it was THE feature -- it influences many major architectural decisions, including color space.

8-bits for Y leaves just 8-bits for color. CRY does a better job than standard color spaces of spreading those 256 values among useful colors, about as well as R4G4B4 does. Also, it allows color blending to work pretty well, again, about as well as R4G4B4 would.

The Jaguar designers obviously spent some time thinking about this, because they list the pros and cons of their approach:

Quote

Advantages of CRY

• Smooth intensity shading from 16-bit pixels
  
• Better matched to the capabilities of the human eye than 5:6:5 bit RGB schemes
  
• Suitable for efficient Gouraud shading

Disadvantages

• Steps are visible in smooth changes of saturation or hue
  
• Translation from RGB to CRY is not straightforward
  
• Non-standard

-KS

[sd32]

kskunk, we know the Jag just cant compete with the PS1 and Saturn when it come to texture mapped polygons, but how does it compare to them when it comes to gouraud shadded polygons?, since you mention it was the Jags strength in 3d, is it comparable to them?.
For being the Jags strength, i have to say that i was quiet dissapointed with Battlemorphs graphics, it had a very short draw distance, albeit with a good frame rate. Its still a great game, and the G-shadded look is very cool (would love to see more games with that look), but again, for those sort of graphics to be the Jags strength, i expected a bit better. But hey, i guess its because it was jus a first gen JagCD game, right?

[kskunk]

sd32, on Sat Sep 24, 2011 12:22 AM, said:

kskunk, we know the Jag just cant compete with the PS1 and Saturn when it come to texture mapped polygons, but how does it compare to them when it comes to gouraud shadded polygons?, since you mention it was the Jags strength in 3d, is it comparable to them?

It has a higher theoretical performance when plotting smooth shaded pixels than either the PS1 or Saturn.

But you know what they say about the difference between theory and practice...

Although the Jaguar is quite good at plotting shaded pixels, it isn't as good at organizing those pixels into polygons. The more polygons there are, the more the Jaguar strains compared to the PS1. This is because the PS1 has fast dedicated hardware for transforming, lighting, and rasterizing polygons. In the Jaguar, these steps must be done with software.

That leads into the other issue you raised: Realtime 3D programming for game consoles was a brand new field in 1993. While the PS1 did a lot of the work for the programmer, the Jaguar demanded the programmer use techniques that were sophisticated, difficult, and largely unheard of in the early 90s.

It is amazing what programmers accomplished at the time. Since then, knowledge of 3D programming has become much more commonplace, and the techniques known only to the very best programmers are pretty well documented (if still hard to understand).

I think the Jaguar could be pushed a little further with everything we know today. It's quite amazing what programmers accomplished on the Jaguar back then, given all the constraints -- low budgets, inexperienced coders, poor documentation, hardware bugs, and the newness of it all.

- KS

[kool kitty89]

kskunk, on Fri Sep 23, 2011 11:08 PM, said:

Standard color models like YIQ (r, theta) or YCbCr (no even distribution, violating #2) didn't meet their requirements.

The Y in CRY had to be 8-bits, because Flare believed that smooth gouraud shading would be the key to the Jaguar's market dominance. This belief is reflected throughout the design of the Jaguar. Smooth polygon shading wasn't just a feature, it was THE feature -- it influences many major architectural decisions, including color space.

8-bits for Y leaves just 8-bits for color. CRY does a better job than standard color spaces of spreading those 256 values among useful colors, about as well as R4G4B4 does. Also, it allows color blending to work pretty well, again, about as well as R4G4B4 would.

The Jaguar designers obviously spent some time thinking about this, because they list the pros and cons of their approach:

Quote

Advantages of CRY

• Smooth intensity shading from 16-bit pixels
  
• Better matched to the capabilities of the human eye than 5:6:5 bit RGB schemes
  
• Suitable for efficient Gouraud shading

Disadvantages

• Steps are visible in smooth changes of saturation or hue
  
• Translation from RGB to CRY is not straightforward
  
• Non-standard

-KS

OK, you addressed most of that (including color blending being reasonably capable as well), but there's still a few odd sticking points:

Why have the colorspace designed around only shading towards black rather than making intensity 0 black and 255 white for all hues, with 127 or 128 at "normal" saturation and intensity for any given hue? (128 shades is still pretty damn smooth, and allows a lot more flexibility for lighting effects)

The other issue is with their comments on what colors the human eye is most sensitive to, especially their mention of red being most important when Green is universally considered to be the color of light the human eye is most sensitive to. (in the RGB model, green, then red, then blue are the most important, though you could break it up much further in general for human sensitivity -colors in the green/yellow range being the most sensitive and blue/violet range being the weakest with orange and cyan somewhat below yellow/green and red further down but well ahead of blue/violet)

Granted, it might not matter too much if the final 256 colors selected still correspond reasonably well to human perception of color. (regardless of how the selection was obtained) . . . And maybe that comment in the manual about green being less sensitive to the human eye was just a typo in the colorpsace explanation. (actually, given the actual colors selected for the CRY palette, that does seem to be a misprint)

Of course, they did already support 15 and 16-bit RGB as well (and a mode for 15-bit RGB and 15-bit CRY color to be selected per-pixel), but with limited support for effects in 15-bit RGB. (not sure about color blending, but I know gouraud shading doesn't work . . . unless you aren't trying to smooth shade but want some crazy distorted color effects in RGB . . . and there's shading in 24-bit RGB, but that's generally impractical to use due to memory capacity, OPL bandwidth, lack of CLUT support for textures, etc -well, maybe useful at low resolutions)

Still, I wonder if 4-4-4-4 RGBI would have been a viable option without adding significantly to the existing logic in the Jaguar. (it works on 4-bit boundaries as the blitter is designed to use, should be possible to implement without needing a large LUT for conversion to 24-bit RGB as CRY does, and offers a nice compromise between CRY and normal RGB)



I wonder how seriously other console designers and PC video chipset developers considered support for alternate color models. Most/all simply went with plain RGB color (NEC used YUV for the PCFX, and the MSX2+ had YJK, but neither used that for shading effects, let alone 3D-oriented effects) and prior to the universal shift to 24/32-bit color, the common option for smoother shading was dithered interpolation. (PSX used it and many PC video cards -and a few software renders- did/do as well, granted dithering works fairly well at high resolutions for smoothing out gouraud shading and filtered textures, but it's really grainy at low resolutions -ie most examples on the PSX- . . . not to mention there usually doesn't seem to have been control for the dithering threshold -an option to limit the dithering threshold to simple checkerboard patters would look much less grainy than stronger dithering usually used and still much less posterized than plain 15/16-bit RGB)
And implementing hardware dithered interpolated shading takes significantly more logic design (or CPU overhead -unless extremely simple dithering patterns were used) while looking worse aesthetically. (granted, for 256 color software renderers, there wasn't much alternative -you can sacrifice some color and optimize the remaining ones to work as well as possible for LUT based 256 color shading, but it can only go so far -albeit very few software renderers even bothered to support dithering, Tie FIghter is one of the most notable -and the CD release of Xwing using the TF engine)

sd32, on Sat Sep 24, 2011 12:22 AM, said:

kskunk, we know the Jag just cant compete with the PS1 and Saturn when it come to texture mapped polygons, but how does it compare to them when it comes to gouraud shadded polygons?, since you mention it was the Jags strength in 3d, is it comparable to them?.
For being the Jags strength, i have to say that i was quiet dissapointed with Battlemorphs graphics, it had a very short draw distance, albeit with a good frame rate. Its still a great game, and the G-shadded look is very cool (would love to see more games with that look), but again, for those sort of graphics to be the Jags strength, i expected a bit better. But hey, i guess its because it was jus a first gen JagCD game, right?

There's 2 issues concerning this: raw rendering performance (which won't match the PSX, though shaded polygons will at least be far, far more competitive than heavily texture mapped ones), and then the quality of shading/lighting effects themselves. (if you want a "3D" game that the Jaguar might actually be universally better at than the PSX, there are some really nice pseudo-3D options -namely height maps like Doom or Phase Zero, perhaps with a tactful mix of polygons and 2D sprites -then there's the non-graphics argument for performance, like the Jag's potential for intensive game logic computations, ie Battlesphere)

In the latter case, CRY has a huge advantage for very smooth shadow effects, but it's not good for shading towards white (you can only go up to the normal intensity for each hue, only white will shade to white ). You're also very limited in colored shading/lighting effects. (unlike RGB which allows shading towards a number of colors, not just bright/dark)

Edited by kool kitty89, Sat Sep 24, 2011 1:44 AM.

[doctorclu]

Cool topic BTW. Would love to learn how to work with and make CRY images for the Jaguar. Been interested in it ever since I looked into the components of thwe Jaguar Bubsy game.

[sd32]

doctorclu, on Sat Sep 24, 2011 9:14 AM, said:

Cool topic BTW. Would love to learn how to work with and make CRY images for the Jaguar. Been interested in it ever since I looked into the components of thwe Jaguar Bubsy game.

Funny doctorclu, the only time i have heard about CRY and Jag Bubsy together is when people are crying due to how bad it is...haha, just kidding.
Can anyone point to an example of a game with a very advanced engine that works only with gouraud shadded polygons, it doesnt matter the platform. I love the look of games like Battlemorph in the Jag, and wonder how a similar game would look like on a more advanced system. Saturn and PS1 dont seem to have anything that looks like it, so maybe on PC from the mid 90s...

[kskunk]

kool kitty89, on Sat Sep 24, 2011 1:37 AM, said:

Why have the colorspace designed around only shading towards black rather than making intensity 0 black and 255 white for all hues, with 127 or 128 at "normal" saturation and intensity for any given hue? (128 shades is still pretty damn smooth, and allows a lot more flexibility for lighting effects)

This would be a cool feature, but it's not obvious to me how to implement it.

I don't want this thread to spiral out into a discussion of 3D lighting, but your approach seems to mix two unrelated kinds of blending: Additive and multiplicative. These are different effects used at different times.

Multiplicative blending is for standard lighting, including gouraud shading. If you have a pure blue floor (say 0,0,150), no matter how brightly you light it, it saturates at pure blue (0,0,255), not white.

Additive blending is for overlaying objects. If I want to place white fog over distant pixels, I might add white (150,150,150) to the blue floor (0,0,150) yielding a washed out whitish blue (150,150,255). Same trick is used with overlaying explosions, rain (subtraction), and other particle effects that are semi-transparent.

In CRY, the blitter does your additive blending, and Y does your multiplicative. In the PS1, the blitter can do both. The PS1's approach uses a lot more hardware and is slower than the Jaguar at shading pixels, but it's more versatile.

So, before we extend the range of Y, realize that this is only good for simulating VERY bright lighting conditions, not for fog, explosions, and other overlay effects. In other words, a lot of what we'll need to do is similar to the high dynamic range capabilities that appeared in 21st century consoles.

The problem with extending the range of Y comes down to how gouraud shading and multiplicative lighting work. Y must have a linear relationship to perceived intensity, or shaded polygons will look blotchy and 'uneven'. CRY does this already. If I have red-purple (255,0,127) and I cut Y in half, I have half the perceived brightness and the exact same red-purple color (127,0,63).

Now how can we maintain this while increasing the range of Y? First, let me try Y=2.0 with my red-purple. On my first try, I don't have red-purple anymore, I have pure purple (255,0,255).

But much worse, I don't have double the perceived intensity. The human eye perceives blue as the 'least intense' color. We can use a common formula to estimate perceive intensity: 0.299R + 0.587G + 0.114B

With Y = 1.0, or 255,0,127, intensity is 90.7. With Y = 2.0, or 255,0,255, intensity is 105.3.

So to achieve the required intensity for smooth shading, the color we need to use is a very washed out white-purple, or 255,130,255, with intensity 181.625.

I'd encourage you to create equations to do proper, saturating, smooth gouraud shading with Y > 1.0. However, the best I can come up with requires 9 multiplies and 9 additions. This is WAY more hardware than the 3 multiplies and 0 additions used in the Jaguar's CRY. I can't think of a good way to fit any of this into a look-up table smaller than thousands of entries, which wouldn't fit on the chip, either.

Hardware isn't the worst part. To implement your proposal where Y=255 is white for all colors, while keeping Y linear for proper shading, Y=2.0 is not near enough. Let's say I start with blue and I want to light it with white hot sunlight. To get from (0,0,255) to (255,255,255), while keeping linearity in Y, requires Y = 8.7. Let's make it 8.0 for simplicity.

We haven't just halved our number of colors, we've cut it by a factor of 8. Now CRY has no advantage over 16-bit RGB, because the majority (>80%) of all colors are white.

I know we end up here a lot, but the Flare engineers were very good. Their problem was they started with the wrong requirements, not that they left low hanging fruit behind!

Quote

The other issue is with their comments on what colors the human eye is most sensitive to, especially their mention of red being most important when Green is universally considered to be the color of light the human eye is most sensitive to.

I think you're misunderstanding what they meant. It is true that red contributes less to perceived intensity. But when intensity is provided by an 8-bit channel already, this is not about intensity. Rather, this is about how your eye differentiates subtle differences in color at the same intensity. From this perspective, which is the one that matters when choosing CR, it is correct that green is less important.

Blue is actually most important. Humans are very good at differentiating shades of blue. Some people think this is related to outdoor depth perception, because distant objects turn very subtly blue due to atmospheric effects.

- KS

Edited by kskunk, Sat Sep 24, 2011 1:48 PM.

[Jag_Slave]

This is definitely an interesting topic, as I have been reading up on CRY and messing with in game effects... Some neat advantages and ideas can be generated from it with just a little creativity

[sd32]

Sorry if i am a bit off topic here and if my questions are dumb for those with knowledge, but i have to know, is the Jag as fast at doing flat shaded polygons as it is doing gouraud shaded ones? I seem to recall someone mentioning a while ago that it is as fast at both, which made me wonder why Club Dive and Checkered Flag went the flat shaded route.
By the way, have you guys seen Stratas arcade racer called Drivers Edge. Here is a video and screenshots:
http://www.gamesdbas...ivers-edge.aspx
Kinda has a Jaguar game look to it due to the gouraud shadding, huh. Again, i really like that graphic style and maybe if F1 World Tour had gone that direction, it would have run smoother. So does something like Drivers Edge look like its out of the Jaguars league?

Edited by sd32, Sat Sep 24, 2011 6:11 PM.

[kskunk]

sd32, on Sat Sep 24, 2011 6:07 PM, said:

Sorry if i am a bit off topic here and if my questions are dumb for those with knowledge, but i have to know, is the Jag as fast at doing flat shaded polygons as it is doing gouraud shaded ones? I seem to recall someone mentioning a while ago that it is as fast at both, which made me wonder why Club Dive and Checkered Flag went the flat shaded route.

Flat shaded polygons are faster because they require less setup and could be twice as fast if they're done in 8-bit color mode instead of the 16-bit color mode used by gouraud shading.

The programming is more complicated for gouraud shading, and that may be the main reason they went with flat shading. The Jaguar was pretty hard to program at a basic level. Really pushing the Jaguar required techniques that had just been invented and weren't too well known, and tools that Atari never bothered to provide.

- KS

[Zerosquare]

The big problem with 3D on the Jag is that the blitter can't draw a complete triangle in a single pass, unlike the PS1 (for example). You have to split each triangle (or polygon) into individual segments yourself, and "feed" them to it one by one, which is wasteful.

[kool kitty89]

kskunk, on Sat Sep 24, 2011 7:57 PM, said:

sd32, on Sat Sep 24, 2011 6:07 PM, said:

Sorry if i am a bit off topic here and if my questions are dumb for those with knowledge, but i have to know, is the Jag as fast at doing flat shaded polygons as it is doing gouraud shaded ones? I seem to recall someone mentioning a while ago that it is as fast at both, which made me wonder why Club Dive and Checkered Flag went the flat shaded route.

Flat shaded polygons are faster because they require less setup and could be twice as fast if they're done in 8-bit color mode instead of the 16-bit color mode used by gouraud shading.

The programming is more complicated for gouraud shading, and that may be the main reason they went with flat shading. The Jaguar was pretty hard to program at a basic level. Really pushing the Jaguar required techniques that had just been invented and weren't too well known, and tools that Atari never bothered to provide.

- KS

Flat shaded polygons can also render in 15-bit RGB . . . and Checkered flag does a "fade to white" distance fog effect that looks like what some other flat shaded 15-bit RGB renderers did. (not sure about club drive)

Zerosquare, on Sun Sep 25, 2011 2:35 PM, said:

The big problem with 3D on the Jag is that the blitter can't draw a complete triangle in a single pass, unlike the PS1 (for example). You have to split each triangle (or polygon) into individual segments yourself, and "feed" them to it one by one, which is wasteful.

Yes, though for developers of 1993-1995 (and some into 1996), the majority of systems capable of any sort of polygonal 3D also rendered that way. (be it older 16-bit machines like the ST, 68000 Amiga, older PCs, Older Macs, X68000 -in Japan, Genesis, Sega CD, or newer PCs with a lot more CPU grunt expected of them -ie games starting to demand 33/40 MHz 386s and beyond as the bare minimum for running games at reasonable detail levels, and the 32x and later Pippin doing similar with an all-CPU approach)

The 3DO was the earliest exception on the consumer market (arcade boards and possibly some workstations prior to that -though I think most SGI stuff was also using CPU+DSP brute-force rendering), and only in the mid 90s did the PSX, Saturn, and a variety of PC accelerators appear, and not until a bit later still did those truly become the defacto standard. (ie hardware rendering . . . not quad based rendering or a few other things that appeared briefly in early 3D systems -plain affine texture mapping didn't last long either . . . even some software renderers on PC were offering pretty significant partial-correction for textures in the mid 90s -you can barely see warping in DOS Quake)


Of course, that doesn't change the fact that the way the Jag renders 3D adds a lot of overhead compared to full hardware polygon rasterizers. (and the way the blitter is set-up limits GPU multitasking considerably -at one point Gorf mentioned how useful a blitter command cache could have been, though the Jaguar II opted for double buffered blitter registers to similar effect -facilitating pipelining of GPU assisted drawing operations)

There are some notable advantages of line by line rendering though (or at least things you can take advantage of if you're already forced to render that way). One advantage is the ability to segment lines of textures into distinct horizontal lengths at regular intervals with each segment having perspective recalculated (to reduce texture distortion compared to only calculating perspective at the end points of each polygon with linear interpolation between said points). Quake does that to effectively allow pespective correct rendering (or very limited distortion compared to contemporary affine renderers on PC, 3DO, PSX, and Saturn). Hardware renderers can use a similar method of segmentation, but it requires subdivision on a polygon basis rather than a line basis (ie breaking a polygon into several polygons to render separately) and it's done on a per-polygon basis rather than a per-screen basis. (albeit hardware designers could have intentionally added features to allow partial perspective correction with subdivision on a screen basis similar to Quake -still much simpler than full perspective correct rendering like the N64 does, but no hardware offered that AFIK)

sd32, on Sat Sep 24, 2011 12:44 PM, said:

Can anyone point to an example of a game with a very advanced engine that works only with gouraud shadded polygons, it doesnt matter the platform. I love the look of games like Battlemorph in the Jag, and wonder how a similar game would look like on a more advanced system. Saturn and PS1 dont seem to have anything that looks like it, so maybe on PC from the mid 90s...

Unfortunately, no, untextured gouraud shaded polygon engines fell out of favor with the advent of hardware acceleration, though even before that you had some totally texture-emphasized polygon games (ie Wing Commander III, IV, and Quake -prior to the accelerated version of the latter, and of course there's numerous later games that offered software renderer modes, and prior to acceleration you had some very texture heavy non-polygonal games like Doom and Duke 3D). There were actually a few earlier accelerators that didn't support texture mapping at all (or well) and did g-shading much better (I think some of the really early Matrox cards did that) but very few games took advantage of those.
Granted, there were some later-gen stylized games that used limited textures with a lot of emphasis on shaded polygons. (a fair amount of PSX and N64 games did that too -more so for the latter, though some of the textures on the N64 were so low res that they looked more like G-shaded polygons due to the blurring/blending )

It's even worse in the arcades since G-shading didn't even catch on until after texture mapping. (Namco System 21 and Sega Model 1 were flat shaded only, Sega Model 2 added textures and spectral reflection effects but no smooth shading, Namco System 22 added gouraud shading as well as texture mapping and other effects)


On PC, the most advanced fully untextured polygon based game I can think of is Tie Fighter, and that still only ran in 256 colors. Smooth shading was facilitated by use of an optimized palette (emphasis on shades over colors to some extent, and Star Wars ship models tending to be relatively gray-intensive anyway) and use of realtime dithering (one of the few non-accelerated games to do that). The game has a 640x480 high-detail option (320x200 is default) that makes the dithered shading much less grainy as well as reducing jaggies in general.

Other than that, there's a few online games (JAVA based, etc) that use heavily untextured models (usually with limited use of textures). Rune Scape comes to mind in that regard, though the more recent updates allow high-detail modes with heavier texture use. (I think low detail also only runs in highcolor, not truecolor given the banded -or grainy with dithering on- shading, so still not a great example of "ultimate" G-shaded polygons)


The ideal example simply doesn't exist since texture mapping came in long before 24-bit rendering became common (since no others used custom colorspaces for smooth shading, it wasn't until 24-bit that you'd see stuff beating the Jaguar in that regard). It sounds like you're describing a dreamcast or late 90s high-end gaming PC class truecolor game without texture mapping.



However, while no such examples of untextured games are really available, there is another area the Jaguar excelled at that was demonstrated in a handful of later gen games: flexible non-polygonal or mixed renderers using "pseudo 3D" techniques (mainly ray-casting based height maps, a la doom, duke 3D and the related -but very different looking- voxel terrain renderers like Commanche and Phase Zero).
There's Amok on PC and Saturn (and a demo on the 32x recoded in the Scavenger demo tape) with rather coarse voxels (much less impressive than phase zero) as well as polygonal models, and there's also the Blade Runner adventure game on PC using voxels.
The best example of a really flexible renderer came slightly later though, and that's with Outcast on PC.
That game went back to the old all-CPU rendering methods (since graphics cards of the time weren't flexible enough to do it in hardware -and available APIs weren't oriented to exploiting those cards to partially accelerate "alternative" rendering methods) and used a combination of texture mapped and shaded polygons, textured height-mapped spans (like Doom/Duke3D), voxel terrain (not sure if they're unfiltered or interpolated like Phase Zero -still need to try this game myself ), and a water effects engine. (the latter seems to mainly use a distorted spectral reflection effect for water surfaces)

[kool kitty89]

kskunk, on Sat Sep 24, 2011 1:13 PM, said:

I'd encourage you to create equations to do proper, saturating, smooth gouraud shading with Y > 1.0. However, the best I can come up with requires 9 multiplies and 9 additions. This is WAY more hardware than the 3 multiplies and 0 additions used in the Jaguar's CRY. I can't think of a good way to fit any of this into a look-up table smaller than thousands of entries, which wouldn't fit on the chip, either.

Oh, OK . . . that's an issue with the Jaguar not actually outputting CRY colorspace directly, but using 24-bit RGB. (and not a massive 65536x24-bit table to define every single CRY color to its approximate 24-bit RGB value)
It just uses a 256x24-bit table for chroma and interpolates luma in realtime. (something relatively simple for shading towards black, but not straightforward for desaturating/shading towards white)
For the same reason, you couldn't choose to alter the color temperature for lower intensities to better simulate human perception of darkness. (albeit you could take advantage of that on more limited platforms stuck with 256 color rendering -opt to desaturate approximately towards cool gray for darkening shades, better fitting to the 256 color limits and human perception in the real-world; much nicer than just posterizing towards approximate colors/shades)


Shading/desaturating towards white also drops many more unique color/shade values than shading towards black in RGB (ie my suggestion of 128 shades towards white would have far fewer unique colors on the "white" side than the lower 128 shades towards black -with far more limited redundancy).

Given those limits of shading towards white, you probably aren't that much worse off just manipulating chroma for added shades via look-up. (as it is, you'd have to do that in software -like Doom or other 256 color games using remapped colors lighting- but hardware support for that might have been practical too -a fairly small look-up table for shading colors beyond max intensity by manipulating chroma values; granted doing that in software allows the flexibility of a custom LUT rather than a fixed one -unless they made it an on-chip RAM LUT and not ROM)

And I say a "small" table as (practically speaking) you're not going to get that many shades towards white just by remapping chroma values to other chroma values. You could do better by desaturating completely towards gray . . . or using a LUT in addition to Y manipulation for brighter shades, with the LUT acting to smooth out transitions towards gray. (a simpler but uglier method would be to make a hard transition to gray after hitting max intensity of any non-white color, approximating the lumiance value of that color and doing grayscale shading up towards white, but using a LUT to transition from a color to grayscale would look much nicer)
Plus, in the software case, you could opt to shade towards other colors than white/gray too, like desaturating towards a blueish gray (for overcast skies) or sky blue (for a sunny day). Phase zero seems to shade/fade towards the sky color in that manner. (and it works quite well)




Then there's still my question to whether a 4-4-4-4 RGBI scheme would have been technically expensive to implement in addition to CRY, or possibly in place of CRY. (albeit the latter case totally contradicts Flare's goals with CRY, but the former is much nicer than only having CRY and limited use of 15/16-bit RGB)

Quote

I know we end up here a lot, but the Flare engineers were very good. Their problem was they started with the wrong requirements, not that they left low hanging fruit behind!

And as I've said before, they certainly made good choices (overall) given the limited perspective they had to work with in 1989-1991. (probably the only big mistake on the graphics end was putting so much logic towards Z-buffering rather than other things . . . the bugs in the RISCs obviously weren't oversights and arguably wouldn't have been much better if more emphasis on ease of programming the RISC chips was made a higher priority than it was -let alone implementing things like a dynamic cache- . . . one could argue the DSP is overkill for the types of audio that became popular -ie mostly MOD-like sample based stuff- but, had it not been for the bugs, the DSP still would have been a very versatile and useful general purpose coprocessor in the system)

Quote

I think you're misunderstanding what they meant. It is true that red contributes less to perceived intensity. But when intensity is provided by an 8-bit channel already, this is not about intensity. Rather, this is about how your eye differentiates subtle differences in color at the same intensity. From this perspective, which is the one that matters when choosing CR, it is correct that green is less important.

Blue is actually most important. Humans are very good at differentiating shades of blue. Some people think this is related to outdoor depth perception, because distant objects turn very subtly blue due to atmospheric effects.

OK, that makes more sense than the impression I'd gotten.

However, from what I've seen, blue isn't easier to discern shades of (at least not pure blue from the RGB scale).
Unless I'm some weird exception . . . or the RGB color tables I've looked at are off, or all the monitors I've been using are mis-calibrated.

When I look at this:
http://upload.wikime..._test_chart.png


Plure blue is by far the hardest to discern shades of, then purple/magenta, and red is 3rd hardest to see of the 6 primary colors. Cyan seems the most obviously visible followed by green and yellow.

Then again, you mentioned atmospheric effects and depth perception being prime reasons for human perception of blue, but "sky blue" is not very close to pure blue of RGB at all and is much closer to cyan (which showed very obvious contrast to me) though not quite right for that either.

Edited by kool kitty89, Sun Sep 25, 2011 6:31 PM.

[kskunk]

Quote

However, from what I've seen, blue isn't easier to discern shades of (at least not pure blue from the RGB scale).
Unless I'm some weird exception . . . or the RGB color tables I've looked at are off, or all the monitors I've been using are mis-calibrated.

This is still sort of on-topic because we're talking about how CRY works, right?

Anyway, you're still focusing on "shades" which is intensity. That blue line you're looking at is a blue intensity chart. Intensity is not what they're talking about, CRY has plenty of resolution there. They're talking about color.

It's hard to separate color from intensity when you look at RGB charts, because RGB doesn't have a concept of intensity. However, human vision does separate color from intensity, and this is a key part of understanding CRY and other color spaces.

I'll try not to go into too much detail, because it gets off topic. If you're really interested in this, try this link:
http://r0k.us/graphics/SIHwheel.html

Look around the outer edge of the color wheel. These pixels all have similar intensities but different colors. Notice how the 'banding' or 'stair step' effect is stronger in the blue and red portions of the wheel, while the green part of the wheel looks 'smoother'.

This is because your eyes are less sensitive to subtle changes in green-ness (again, not green intensity), but much more sensitive to changes in red-ness and blue-ness.

As for the color of the sky, it probably depends on where your particular vision system evolved. Those of us living up in northern latitudes see a different color sky than our ancestors. To further complicate things, color perception is different from person to person, and the wavelengths detected by your 'blue cones' cover a lot of shades of blue green as well. Okay, okay, back to Jaguar talk please!

- KS

Edited by kskunk, Sun Sep 25, 2011 7:46 PM.

[sd32]

Its a shame that Strata didnt create more 3d games with Drivers Edge hardware, because as you can see in this video, http://www.gamesdbas...ivers-edge.aspx, i think it gives a good impression of what a late gen gouraud shadded racer would have looked like in the Jaguar.

[kool kitty89]

kskunk, on Sun Sep 25, 2011 7:29 PM, said:

Anyway, you're still focusing on "shades" which is intensity. That blue line you're looking at is a blue intensity chart. Intensity is not what they're talking about, CRY has plenty of resolution there. They're talking about color.

Yes, shades as in intensity/lumiance values of a single hue/color . . . that's what I thought you meant when you said: "Humans are very good at differentiating shades of blue."

Quote

It's hard to separate color from intensity when you look at RGB charts, because RGB doesn't have a concept of intensity. However, human vision does separate color from intensity, and this is a key part of understanding CRY and other color spaces.

Doesn't RGB, by definition, have clearly defined intensities for the 6 primary colors (and black/white/gray)?

Quote

I'll try not to go into too much detail, because it gets off topic. If you're really interested in this, try this link:
http://r0k.us/graphics/SIHwheel.html

Look around the outer edge of the color wheel. These pixels all have similar intensities but different colors. Notice how the 'banding' or 'stair step' effect is stronger in the blue and red portions of the wheel, while the green part of the wheel looks 'smoother'.

This is because your eyes are less sensitive to subtle changes in green-ness (again, not green intensity), but much more sensitive to changes in red-ness and blue-ness.

Oh, you didn't mean differentiating different shades of blue (as in different luminance values of a single hue -pure blue in this case), but different "shades" as in different hues that are relatively near the blue end of the spectrum.

Sorry, I nearly always see "shades" being used to describe brightness/intensity/luminance, not differing colors/hues.


Also, are those colors really using identical (or as close as possible) intensity levels?
Would that be intensity on the RGB scale or YCbCr (or similar) scale? (that would be significantly different, and YCbCr hues of the same intensity should show far less "stepping" than RGB values at equal RGB intensity levels, that's just the way the RGB scale works -it's not a very close representation of human color/intensity perception at all)
That's obviously RGB color and almost certainly RGB brightness scale . . . especially since desaturating it to grayscale yields significant banding. (albeit if it was RGB, and you were to desaturate using only RGB levels -ie averaging R/G/B to 8-bit grayscale- you should get rings of solid gray -and I can only guess that the desaturated display viewed by double clicking the center of that color wheel is using YCbCr intensity to convert to grayscale rather than unweighted RGB -ie the same way properly calibrated monochrome VGA monitors work, compensating for human perception of lumiance)

Quote

Okay, okay, back to Jaguar talk please!

- KS

OK.
Any comments on the merits of using a 4-4-4-4 RGBI colorspace? (again, it obviously doesn't match flare's primary design goals,but may not have been unrealistic to consider as an "extra" mode . . . or aside from that, still seems like a nice compromise for a 16-bpp colorspace in general over contemporaries using 15/16-bit RGB -usually 15-bit, especially in terms of fitting with 24-bit RGB video output -and works exclusively with 4-bit logical boundaries)

sd32, on Sun Sep 25, 2011 8:06 PM, said:

Its a shame that Strata didnt create more 3d games with Drivers Edge hardware, because as you can see in this video, http://www.gamesdbas...ivers-edge.aspx, i think it gives a good impression of what a late gen gouraud shadded racer would have looked like in the Jaguar.

This is getting a bit off topic, but:

Honestly, I don't think trying to push polygonal 3D on the Jag in general was the best route. Many, many "3D" genres could be done better at the time using non polygonal methods (or with limited use of polygons where necessary). Height maps are the prime example, both flat vertical/horizontal spans (ie floors/walls in Doom/Duke3D/etc) or voxel terrain renderers. Neither of those were unheard of when the Jaguar launched (though voxels were newer than ray-cast spans as far as commercial games went), but relatively few of the "3D" games used those, especially voxels. (let alone in the early releases)

I'm not saying games would have been Phase Zero quality, but expecting Commanche I level voxels in 1994 (maybe 1993 -would have been awesome for cybermorph) wasn't unreasonable for the time.

Another missed opportunity is using low resolutions to allow otherwise fairly impressive (for the time) 3D and pseudo 3D at realistic framerates. (more so since you could potentially use a separate high-res overlays or backdrops -of varying color depth- in separate OPL windows -though with some added OPL overhead compared to just 1 low res layer; another mixed-res option would be changing res on a per-line basis with status/score in the high-res boarder with the in-game window at low-res)

People seem to complain about small screen sizes and low framerates much more than blocky low-res graphics. (Jaguar Doom definitely paid-off big time for halving the horizontal resolution on the Jaguar -32x and SNES obviously needed that too . . . 3DO Doom really should have done it, as should several jaguar games -especially AvP since it's a ray-caster like Doom and halving the horizontal res also halves the number of rays to cast, so proportionally more savings than a polygon renderer doing the same)

Chilly Willy's Yeti 3D demo on the 32x demo at 160x112 in highcolor mode seems to get fairly positive comments too. (it's software scaled -some versions interpolate- to 320x112 and then line doubled by the VDP to 320x224 -32x has a fixed horizontal resolution)

Several 3D/pseudo 3D DOS games often allowed dropping the screen size, but rarely allowed dropping the actual resolution below 320x200, but the Jaguar has the ability to actually render at lower resolutions natively. (so even less overhead than writing 2 or 4 pixels in a row/group)

[kskunk]

kool kitty89, on Sun Sep 25, 2011 11:41 PM, said:

Doesn't RGB, by definition, have clearly defined intensities for the 6 primary colors (and black/white/gray)?

I guess it could depend on your definition of intensity. But if you mean it in the "Y" sense as I do, no. Intensity doesn't have a standardized definition in RGB. Google "gamma correction in RGB" for the whole scoop. From epic, endless, discussions on other forums, I've learned that RGB is very poorly standardized, gamma is all over the map, different TVs, different video cards, and different video standards all result in different intensities, and of course - color is all a subjective thing in the human brain in the first place. Trying to be too concrete about this will just end in endless tedium.

Anyway, back to the CR in CRY: I think they selected a pretty sensible 256 color palette for CR. But I agree with your other comments about how cool it would be to have a programmable CR palette instead of a hardcoded one.

Unfortunately, RAM is at least 6 times bigger than ROM, and Tom was already way too big. So to add that feature, something else would have to give.

You can't just move the programmable palette that already exists in Tom to the back end with the CRY multipliers -- if you did that, all the cool semi-transparent blending effects in the Object Processor would stop working with palette-based sprites. It's just tradeoff after tradeoff, and you can really get a feel for what Flare was going for by looking at all the tradeoffs they made.

Quote

Any comments on the merits of using a 4-4-4-4 RGBI colorspace? (again, it obviously doesn't match flare's primary design goals,but may not have been unrealistic to consider as an "extra" mode . . . or aside from that, still seems like a nice compromise for a 16-bpp colorspace in general over contemporaries using 15/16-bit RGB -usually 15-bit, especially in terms of fitting with 24-bit RGB video output -and works exclusively with 4-bit logical boundaries)

The main reason I don't get 4R4G4B4Y is that it seems to have nearly the same color expressiveness as CRY. That is, the main downside of CRY is that 4C4R makes big blocky color bands. But the color bands with 4R4G4B are just as blocky and chunky.

Also, CRY does a pretty good job of maximizing unique colors and spreading them out evenly, where RGBY distributes colors less evenly -- try plotting them both if you want to see what I mean. With people already complaining about CRY being chunky, this wouldn't help.

If you're more excited about RGBY because it allows additive effects to be more like they were on the Playstation, saturating toward white, it would get you this, but the tradeoffs seem kind of lousy.

It would be less hardware to just due proper saturating on 15/16-bit RGB. Of course you wouldn't get that smooth CRY lighting trick, but if you're resorting to RGBY you probably didn't want that anyway!

- KS

Edited by kskunk, Mon Sep 26, 2011 1:19 AM.

[kool kitty89]

kskunk, on Mon Sep 26, 2011 1:16 AM, said:

Anyway, back to the CR in CRY: I think they selected a pretty sensible 256 color palette for CR. But I agree with your other comments about how cool it would be to have a programmable CR palette instead of a hardcoded one.

Unfortunately, RAM is at least 6 times bigger than ROM, and Tom was already way too big. So to add that feature, something else would have to give.

Yes, making the 256x24 table programmable would have significant trade-offs.
And the idea of a totally customized colorspace interpolated to 24-bit RGB, as already mentioned, would take far too much space even in ROM (192 kB to remap all 65k entries to 24-bit RGB).

However, I wasn't suggesting programmable CRY hues in my previous post, but use of look-up tables to offer limited shading outside the normal CRY range. (similar to what can be done in software currently, but with hardware support) Except that has the same trade-offs with RAM as above, and using a ROM table would limit that more (and still use added chip space).
Plus, you'd need different tables for different types of effects. (ie distance fade towards x color/shade vs things like explosions or lens flares)
Obviously, the coarser/blocker/less optimzied the shading effects could be made (without being unacceptably ugly), the smaller the look-up tables could be for such effects. (and for effects, you can already approximate some things somewhat adequately without added tables, like coarsly shading towards cyan if you wanted to fade towards a sky gradient that was near that color -or red for a sunset-, or you could use a small table to drop to grayscale in the distance and fade out from neutral gray to white -the best looking effects would require large tables though, so added overhead and RAM usage)

Quote

The main reason I don't get 4R4G4B4Y is that it seems to have nearly the same color expressiveness as CRY. That is, the main downside of CRY is that 4C4R makes big blocky color bands. But the color bands with 4R4G4B are just as blocky and chunky.

Also, CRY does a pretty good job of maximizing unique colors and spreading them out evenly, where RGBY distributes colors less evenly -- try plotting them both if you want to see what I mean. With people already complaining about CRY being chunky, this wouldn't help.

If you're more excited about RGBY because it allows additive effects to be more like they were on the Playstation, saturating toward white, it would get you this, but the tradeoffs seem kind of lousy.

Wouldn't 4-4-4-4 RGBY allow much more even color blending than CRY does? (ie using averaging of the 4, 4-bit channels compared to blending of CRY hues -without use of additional large look-up tables for blitter/GPU rendered stuff -more so for OPL object effects which can't practically use look-up blending) And on top of that, potentially allow for more than just 50/50 averaging for such translucency effects?
The blitter and OPL can't do any shading/blending effects in 15/16-bit RGB mode, right? (no transluecent blending, no shading, etc)

Since it's organized on 4-bit boundaries, wouldn't RGBY allow the existing Jaguar blitter to shade in that colorspace. (which it can't do in 5-5-5 or 5-6-5 RGB -and can in 8-8-8, but that's impractical to use in general)

A 8-4-4 YCbCr scheme would also blend more evenly than CRY, but have the other trade-offs mentioned (less than 256 unique hues, poorer color distribution, etc), and if they offered it in addition to CRY, that would mean a second 256x24-bit ROM LUT. (unlike RGBY, which corresponds directly to 8-8-8 RGB)

Having 4-4-4-4 RGBA would be far more useful and flexible still, but that would be more complex than RGBI/RGBY. (and more practically useful than 8-8-8-8 RGBA; albeit you did mention that would have been relatively simple to add in place of that grayscale test mode)

Quote

It would be less hardware to just due proper saturating on 15/16-bit RGB. Of course you wouldn't get that smooth CRY lighting trick, but if you're resorting to RGBY you probably didn't want that anyway!

It would take less hardware to support 15-bit RGB than it would for blitter shading effects in 4-4-4-4 RGBY?

In any case, you could still offer a "mixed" mode with per-pixel definition of 15-bit CRY/RGB, or RGBI (or RGBA if that was realistic), though for the 4-4-4-4 scheme, you'd have a greater trade-off for dropping the added bit than 5-6-5 RGB. (you'd probably drop to R4-G4-B3-Y4)

[kool kitty89]

I was thinking specifically on RGBI/RGBY again, and noticed I previously suggested having the 4-bit I/Y act as the lower 4-bits of each 8-bit RGB element of 8-8-8 RGB. Now, that would technically work as a colorspace, but it would be a bit odd. (the Y/I value would be effective for fine tuned 16 level shading for any color/shade of 12-bit RGB, but not actual bright/drak shading -to do that, you'd need to manipulate the 4-bit RGB elements, or do that along with modifying Y/I)

A more realistic route (and the one I was thinking of conceptually -but misspoke with the "bottom 4 bits" comment) would be to have Y/I define offests of 12-bit RGB within 24-bit RGB. (ie have 12-bit RGB able to be offset in 16 different levels to traverse the entire 24-bit range -ie I/Y set to zero would allow RGB elements to each go to 0-15, Y set to 1 would allow 16-31, etc) Thus you'd have 16 levels of intensity for the entirety of 12-bit RGB.

However, that doesn't just mean 16 shades of every color/shade of 12-bit RGB (and the ability to shade towards RGB/CYM colors), but the possibility for far smoother shading than just those 16 levels for many colors if you manipulate both RGB and Y values for shading effects. (you'd have a full 256 shades for many colors, not too much less for some others, and more than 16 brightness levels for every single 12-bit RGB color)
You'd just have to be able to manipulate each of the 4 color/intensity elements independently (ie clamping at 4-bits for max/mimimum saturation, avoiding overflow/underflow and rollover errors). Alpha blending effects would involve averaging those 4-bit elements.
White/black shading would be done using all 4 elements, colored shading would manipulate 1 or 2 of the RGB elements. (and would obviously be coarser -coarser than 15-bit RGB too)
You could also manipulate I/Y alone for coarser/more limited shading/lighting.


That would provide a true 65,536 unique colors/shades (unlike CRY -using 24-bit RGB output- and 15-bit RGB) since it corresponds directly to 24-bit RGB (without redundancy) and effectively allow similarly smooth shading as CRY (since CRY in 24-bit RGB would have the same coarse areas of redundant colors as RGBY would with colors that simply have fewer true shades). The only disadvantage to plain 15-bit RGB would be poorer colored lighting and somewhat weaker alpha blending for certain colors. (but making up for that in better luminance resolution)
And it's working purely on 4-bit boundaries.



Hmm, actually, using 4-bits of "intensity" that did only control the lower 4-bits of all 3 8-8-8 RGB elements could be logically/mathemetically simpler to implement for shading than using 16 segments of 12-bit RGB . . . or if not simpler, able to avoid artifacts of the segment method that would appear without greater complexity to prevent them.

For the segment method to shade smoothly, you'd want to modify all 3 RGB elements (add or subtract -for brighter/darker) until you couldn't shade any futher, then you'd switch to the next brighter/darker Y shade bank and start over with the original 12-bit color value, but that would lead to bands of desaturation (towards black/gray/white) at the fringes of each shade segment transition (more so for colors further from the 6 primary colors and gray) and to prevent that you'd need to set the intensity segment to change once any RGB element reaches 0 or 15 (depending on whether you're shading towards white or black), so you'd need logic to check for that.

With 4-bits of "intensity" only controlling the lower 4-bits of each 8-8-8 RGB element, you wouldn't have that problem (though modifying Y alone would have only a subtle impact on shading); in that case you could increase/decrease Y until it hit 15 or 0 (depending on bright or dark shading) and then shift the RGB elements for the next shade step along with cycling Y to 0 or 15 (if it had just hit 15, it would change to 0, if 0 it would change to 15) and then continuing to shade the next 16 Y levels before modifying RGB again. Once you did hit one of the RGB boundaries (like 15,9,9 or 0,5,5) you could clamp the maxed value and continue to shade with Y and any non-maxed RGB elements until you got to black or white -as that wouldn't induce banded fringing issues as the segmented intensity space would. (you'd only need to know when Y hit 0 or 15 -to tell when to modify RGB, and you'd also smoother overall shading than the 16 level segmented RGBY since you wouldn't be skipping values to avoid fringing)


Even if that wasn't practical to implement on the Jaguar, it would still be a very attractive 16-bit colorspace to use in general for systems with 24-bit color DACs. (a system directly outputting YPbPr/YUV could effectively use 8-4-4 YCbCr instead . . . technically the Jag could have used YPbPr for analog output instead of RGB, but that would mean using a less common -but technically simpler- external composite/s video encoder -and the old TMS9928 did just that- and also need external circuitry for RGB output -though analog YUV to RGB is relatively simple to do . . . maybe Atari should have done that with the Jaguar -digital YUV to RGB inside JERRY was obviously impractical, but actually using YUV/YCbCr in general and only doing conversion to other formats externally on the analog end -or maybe embedding the analog transcoding circuitry as well, more like some old console/computer video chips with native Y/C and/or composite output)

[JagChris]

Zerosquare, on Sun Sep 25, 2011 2:35 PM, said:

The big problem with 3D on the Jag is that the blitter can't draw a complete triangle in a single pass, unlike the PS1 (for example). You have to split each triangle (or polygon) into individual segments yourself, and "feed" them to it one by one, which is wasteful.

I wonder if the hack that Scatologic discovered for the Blitter improves performance in this area.

[Zerosquare]

Dunno, but even BattleSpehere's 3D stuff doesn't look good when compared to the PS1.

[JagChris]

Zerosquare, on Sat Oct 1, 2011 9:14 AM, said:

Dunno, but even BattleSpehere's 3D stuff doesn't look good when compared to the PS1.

We are aware its never going to be a 3d engine like the PSX but just wondering out loud if the 'Blitter Trick' improved the Jags lot at all in throwing polygons to the screen.

[sh3-rg]

JagChris, on Sat Oct 1, 2011 10:50 PM, said:

We are aware its never going to be a 3d engine like the PSX but just wondering out loud if the 'Blitter Trick' improved the Jags lot at all in throwing polygons to the screen.

BS/G never really throws around all that many polygons at once from what I've seen. I'm not sure it is doing anything particularly taxing or performing special or 'secret' tricks with the Jaguar hardware. I'm not basing that on any technical understanding of the hardware or the game, only the fact that it appears to run in Virtual Jaguar when other games (ones that are seen as being average or poor games, both technically and gameplay-wise) do not. Maybe that's not the best way to judge these things, but from using emulators of many systems in the past, it's usually the special-case games that abuse the hardware that are the last ones to be supported.