shmups.system11.org

I delayed the chroma in the encoder before it gets to the 422-444. Sounds like you'd need to compensate for the shift in the encoder when pixel averaging is on.

That answer doesn't make any sense to me. Using zero-order hold instead of bilinear interpolation in the 422-444 conversion results in a half-pixel shift (relative to luma) which you can't fix by delaying anything because delays can only result in full-pixel shifts.

Ok. Thanks for that, I never thought of checking twitter as I don't use it much. I wonder if there is a way to do it before I install the kit?

It was added at my request for a future project and analog YPbPr.

Just to confirm, it is advised now for WiiDual users to flash citrus3000psi's 2.4c.1, or is Unseen's 2.4d doing the same but better, or still wait for 2.5?

I'm asking since Unseen's last post makes it sound as if the fix implemented in 2.4c.1 is not correct.

I mean that depends on how "easy" it is for you to flash the firmware? If you know what you are doing, have soldering experience and are confident in flashing it real quick without messing it up you can go ahead and flash it right now I guess? However, if you have no soldering experience and you are not really too confident in what you are doing then it is better to update the firmware as little as possible, in that case it would be advised to wait for 2.5 or later.

I mean citrus himself gives you this disclaimer:

It's unrelated to the fix.

Here are screenshots. There seems to be in issue with vanilla 2.4d on the Wii? As the color are inverted? See screenshot below.




Odd Image screenshot of 2.4c.1 with pixel average on


Odd Image screenshot of 2.4c.1 with pixel average off (Yes Luma is not aligned, its 1 pixel to the right)



Even Image screenshot of 2.4c.1 with pixel average on


Even Image screenshot of 2.4c.1 with pixel average off (Luma looks correct)

Just so you know, these are both the same screenshots (with pixel average on).

You somehow managed to implement average off incorrectly, it's shifted left.

Thanks Fixed



It makes sense what unseen is saying, not sure how to fix this....

Would you please be kind enough to explain what the introduction of "pixel average on" and "pixel average off" does and what improvements it is supposed to bring in? Does it affect (Analog) RGB or only YPbPr?

With the "pixel average off" being shifted left/right, I notice that the circle looks more "pixelized" or "aliased", see the circled part in red on the lower left part of the screen:



The screenshot with "pixel average on" on the other hand, looks to not have this problem in comparison.

"pixel average on" is basically what GCVideo has always done, it calculates the missing color values for every second pixel by averaging the color of the left and right pixel - it's a very common method for interpolating 4:2:2 video to 4:4:4. "pixel average off" in citrus' build probably takes the color of one pixel and applies it either to the left or right one. This can make smooth color transitions look more pixelated, especially for colors that are at the extreme ends of the YCbCr color range (e.g. fully saturated red or blue). extrems probably wants it for GBI, because there he's dealing with non-smooth graphics in the first place and disabling color interpolation can preserve the edges of zoomed pixels.


It should affect everything, because the Gamecube outputs YCbCr 4:2:2 and everything else is derived from that.


If you take two identical screenshots with pixel averaging on and off and flip between them, you'll probably notice that the colors move slightly between them, especially in the areas that appear pixelated. That's because the Gamecube sends the brightness for every pixel, but the color only for every second pixel to save RAM and bandwidth. If you then take that color and apply it either to the left or right brightness-only-pixel, you conceptually "smear" the color towards this direction. With pixel averaging on, the "smearing" happens equally in both directions, so the position of the color channels compared to the brightness channel stays the same.

Thanks. I'm a mere user with no ability to do the upgrade myself, so I have to send it out to the modder who did the installation again, at additional cost after paying for the kit and installation. I'd wager a good chunk of users, if not most, are on the same boat.

From the current discussion it sounds like it's more prudent to wait for the video gurus here to sort things out.

The gamecube outputs 422 Luma Chroma information. This is converted to 444, to make up for the missing chroma you either can average or duplicate. Duplication will look better on hard/rough pixel content like GBI.


