search

xtreme8000 / CavEX

Project to recreate your favourite block game for the Wii (Beta 1.7.3)
GNU General Public License v3.0
225 stars 20 forks source link

Running the game #15

Closed mardy closed 9 months ago

mardy commented 10 months ago

Hi! Sorry for the silly question, but I'm not able to run the game: I built both the Wii and the Linux version, and I get the following issues:

Linux version

The game starts, it recognized my two save folders, but does not react to input. Mouse and keyboard presses have no effect. The game does not seem to be using the CPU, but it cannot be closed by closing the window -- only by pressing Ctrl+C on the terminal.

Wii version

I created a directory containing the DOL file (renamed to boot.dol), plus the assets, the save files, and the config, icon and meta files from the source tree. Then I try to open the DOL file with dolphin, but it immediately asks me if I want to stop the current emulation.

mardy commented 10 months ago

The game starts, it recognized my two save folders, but does not react to input.

OK, this was due to me missing the config.json file. Moving the config_pc.json file into the build directory (and renaming it to config.json) did the trick. :-)

For the Wii version I'm still trying to understand what happens.

mardy commented 9 months ago

I created a directory containing the DOL file (renamed to boot.dol), plus the assets, the save files, and the config, icon and meta files from the source tree. Then I try to open the DOL file with dolphin, but it immediately asks me if I want to stop the current emulation.

The same happens on a real Wii as well: after a couple of seconds (during which only a black screen is seen) the game quits and I get back to the homebrew channel app.

I will try building the v0.2.1 tag to see if it might be due to a later change.

SmollestBug commented 9 months ago

I had this same issue explained in Issue #10 comment and you just need a couple older install files for it to compile properly. There are a bunch of older installs here, https://gbatemp.net/threads/collection-of-old-devkitpro-versions.526377/ and from what I've tried you can just use the newest versions dated August 19th, 2022 of DevkitPPC and libogc.

The compiled build can crash decently often, and it probably is because of the cursed install used to build it. Unless Bytebit says otherwise.

xtreme8000 commented 9 months ago

@SmollestBug what kind of crash? 😟 It should be very stable on Wii.

SmollestBug commented 9 months ago

@xtreme8000 Basically just between 5-20 minutes of flying around a world it'll just inexplicably freeze, it's also frozen and then unfrozen a couple seconds later before, but then enters a state where it stops loading chunks from the world file.

mardy commented 9 months ago

I had this same issue explained in Issue #10 comment and you just need a couple older install files for it to compile properly. There are a bunch of older installs here, https://gbatemp.net/threads/collection-of-old-devkitpro-versions.526377/ and from what I've tried you can just use the newest versions dated August 19th, 2022 of DevkitPPC and libogc.

Mmm... my devkitPPC version is r41, which is exactly the version you suggest:

$ /opt/devkitpro/devkitPPC/bin/powerpc-eabi-gcc --version
powerpc-eabi-gcc (devkitPPC release 41) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My libogc seems to be actually older, it's dated July 2nd, 2021 and looking at the strings inside the binary I found this

GCC: (devkitPPC release 39) 11.1.0

I'll try upgrading libogc, then, to the version from August 2022, and report back. :-)

mardy commented 9 months ago

Nope, no luck, it makes no difference.

I've also tried to checkout an older commit:

Just to make sure that it's not an issue with the emulator, I took the boot.dol from the v0.2.1 release and moved it over my compiled one, and indeed that works. @SmollestBug, what commit are you building from?

It might also be that it's due to changes in the versions of the dependent libraries. I'm using:

SmollestBug commented 9 months ago

@mardy Maybe try a fresh install of latest devkitpro, and then downgrade devkitPPC and libogc. This is how I did it.

mardy commented 9 months ago

Still no luck. I also tried the following things, but none helped:

The latter seems to prove that this is not the same issue mentioned in issue #10.

I then tried to run a git bisect, to find out what is the last commit where the game does not exit immediately, and that's commit ddf6827254020e81057fa7a5d6b5ae414be01699; meaning, that the first commit where things broke (well, I get a black screen on the "working" one as well :-)) is commit 511e695e49f0fd87cca1983cdfabdcbc22ffd918.

