Test-Candidate of ScummVM 2.0.0 for WII
Moderator: ScummVM Team
For future reference.
Just tried building this and it died with the following error and other similar ones... :
../../fluidsynth-1.0.9/src/fluidsynth_priv.h:212:1: error: unknown type name 'int8_t'
I passed the normal cross compile parameters to configure i.e. --host=ppc --disable-shared --prefix=<normal thirdparty library root for Wii toolchain> --disable-alsa-support --disable-pulse-support
The last two were necessary as neither ALSA nor PulseAudio is present on the Wii and was being autodetected from the Linux host system of the buildbot.
Will attempt to debug this, patch and install to the Wii toolchain... but this may take some time.
Just tried building this and it died with the following error and other similar ones... :
../../fluidsynth-1.0.9/src/fluidsynth_priv.h:212:1: error: unknown type name 'int8_t'
I passed the normal cross compile parameters to configure i.e. --host=ppc --disable-shared --prefix=<normal thirdparty library root for Wii toolchain> --disable-alsa-support --disable-pulse-support
The last two were necessary as neither ALSA nor PulseAudio is present on the Wii and was being autodetected from the Linux host system of the buildbot.
Will attempt to debug this, patch and install to the Wii toolchain... but this may take some time.
Wow, thanks a lot. I was just asking about it, it's totally up to you if you want to go throuh all of that.digitall wrote:For future reference.
Just tried building this and it died with the following error and other similar ones... :
../../fluidsynth-1.0.9/src/fluidsynth_priv.h:212:1: error: unknown type name 'int8_t'
I passed the normal cross compile parameters to configure i.e. --host=ppc --disable-shared --prefix=<normal thirdparty library root for Wii toolchain> --disable-alsa-support --disable-pulse-support
The last two were necessary as neither ALSA nor PulseAudio is present on the Wii and was being autodetected from the Linux host system of the buildbot.
Will attempt to debug this, patch and install to the Wii toolchain... but this may take some time.
Without any debug detail, it is practically impossible to work out why that is happening. It could even be a hardware issue ie. cracked solder joint in your USB connector that opens thermally when you have been playing for some time.
When it happens again, could you use the virtual keyboard with CTRL-d to open the debug console. If this works, only the ScummVM SCUMM engine has frozen / deadlocked, rather than the entire application. If not, try holding the home button which should exit the HBC application back to the system menu. If not, then the console is locked up.
The only way to debug this then would be to run with a GDB connected on a debug build and capture the backtrace / location of the "crash".
When it happens again, could you use the virtual keyboard with CTRL-d to open the debug console. If this works, only the ScummVM SCUMM engine has frozen / deadlocked, rather than the entire application. If not, try holding the home button which should exit the HBC application back to the system menu. If not, then the console is locked up.
The only way to debug this then would be to run with a GDB connected on a debug build and capture the backtrace / location of the "crash".
Trust me, it locks the system up entirely. No input or anything. It can't be my USB as it works fine with 1.2.0 and all the other homebrew apps I use. I have played GameCube games for hours and hours using dios mios without any issues, same goes for Wii games from USB.digitall wrote:Without any debug detail, it is practically impossible to work out why that is happening. It could even be a hardware issue ie. cracked solder joint in your USB connector that opens thermally when you have been playing for some time.
When it happens again, could you use the virtual keyboard with CTRL-d to open the debug console. If this works, only the ScummVM SCUMM engine has frozen / deadlocked, rather than the entire application. If not, try holding the home button which should exit the HBC application back to the system menu. If not, then the console is locked up.
The only way to debug this then would be to run with a GDB connected on a debug build and capture the backtrace / location of the "crash".
If this is something that requires the USB Gecko for debugging, I can't do it. I don't have one.digitall wrote:*shrug* As I said, you need to setup to run a debug build with a GDB attached then. Otherwise, we have nothing to go on.
I'm a game hacker, not a programmer if this requires other special methods.
I'm not really sure what you mean by "Game Hacker"... but the other method would be compiling the Wii build for GDB remote debugging over TCP/IP using USB Ethernet or Wifi network connection to Wii:
http://wiibrew.org/wiki/User:Qiang0/Deb ... he_network
Without someone doing this, we have no way of knowing what the cause of the crash is and thus it will not be fixed.
http://wiibrew.org/wiki/User:Qiang0/Deb ... he_network
Without someone doing this, we have no way of knowing what the cause of the crash is and thus it will not be fixed.
Sorry but I have no way of doing this, I don't have a Gecko or the Wii LAN adapter. I do have a USB network adapter but I don't think anybody made an app to be able to use third party (netgear) adapters.digitall wrote:I'm not really sure what you mean by "Game Hacker"... but the other method would be compiling the Wii build for GDB remote debugging over TCP/IP using USB Ethernet or Wifi network connection to Wii:
http://wiibrew.org/wiki/User:Qiang0/Deb ... he_network
Without someone doing this, we have no way of knowing what the cause of the crash is and thus it will not be fixed.
What I meant by game hacker:
http://gamehacking.org/hackers/47iscool
Yes. You should even be able to do it via the Wii inbuilt WiFi, thus no extra hardware is needed. Though I think I would recommend a wired network card as more reliable at point of crash to giving some output.
I have googled around and I can't give you a tutorial for doing this as it is highly experimental to do this on the Wii. See the notes here and the link I indicated earlier:
http://wiibrew.org/wiki/Debugging
http://wiibrew.org/wiki/User:Qiang0/Deb ... he_network
A quick google will give you various tutorials on the general use of GDB ie. https://www.cs.cmu.edu/~gilpin/tutorial/
You will need to compile a build yourself to work with this. See: http://wiki.scummvm.org/index.php/Compiling_ScummVM/Wii
You will need to modify the config.h generated by the configure to uncomment the line: #define DEBUG_WII_GDB
Then make modifications as indicated by Qiang0's instructions to link the network GDB stub in and use it...
You then also have the wiigdb make target for initialising the GDB instance on the host machine, which will need to be started for the slave binary on the Wii to actually initialise i.e. otherwise you will have a blank screen until this connects and you send the "run" command.
I admit this is a complex task, but there is no other easy way to work out the cause of this.
I have googled around and I can't give you a tutorial for doing this as it is highly experimental to do this on the Wii. See the notes here and the link I indicated earlier:
http://wiibrew.org/wiki/Debugging
http://wiibrew.org/wiki/User:Qiang0/Deb ... he_network
A quick google will give you various tutorials on the general use of GDB ie. https://www.cs.cmu.edu/~gilpin/tutorial/
You will need to compile a build yourself to work with this. See: http://wiki.scummvm.org/index.php/Compiling_ScummVM/Wii
You will need to modify the config.h generated by the configure to uncomment the line: #define DEBUG_WII_GDB
Then make modifications as indicated by Qiang0's instructions to link the network GDB stub in and use it...
You then also have the wiigdb make target for initialising the GDB instance on the host machine, which will need to be started for the slave binary on the Wii to actually initialise i.e. otherwise you will have a blank screen until this connects and you send the "run" command.
I admit this is a complex task, but there is no other easy way to work out the cause of this.