Those Pixel Average off images are incorrect. They should more look like this. Ignore the OSD, only look at the background content. This is with the chroma shifted right 1 pixel.

Odd Image


Even Image

I found that a zero-order hold give better results for analog YPbPr with consumer equipment.

Yeah I am in the same boat as well, I am on GCVideo 2.4b right now, meaning digital audio is a no-go as it has an issue where digital audio (through HDMI) sound muffled and echoes like if it was coming from a tunnel or something (this is an issue that was fixed by 2.4c) thankfully analog audio does not have this issue, and now 2.4d fixed the "incorrect chroma mixing for Cr-first lines" issue as well. So yeah, if you are going to pay money for shipments and for the modding service, it would be better to wait (in my opinion) and have it done once.




I see thank you for the information, interesting, I was aware that both the GameCube and Wii uses 422 internally as Fudoh explained to me, so I am using the Wii set to Analog RGB in the GCVideo menu + OSSC 1.6 + Extron DSC 301 HD, both the OSSC and Extron uses 4:4:4 chroma and I set the Extron to output in 1920x1080 4:4:4, by any chance might you know if this might somehow "rectify" the issue?

Where are you getting it from?



The update is actually pretty easy. I will update anyone's Wii for free. As long as they:

Take apart the Wii and ship me only the motherboard.
Pack the item appropriately, so I can reuse your packing materials.
Include a return shipping label, that I just need to tape on.

Oh yeah, though by "not easy" I meant from an average joe end-user perspective, not from an expert modder perspective. Average joe's expect to be able to update the firmware easily like they would update their PS4 firmware, or at most insert an SD Card with the firmware inside and click "update firmware" like on an OSSC or Mega Sg for example, with the GCDual or WiiDual updating the firmware is little more complicated than that.




Oh that would be pretty helpful for alot of us who don't feel too confident in updating the firmware ourselves, thank you very much for for letting us know.

That's a nice offer, though it seems that by far the worst part involved in the upgrade process is the disassembly and reassembly of the console.

Yeah, I recently bought a brand new SCPH-3900x PAL PS2, upon trying it out I found that the clock battery was dead (the time wouldn't work and the sphere wouldn't swirl around on the dashboard), I looked on youtube to see how you can replace the battery and holy hell you literally have to take the whole thing apart just to get to the battery:

https://www.youtube.com/watch?v=yFjZ-aVaYzM

Thankfully for the Wii, Nintendo made it so much easier to replace it by just having you unscrew one screw on the side of the Wii (the side where the fan is).

VGP. although I suppose you would've been more local? For some reason I thought you were also in the UK. After Seeing your Twitter page, I realize your US.

I can certainly do the procedure myself, but I guess I'll have to order the programmer.

Is your offer only good for ones you sold directly?

Here is 2.4c.2 for users with WiiDual 1.1
http://dansprojects.com/firmware/WiiDual1.1_2.4c.2.zip

And also 2.4c.2 for WiiDual 1.0 (The 1.0 is not printed on the PCB, just says WiiDual)
http://dansprojects.com/firmware/WiiDual1.0_2.4c.2.zip

This fixes the shift that extrems mentioned earlier.

Thanks for this release. I think I'll try to get this flashed and call my WD done for good. After this there aren't really any issues left unresolved, right?

Also, am I getting it correctly that pixel average off would be more suited for sprite-based graphics (like GB/C/A games on GBI), while pixel average on would be better for 3D/Wii/GC games?

It's for analog YPbPr and a future project based on GBIHF.

OK, so just to clarity, for analog RGB and other content it will be better to leave it on, while setting it off for analog YPbPr and your future project?

If you get YPbPr into an OSSC, you'll probably want to leave it on.

Thanks. I mainly feed RGBS into a BVM. I guess it won't hurt to see how off looks on different stuff anyway.

This is what I've been wondering. What's even left to implement with Firmware v2.5? Sounds like the FPGA is pretty stretched by this point anyway, no?

You can read the GBI manual for a taste of remaining issues condensed in one-ish place.