16-bit RGB vs 16-bit CRY

[+xucaen]

Based on what I have read in the Jaguar Technical Reference Manual, I could assume that using 16-RGB is faster than using 16-bit CRY. But is it really?

[LinkoVitch]

Faster how? and for what purpose? Been I while since I read anything in there and nothing springs to mind that would imply (to me) that one is faster than the other for general display.

[+xucaen]

First, I can not answer your questions. This is my first time reading. The book says CRY uses a lookup table to get the colors. But RGB does not need a lookup. Wouldn't the CRY lookup add extra ticks?

[LinkoVitch]

Hmm, not sure. I believe the look up would be done within hardware of the OP. No idea if it would take an extra tick or not, but it's a fair assumption that it would reduce the number of pixels it could paint in the same time. One of the hardware boffins would be best suited to answer that question.

 

Personally I tend to use RGB as it works for what I need, as with most things there are pro's and con's with each, some effects are simpler in CRY than RGB and vice versa. I'd imagine the loss of speed would be minimal however and not worry about it unless you have a particularly busy object list with many overlapping objects on a scanline, which is where it would actually affect the system (number of simultaneous objects on a single scanline)

[SCPCD]

The CRY to RGB convertion is made in the pixel data path from the Line Buffer to the Screen, so this doesn't take more cycle from the user point of view since it's in the video output stream. (page 23 of Jag_v8.pdf for more information)

 

Internaly, the screen drawing logic takes account of the CRY2RGB convertion time by adding extra synchronisation for the 16-RGB to 24-RGB convertion. (and so the variable mode, that allow CRY and RGB pixel at same time, could be done)

Edited June 11, 2014 by SCPCD

[MikeFulton]

If I recall correctly, doing 3D rendering with gouroud shading was noticeably faster with CRY mode because only the Y channel needed to be manipulated for the shading.

 

I spent way too many hours on artwork conversion tools for CRY...

[+CyranoJ]

CRY overlays take longer than RGB overlays, as they are additive (easy to prove, as well, by waiting for tearing)

[MikeFulton]

CRY overlays take longer than RGB overlays, as they are additive (easy to prove, as well, by waiting for tearing)

 

What do you mean by "overlay" ?

[+CyranoJ]

CRY RMW (Read, Modify, Write - ie, additive mode) is slower because of the additional bus access when using overlayed bitmaps.

[MikeFulton]

CRY RMW (Read, Modify, Write - ie, additive mode) is slower because of the additional bus access when using overlayed bitmaps.

 

That didn't explain things as much as you may have hoped. Do you mean multiple objects with the object processor where blending is required instead of simple prioritization?

 

Or are you talking about just doing some sort of blending during a normal rendering operation?