I then took the latest master branch, added a call to PAD_Init() in input_init(), and now the game does not exit immediately, but stays running (still, only a black screen is shown). But I have no idea if this is part of the problem, or if it's irrelevant. @xtreme8000, do you have any idea of what could be wrong? Or maybe a suggestion to debug this (i'm new to Wii development, so I don't know if there's an equivalent of printf() that I could use...)?

xtreme8000 commented 9 months ago

Obviously there is no printf() on Wii (edit: not entirely true), so in severe cases I just used exit(0) and tried it at different places (as suggested first here). In Dolphin you can easily see that it reached exit, because it will show a prompt.

Make sure to not call PAD_Init() anywhere, because it makes exit hang indefinitely for some unknown reason.

mardy commented 9 months ago

Obviously there is no printf() on Wii, so in severe cases I just used exit(0) and tried it at different places (as suggested first here).

Thanks for the advice! Since for me the game exits immediately, whereas with PAD_Input() it hangs, I debugged it using the latter, and checked when it was not exiting. :-)

It looks like a deployment issue: the game quits because the textures cannot be loaded (tex_read() returns NULL when trying to load the terrain.png atlas). The weird thing is that when I run dolphin under strace I don't see any attempt to open the assets directory, and even more strange is the fact that the binary boot.dol that you published for v0.2.1 works fine, yet I don't see that it's opening the assets directory either (at least according to strace). What's the trick here? Maybe it had the textures built into the binary back then?

xtreme8000 commented 9 months ago

Yes, the old v0.2.1 release had all assets inside the binary.

You probably don't see Dolphin opening a directory, because you need to use an emulated SDcard, from which it reads any files. In Dolphin's Wii settings, you can set the location of a raw image, for me the default was ~/.local/share/dolphin-emu/Load/WiiSD.raw. That can be mounted e.g. sudo mount -t vfat -o user,uid=1000,gid=1000 ~/.local/share/dolphin-emu/Load/WiiSD.raw ~/sdcard/ (format first).

mardy commented 9 months ago

Oh, silly me! Indeed, creating an emulated SD card did the trick :-)

Just for others who might bump into this thread: for me the easiest solution was to enable the automatic sync of the SD folder in dolphin, and then I just had to recreate the required folder structure in dolphin's Load/WiiSDSync/apps/ directory. No need to mount the SD image file manually, then.

Once this is done, the game's dol file can actually be run from anywhere, even from cavex's build directory.

Thanks @xtreme8000 and @SmollestBug for your help!

Before I close this issue, can you please recommend me a world to download? I download a couple of them, but they don't appear in the Wii, and in the OpenGL version they load but are very far away from the camera, so I suspect that they are not fully compatible with cavex.

mardy commented 9 months ago

Oops, I wrote too soon: as a matter of fact, dolphin was still loading the dol file from the official release, so it turns out I didn't fix anything :-(

SmollestBug commented 9 months ago

I don't know if this could help narrow it down, I don't have much experience with this. But what is the file size of the .dol file you're getting? I noticed that depending on what version devkitpro was on that it would compile different size .dol files.

Up to date version gives a 875kb .dol Purposely downgraded version I suggested gives a 905kb .dol

I'd guess it changes quite a bit depending on how old the version you're using is. But I could assume if something is going wrong then it could be outputting some flimsy broken file.

mardy commented 9 months ago

I don't know if this could help narrow it down, I don't have much experience with this. But what is the file size of the .dol file you're getting? I noticed that depending on what version devkitpro was on that it would compile different size .dol files.

It's 932288 bytes. But now I'm convinced that the issue I'm seeing is just that dolphin cannot find the assets: I've just tried on a real Wii, and the game works just fine: I first tried with usleep() commented out, and then with the usleep() call, and it works in both cases. The reason why it didn't work the first time I tried on the wii, is that I didn't copy the assets, since I installed it over an existing installation of cavex and I thought that the assets would be the same (wrong! :-) ).

So, this is not a compiler issue, it's just that I'm unable to get dolphin emulate the SD card properly (and developing using Dolphin would be much easier for me). I'll give it a few more attempts. :-)

xtreme8000 commented 9 months ago

and developing using Dolphin would be much easier for me

This is the reason the PC port exists: so that I no longer have to rely on Dolphin or a real Wii to develop and debug :)

btw my .dol is 925760 bytes and even has additional features