wraggster
March 27th, 2010, 23:45
Simon Kagstrom has posted some WIP News concerning his Amiga Emulator for the Wii:
Well, I've already got two correct answers: It's a classical byte order problem. It comes from UAE-Wii, and I've had this problem for quite a long time. I only found out what was causing it last week, thanks to some questions by Fredric Blåholtz, and I actually realised what the problem was when going to bed one night.
The reason I didn't understand the issue quicker (maybe apart from general slowness!) was that the graphics works well in games. I therefore assumed that this was caused by the Wii resolution (640x480) and problems with scaling it to 640x512. Fredric showed me that it works fine on the host when using 640x480, so this couldn't be the problem.
But byte order can. With 16-bit color depth, the relevant part of drawing looks like this:
while (dpix < stoppos) {
uae_u32 spix_val;
uae_u32 dpix_val;
uae_u32 out_val;
dpix_val = xcolors[ham_linebuf[spix]];
spix++;
out_val = dpix_val;
dpix_val = xcolors[ham_linebuf[spix]];
spix++;
out_val = (out_val << 16) | (dpix_val & 0xFFFF);
*((uae_u32 *)&buf[dpix]) = out_val;
dpix += 2;
}
and as you can see, it's done in chunks of 32-bit stores. Uh oh. Problem.
This particular source code is generated by a tool shipped with UAE. Autoconf is a true horror to work with though, so I resorted to just putting together the makefile for the Wii port by myself instead. And took a few shortcuts - like generating the files once and for all. So on the big-endian Wii, the two neighboring 16-bit pixels are swapped (see the last assignment to out_val). With half-resolution (320x256) the problem doesn't show, simply since the order of two same-colored pixels doesn't matter.
In hindsight, the problem is pretty obvious.
http://simonkagstrom.livejournal.com/48891.html
Well, I've already got two correct answers: It's a classical byte order problem. It comes from UAE-Wii, and I've had this problem for quite a long time. I only found out what was causing it last week, thanks to some questions by Fredric Blåholtz, and I actually realised what the problem was when going to bed one night.
The reason I didn't understand the issue quicker (maybe apart from general slowness!) was that the graphics works well in games. I therefore assumed that this was caused by the Wii resolution (640x480) and problems with scaling it to 640x512. Fredric showed me that it works fine on the host when using 640x480, so this couldn't be the problem.
But byte order can. With 16-bit color depth, the relevant part of drawing looks like this:
while (dpix < stoppos) {
uae_u32 spix_val;
uae_u32 dpix_val;
uae_u32 out_val;
dpix_val = xcolors[ham_linebuf[spix]];
spix++;
out_val = dpix_val;
dpix_val = xcolors[ham_linebuf[spix]];
spix++;
out_val = (out_val << 16) | (dpix_val & 0xFFFF);
*((uae_u32 *)&buf[dpix]) = out_val;
dpix += 2;
}
and as you can see, it's done in chunks of 32-bit stores. Uh oh. Problem.
This particular source code is generated by a tool shipped with UAE. Autoconf is a true horror to work with though, so I resorted to just putting together the makefile for the Wii port by myself instead. And took a few shortcuts - like generating the files once and for all. So on the big-endian Wii, the two neighboring 16-bit pixels are swapped (see the last assignment to out_val). With half-resolution (320x256) the problem doesn't show, simply since the order of two same-colored pixels doesn't matter.
In hindsight, the problem is pretty obvious.
http://simonkagstrom.livejournal.com/48891.html