PC-FX homebrew development.

[TheOldMan]

May I ask why you do

"if (leftvol > 63) leftvol = 63;
 if (rightvol > 63) rightvol = 63;"

rather than
"
 leftvol &= 63;
 rightvol &= 63;
" ?

And does it work right if leftvol = -1? I believe HuC has some problems with mixed mode compares.

(ie, 63 is an int (presumably signed) and leftvol is unsigned char; Huc doesn't sign extend afaik, so
 it's possible to get things that seem to work in most cases...but not in all)
I know its not HuC, that's why I'm asking.

[NightWolve]

I wondered about that. It all depends on what causes less cycles. If it's generally false 90% of the time, maybe quick value tests and a jump are faster than always AND'ing and assigning/writing to a memory location. You guys would know, maybe Rover cycle tested his code. I wanna agree it could be faster your way, but I'd wanna test it, dunno.

[nodtveidt]

May I ask why you do

"if (leftvol > 63) leftvol = 63;
 if (rightvol > 63) rightvol = 63;"

rather than
"
 leftvol &= 63;
 rightvol &= 63;
" ?

Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts.

[elmer]

May I ask why you do

"if (leftvol > 63) leftvol = 63;
 if (rightvol > 63) rightvol = 63;"

rather than
"
 leftvol &= 63;
 rightvol &= 63;
" ?

Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts.

That's not exactly "clever" C code ... "+=", "-=", "*=", "/=", etc are pretty standard stuff.

OTOH ...
  if (leftvol > 63) leftvol = 63;
is actually very different to ...
  leftvol &= 63;

Your version clamps an over-the-limit value of 64 to the maximum of 63.

NightWolve's version wraps 64 back to 0 (which is pretty-much-never what you want in practice).

Given that neither are particularly good end-results, and that you're programming for a fairly-slow videogame console and not a medical life-saving device ... IMHO it's best not to waste the CPU cycles by even trying to clamp/wrap it, and just leave it up to the programmer to feed it legal values.

[nodtveidt]

I've always said that we should just remove the safeguards and let the problems solve themselves... but I was just being cautious, as I tend to do. I'll remove all safeguard code from my work and also not add any in the future.

[nodtveidt]

Okay so I guess one thing we're going to need is some utility tools to convert graphics and other such things.. if stuff like this does not already exist, I can spend this weekend working on such things.

[NightWolve]

NightWolve's version wraps 64 back to 0 (which is pretty-much-never what you want in practice).

Uh, you mean OldMan? I only wondered which version uses less CPU cycles factoring in the % rate that over 63 is possible. If it's 9X% false in general use, then I'm guessing reading those variables and always writing back to them with an AND operation will take more CPU cycles versus a cmp to 63 and jumping over the assignment/writing of 63 to the variable. I'm not sure either way, but I think a test is worth it to know what's fastest to keep the library code fast if such safeguards are really needed (sounds like they might not be).

But anyway, good point if his AND'ing with 63 would cause a wrap back to 0 with 64 which rules out considering it at all... I thought it was legit code to accomplish the same result at first glance and simply compact but doubted the CPU cycle gains in switching.

[nodtveidt]

I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4. I'm going to assume that Y is the upper 8 bits, U is the high nybble of the lower 8 bits and V is the lowest nybble... someone please correct me if I'm wrong. I am going to be using this formula:

Code: [Select]

Y = (0.299*R) + (0.587*G) + (0.114*B)
U = ((B-Y)*0.565) / 4
V = ((R-Y)*0.713) / 4
YUV = (Y << 8) + (U << 4) + V
If any of this is wrong, I'd like to know...

EDIT: Fixed mah formula!

[elmer]

Uh, you mean OldMan? I only wondered which version uses less CPU cycles ...

Sorry, I got confused!  :oops:

I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4. I'm going to assume that Y is the upper 8 bits, U is the high nybble of the lower 8 bits and V is the lowest nybble... someone please correct me if I'm wrong. I am going to be using this formula:

Code: [Select]

Y = (0.299*R) + (0.587*G) + (0.114*B)
U = ((B-Y)*0.565) / 2
V = ((R-Y)*0.713) / 2
YUV = (Y << 8) + (U << 4) + V
If any of this is wrong, I'd like to know...

I'm afraid that my graphics toolchain still needs a lot of cleanup before it's shareable.

I've got 131 undocumented options in there now from 25+ years of "just-get-it-done" ... it badly needs some TLC before anyone else would find it useful.

But here's the palette code that I added to it for converting graphics for Zeroigar.

It's not pretty, but it worked.


        float fl___R = (float) pcl__P->m_uRgbR; // 8-bit (0-255)
        float fl___G = (float) pcl__P->m_uRgbG; // 8-bit (0-255)
        float fl___B = (float) pcl__P->m_uRgbB; // 8-bit (0-255)

        float fl___Y =
          ( 0.2990f * fl___R) + (0.5870f * fl___G) + (0.1140f * fl___B);
        float fl___U =
          (-0.1686f * fl___R) - (0.3311f * fl___G) + (0.4997f * fl___B) + 128.0f;
        float fl___V =
          ( 0.4998f * fl___R) - (0.4185f * fl___G) - (0.0813f * fl___B) + 128.0f;

        if (fl___Y <   0.0f) fl___Y =   0.0f;
        if (fl___Y > 255.0f) fl___Y = 255.0f;
        if (fl___U <   0.0f) fl___U =   0.0f;
        if (fl___U > 255.0f) fl___U = 255.0f;
        if (fl___V <   0.0f) fl___V =   0.0f;
        if (fl___V > 255.0f) fl___V = 255.0f;

        unsigned ui___Y = (unsigned) fl___Y;
        unsigned ui___U = (unsigned) fl___U;
        unsigned ui___V = (unsigned) fl___V;

        ui___U = (ui___U + 8 ) >> 4;
        ui___V = (ui___V + 8 ) >> 4;

        ui___P = (ui___Y << 8 ) + (ui___U << 4) + ui___V;

        *puw__Q++ = (uint16_t) ui___P;

[nodtveidt]

I was actually wrong on the / 2... it should be / 4 (or >> 4, both work)... realized that when I was taking a shower... why is it that all this stuff comes to me when I'm all wet? Anyway, I recognize that algorithm as well, and I am not sure which one would produce more accurate results... maybe neither, heh.

[elmer]

Anyway, I recognize that algorithm as well, and I am not sure which one would produce more accurate results... maybe neither, heh.

Well ... mine comes directly from the PC-FX SDK documentation, but I'm not sure where yours comes from (especially since you're missing the center-bias on the U & V). 

