[WiiU] Wrong color palette?

[cucholix]

Hi, thanks for including Wii U in your builds. Tried the emu for the first time today and all the games have a bluish color palette, also the sound is just a popping noise.

[Zlika]

Hi! Thanks for reporting this issue. I'm happy to see that the emulator compiles and "nearly" works on WiiU, I don't have the opportunity to test it by myself. It would be great if you could launch retroarch in verbose mode and send me the logs.

[cucholix]

I think Wii U doesn't support logs =( Could it be endianess issue? I tried compile it on my end by get stuck with a undefined reference in libretro.c and didn't look into it further.

Anyway the line I was experimenting in the makefile is ENDIANNESS_DEFINES += -DMSB_FIRST STATIC_LINKING = 1

[Zlika]

The core works on both x86 and ARM architectures which have different endianesses... But maybe WiiU has a strange endianess or memory alignment requirement. I used nestopia as an example for my core. It is supposed to work on wiiu but does not have any special hack for this platform, only a different memory allocation for the 3DS. I will try to have a deeper look at it.

[Zlika]

According to what I've read here and there, it seems that the WiiU version of Retroarch supports logging. It would be great if you could compile the core by yourself to make some tests. What is your compilation issue?

[cucholix]

Hey!

.\libretro_wiiu.a(libretro.o): In function `load_file':
libretro.c:(.text.load_file+0xe): undefined reference to `__stack_chk_guard'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
libretro.c:(.text.load_file+0x16): undefined reference to `__stack_chk_guard'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
libretro.c:(.text.load_file+0x254): undefined reference to `__stack_chk_fail'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
.\libretro_wiiu.a(sap.o): In function `sap2fd':
sap.c:(.text.sap2fd+0xe): undefined reference to `__stack_chk_guard'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
sap.c:(.text.sap2fd+0x1e): undefined reference to `__stack_chk_guard'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
sap.c:(.text.sap2fd+0x158): undefined reference to `__stack_chk_fail'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
.\libretro_wiiu.a(devices.o): In function `RunIoOpcode':
devices.c:(.text.RunIoOpcode+0x16): undefined reference to `__stack_chk_guard'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
devices.c:(.text.RunIoOpcode+0x1a): undefined reference to `__stack_chk_guard'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
devices.c:(.text.RunIoOpcode+0x690): undefined reference to `__stack_chk_fail'
c:/msys32/home/buildbot/tools/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eabi/bin/ld.exe: BFD (GNU Binutils) 2.27 assertion fail ../../../binutils-2.27/bfd/elf32-ppc.c:8812
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile.wiiu:312: objs/wiiu/retroarch_wiiu.rpx.elf] Error 1
make: *** Se espera a que terminen otras tareas....
.\libretro_wiiu.a(libretro.o): In function `load_file':
libretro.c:(.text.load_file+0xe): undefined reference to `__stack_chk_guard'
libretro.c:(.text.load_file+0x16): undefined reference to `__stack_chk_guard'
libretro.c:(.text.load_file+0x254): undefined reference to `__stack_chk_fail'
.\libretro_wiiu.a(sap.o): In function `sap2fd':
sap.c:(.text.sap2fd+0xe): undefined reference to `__stack_chk_guard'
sap.c:(.text.sap2fd+0x1e): undefined reference to `__stack_chk_guard'
sap.c:(.text.sap2fd+0x158): undefined reference to `__stack_chk_fail'
.\libretro_wiiu.a(devices.o): In function `RunIoOpcode':
devices.c:(.text.RunIoOpcode+0x16): undefined reference to `__stack_chk_guard'
devices.c:(.text.RunIoOpcode+0x1a): undefined reference to `__stack_chk_guard'
devices.c:(.text.RunIoOpcode+0x690): undefined reference to `__stack_chk_fail'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile.wiiu:308: objs/wiiu/retroarch_wiiu.elf] Error 1
make: se sale del directorio '/home/Sebastian/libretro-super/retroarch'

real    22m12,345s
user    0m6,531s
sys     0m38,745s
buildbot job: retroarch: [status: fail] [recipes/nintendo/wiiu]
buildbot message: retroarch: [status: fail] [recipes/nintendo/wiiu]

Using my fork with ENDIANNESS_DEFINES += -DMSB_FIRST Or using your fork

[Zlika]

Ok. I think the problem is that your compiler chain is not fully compatible with the "-fstack-protector" option. Just remove this option from the makefile (you can event delete the whole GCC_SECURITY_FLAGS variable), and try to compile again.

[cucholix]

Yep, that made the trick, tried my build with endianess flags and the issue persist. At least I can test on my end now =)

[Zlika]