[nodtveidt]

Mine comes from here:

http://www.fourcc.org/fccyvrgb.php

because I don't have access to such fancypants thingos.

[nodtveidt]

Okay so I implemented the algorithm you have up there... here's the results I get parsing a simple 16 color palette:

Code: [Select]

255 0 255 -> 0x69DF
0 0 0 -> 0x88
36 0 0 -> 0xB89
0 36 72 -> 0x1DA7
72 0 0 -> 0x167A
36 72 144 -> 0x45B7
36 108 180 -> 0x5FB5
144 36 36 -> 0x447B
180 36 36 -> 0x4F7D
144 72 36 -> 0x596A
180 108 36 -> 0x795B
216 72 72 -> 0x737D
216 144 72 -> 0x9D5B
255 144 72 -> 0xA95C
255 216 72 -> 0xD33A
255 180 144 -> 0xC66B
As long as I didn't mess anything up, I assume your implementation should get the same results.

[TheOldMan]

...Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts.

Ok. I do that too.
Asking because I often see the & route used, suposedly being 'faster'.
And because I've had trouble with mixed-type compares...Maybe 0x3f would be 'better' than 63?
personally, I'm not sure though that clamping it is 'better'. I like to know when there are problems with input variables, and no sound would be a sure indication of that
Since I'm not familiar with the machine, or the compiler generated code, I'll leave it  to the experts.

As for the input checks...we do it all the time. It's easy enough to use a #ifdef/#endif to turn them
on/off.

I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4.

Ouch.Good luck.

[nodtveidt]

Okay so now this subforum needs to be changed to Turbo/PCE/PC-FX Game/Tool Development...