Great! Just an idea: there is a "struct pix {char b, g, r, a;}" defined in video.c. Could you check that the size of this struct is 4 bytes on WiiU? (you can add "printf("sizeof struct pix=%d\n", sizeof(struct pix));" at the beginning of the SetLibRetroVideoBuffer() function for example, but you have to be able to read standard output. Or you can use a libretro's function to print it on the screen, see print_current_virtualkb_key() in libretro.c). If for some reasons there is a padding in this struct that would explain the video problem. In this case the solution would be to use a pragma to "pack" the struct

[cucholix]

Did the changes in my fork, but I'm not sure what do you mean with "but you have to be able to read standard output", I compiled a build on my end with the changes in video.c, send a .rpx to a tester but he couldn't see any log text on screen...

[Zlika]

I created a new branch "3-fix-wiiu" to work on this issue. Could you checkout and compile this branch? Then, when you run the core, you should see during the first 30s a message on the screen like this: "sizeof struc pix = 4". If you see a different value then I think I understand the problem and I know how to fix it.

[cucholix]

Ok, tested with the changes from your wiiu branch and it displays "sizeof struc pix = 4"

[Zlika]

Too bad. I had another idea. Now I print on the screen the color code of the upper left pixel. On the TO8 home screen it should be FFCBFBFB (CBFBFB is ~cyan, FF is the transparency). Could you test it?

[cucholix]

Yep, are the changes in 3-fix-wiiu branch?

[Zlika]

Got it! (I think). I thought that ARM processors were big endian and then that my code was compatible with both little (x86) and big endian processors, but I was wrong:

It’s little-endian on 99.9% of implementations, including all new ones and everything Android, IOS, and Nintendo. On early generation ARMs, it would depend on if a certain pin was connected or not. In practice, almost everybody went little-endian, and big-endian ARM is both old and rare as hen’s teeth.

Then my guess is that the WiiU is in fact big endian (it seems to be a PowerPC CPU, and this architecture is normally big endian). To be sure, run the current 3-fix-wiiu branch and tell me the color code of the upper left pixel as indicated in the printed message. If it confirms my guess, then I will refactor the pix struct to make it endianess agnostic.

[cucholix]

Are you sure 3-fix-wiiu will print the color code? I only see you remove the sizeof struc pix = code, but no other print in replace. Thanks!

[Zlika]

I made on this branch some rebase/merge black magic I don't even fully understand myself :-), but if you just do a fresh clone of my repo and switch to the 3-fix-wiiu branch you will see that the "sizeof struct pix =" code has disappeared and other changes were made (libretro.c, lines 415-420). I also removed the GCC security flags, but only for the PowerPC CPUs.

[cucholix]

Done, will test when I get home =)

[cucholix]

the upper left pixel reads fbfbcbff (fb fb cb ff) it's on the main TO8D screen

backwards to the value you give me ff cb fb fb

[Zlika]

Great! That's what I thought. I pushed a new commit on 3-fix-wiiu that should fix this problem. If it's ok for you I will merge it on the trunk. However I still have no clue on the sound problem. Could it be that the WiiU does not support a 22kHz sampling rate?

[Zlika]

For the sound problem, I've read other people having similar problems and fixing it by changing the "Audio Output Rate" setting in Retroarch (menu Driver/Audio). Do you have a similar issue with other cores?

[cucholix]

the color issue is fixed \o/ as for the sound I suspect it's the CPU struggling with the code, the sound is accurate but with a lot of stutter, the game itself performs pretty slow. I test with Bob Morane SF and after killing a soldier the game freeze. Is this core accuracy high enough to hang the Wii U CPU?

[Zlika]

I already played to Bob Morane SF on my Android phone and it was working great. I don't think the core is very CPU intensive, and anyway it should not hang. Could you try another game? Also, please use .fd files because support for the .sap file format is still preliminary.

[cucholix]

kk, will try .fd format when I get home

[cucholix]

Tried .fd directly, and it's a bit faster, but still the game stutter alot, made a video so you can have a more clear view on what's happening https://m.youtube.com/watch?feature=youtu.be&v=oqfBzsX7r10

[Zlika]

Thanks for the video. I don't know this game, but the game speed seems normal to me. I'll try to analyze the frequency of this annoying "popping" sound to better understand its root cause. Could you try also to change retroarch's audio output rate option? I've read other people with seemingly similar problems fixing it by using 44khz instead of 48khz. Also, configure retroarch to make it display the current frame rate on the screen (it should be constant and very near 50fps).

[cucholix]

Can you change sound sample rate in every core? I tried changing 48khz in settings > sound, but it seems it's fixed

[Zlika]

It's not linked to a core, it's a global retroarch setting. But maybe you need to manually change the value in the retroarch config file. Cf. http://www.lakka.tv/doc/Audio-settings/ :

The default rate, 48KHz, should be OK in most case. If you hear audio crackling or if games are slow like 55fps, you may need to use 44.1KHz instead.

[cucholix]

Was asking in RA discord and the value is fixed at 48khz there is a technical reason (I think maister said) why RA should always be left at 48khz

You can set 44khz in the core code.

[Zlika]

I analyzed the sound. The "crack" is very regular and repeats every 100ms. I don't know why. I made a small change in the 3-fix-wiiu branch to use a 48kHz sample rate. I saw that this is the sample rate used for example by libretro-nestopia. Could you test this version and, if the problem still occurs, tell me if you have a similar problem with the nestopia core?

[Zlika]

I was able to reproduce a similar repetitive "crack" sound when running retroarch through a profiler (valgrind/kcachegrind): in this situation, the overhead of the profiler is so big that the frame rate of the core is lower than 30fps instead of the expected 50fps. So it would be very helpful if you could configure retroarch to print the current frame rate on the screen and check if you are close to 50fps or not.

[cucholix]

Hi, tested the newest 3-fix-wiiu build with Mach 3 and it's 30fps and the samplerate on info screen is 48khz. Curious enough the game started at 20fps, then went up to 30fps and kept that frame rate constant.

Nestopia core sound is flawless on Wii U.

[Zlika]

Ok, so it's a performance problem. I really don't know the cause, because this core works flawlessly on my Android phone, on a raspberry pi 3, and it barely takes 10% of 1 CPU core on my 6 years old core i5 laptop... I will try to do some profiling and compare with other 8bit cores like nestopia.

[Zlika]

I made some profiling and performance measurements. On my laptop, nestopia has a CPU consumption very similar to theodore. The profiler shows that most of the time spent in the core (excluding retroarch's own functions) is spent in the Decode320x16 function. This function overuse the memcpy function to copy single elements. One possibility is that this function may not be well optimized on WiiU, thus leading to the performance problem you see. I reworked this method in the 3-fix-wiiu branch, and even on my laptop I can see a small but measurable performance boost. To test the impact of this change there is no need to start a game, only stay on the TO8 main screen and note the displayed frame rate (you may have to wait a few seconds before retroarch gives you a reliable value).

[cucholix]

Hi, just tested new 3-fix-wiiu and it still sitting at 30fps Enabled extra info that could be useful. Just an idea but could you set sample rate to 44khz or lower, something similar happened when helping @fr500 to test sameboy and a lower sample rate lead to a performance boost

[Zlika]

I added a commit 1 hour ago to revert the change on the audio sample rate and put it back to 22khz.

[cucholix]

Still the same, stable 30fps and the popping noise =c It displays 22khz on info screen

[Zlika]

Damn it! Do you know if you can use a profiling tool (like valgrind) on WiiU?

[Zlika]

Another small idea I have: maybe there is a restriction on available frame rates on the WiiU. So I bumped the frame rate to 60Hz on the 3-fix-wiiu branch (I think 60Hz is the frame rate used by most other cores). Maybe it is just a stupid idea but at this time I have no other better one. I wish my brother didn't sell its WiiU to be able to test it by myself.

[cucholix]

Still stuck at 30fps =c Core timing -FPS: 60 -Sample Rate: 22.000

Would you like joining to RA Discord? We could get more help regarding tools I'm not aware of.

[Zlika]

I will try to join RA IRC channel (I prefer old school tools :-)) tonight.

[Zlika]

Wasn't able to find someone with relevant knowledge on the IRC channel... :-( I'm still investigating possible performance improvements. However, on my computer, 70% of the CPU time is spent in the retro_video_refresh_t callback that is called once in retro_run to update the frame on the screen. This is a RetroArch function so I don't know what I can do to make it quicker. What are the cores that are working correctly on WiiU, and are they other cores that have similar performance problems?

[Zlika]

As the video refresh callback seems to be the bottleneck, maybe you should have a look at RA's video options. There are some options that can have a positive/negative impact on performances. For example, you should disable filters, try integer scaling, threaded video, etc...

[cucholix]

Good news! Manage to get 52fps by disabling vsync, no other change needed.

The popping noise still there though the frequency is higher.

[Zlika]

Could you make another video? Also, as you reached 52fps I suppose you're still using the 60fps version I made for tests. You can download the latest version of the core using RA core updater feature, it includes all the fixes I made for the WiiU and uses 50fps. Also, did you disable the rewind feature?

[cucholix]

https://www.youtube.com/watch?v=vD2Ued_1lyI

Yes, rewind is disabled

[Zlika]

Thanks. In this video, core timing is still at 60fps, so I think that's why you still hear the popping noise. Either use the latest version available from the core updater, or compile the head version of the master branch. The nominal fps for this computer is 50Hz. As the WiiU seems to be able to do a little bit more with vsync disabled, I think the popping noise should disappear at 50Hz. Also, you can configure other video options to add additional margin.

[cucholix]

yay! The noise is gone in latest nightly ^^

[Zlika]

Great! Thank you very much for helping me fixing these issues. I hope you will enjoy the emulator. One of my favorite game is Saphir.

[cucholix]

So you disabled vsync on Wii U build by default in the official release? Or it's still needed disable it in settings > video > vsync =off ?

[Zlika]

As far as I know, I cannot disable it programmatically. Moreover, I think it's a performance problem of RA, so maybe it will be fixed in a futur release.