Super Mario War on RPi4

ledow

I got SMW working fullscreen on RPi4 / SDL2, would anyone be interested in my coding up the patches or is someone else already working on that?

Basically I used:

the existing HerbFargus git repo
a primitive SDL1->2 wrapper file from https://github.com/rsn8887/smw-switch
the existing smw retropie port scripts (with the -kms removed to make it appear/install on RPi4)
the SDL2 library equivalents (SDL2_mixer, image, etc.) and sdl2-config
a hardcoded resolution in the scaler code in the above file (but nothing stopping that being read at runtime from a file or command line if necessary) to stretch it to 1280x1024 (my screen size).
a handful of small source / Makefile changes to use SDL2 libraries / includes and the above wrappers, silencing a warning that turns into an error otherwise, and not bothering with the level editor, world editor, etc.

It works and I've played four-player games with joypads, sound, fullscreen video etc. but I'm trying to track down a segfault-at-exit but it doesn't affect gameplay at all and isn't visible when used from ES.

Is someone working on this, or is there someone who'd like a (neater) patch? What would be the preferred format? A git push to the HerbFargus git tree, a manual diff to it in the Retropie install script?

herb_fargus

@ledow better option would be to just install fluffypillows (mmatyas) version which is what the switch port is based on. Required some modifications of the install script, or you can fudge the install script of my repo to use xinit for the sdl1 build.

The mashed version on my repo is just a stripped pi mostly specific build with some extra assets, alternate splash etc.

I'm not against the idea of porting it to sdl2 or to use fluffypillows build in place of mine, just haven't had any free time myself for any new implementations

ledow

Meh, it took about an hour or so to do, and most of that was repeated compile times and installing the SDL2 libraries.

It didn't take any porting, really, just a single cpp/h file from the switch version with a handful of "SDL2-named function that calls the SDL1 function" macros / functions and then a couple of includes and changing the "scaled" resolution to something matching my screen.

If yours isn't going to be the version that gets into the next version, then I'll leave it, but at least I can play SMW for now! :-)

But if anyone wants a nice diff for it, I'll write it up and push it your way.

fluffypillow

Yup, the latest version is available here: https://github.com/mmatyas/supermariowar/. It has full support for SDL2 (including the editors), so in theory if SDL2 (+ image/mixer/ttf) works properly on the Pi 4, SMW should too. It's not particularly well tested though so feel free to report if you run into issues.

ledow

@fluffypillow You need to get that pushed into the fkms branch - just me testing isn't going to help you much and currently there's no smw port on that at all (because of the -kms on the port script which removes it from all the menus).

psyke83

I've started work on updating the scriptmodule to use your fork, @fluffypillow.

The commit is here (not yet submitted as a PR): https://github.com/RetroPie/RetroPie-Setup/compare/fkms_rpi4..psyke83:smw_rpi4

Without any changes to your source, the build is segfaulting on exit - but I know the cause. It's necessary to avoid the use of atexit for SDL_Quit() due to a conflict between SDL2 and the Mesa driver's usage of atexit; see: https://bugzilla.libsdl.org/show_bug.cgi?id=4530

Additionally, it's necessary to enable vsync for kmsdrm contexts due to a driver bug causing a drastic performance reduction when vsync is disabled.

I've only had time to check basic functionality (mostly to verify that bypassing the atexit calls prevents the segfault on exit). When I have some free time to test and verify everything's ok, I'll send the atexit patch as a PR to your repo, but if you think my change isn't good enough, let me know and I can take a look at the code again (or you could do it yourself, perhaps). I also had to bypass SDL_FreeSurface(screen) is it was causing a double free error on exit, but I'm not sure where the culprit lies (likely another call freeing the same pointer?).

I'm not sure if the vsync patch is suitable to send, however, as you seem to provide framerate options beyond 60fps in the menu, which indicates that vsync being off is intentional. We can keep that patch isolated to configurations using the kms driver only, perhaps. Thanks.

hhromic

@psyke83 @fluffypillow vsync can always be added as a toggle user-option as well :)

fluffypillow

@psyke83 nice, thanks, I'm okay with using with using my fork, if @herb_fargus doesn't mind. I admit I don't actively work on the game, but I do review pull requests and fix some issues occasionally.

The atexit fixes could be added too. In the code void gfx_close() is intentionally empty and the actual Close is called by ~GraphicsSDL -- perhaps this double closing caused the error for you? Also you might want to update the SDL1 version of Close too at the bottom of the file.

As for the vsync, I'd prefer to keep it optional (or perhaps even Pi 4 only in the script). Do you happen to have a bug report for that too? I wonder if there's already some work going on, perhaps we can just wait for a driver update. In the long term a menu option could be implemented for it in the game too.

psyke83

@fluffypillow said in Super Mario War on RPi4:

@psyke83 nice, thanks, I'm okay with using with using my fork, if @herb_fargus doesn't mind. I admit I don't actively work on the game, but I do review pull requests and fix some issues occasionally.

The atexit fixes could be added too. In the code void gfx_close() is intentionally empty and the actual Close is called by ~GraphicsSDL -- perhaps this double closing caused the error for you? Also you might want to update the SDL1 version of Close too at the bottom of the file.

As for the vsync, I'd prefer to keep it optional (or perhaps even Pi 4 only in the script). Do you happen to have a bug report for that too? I wonder if there's already some work going on, perhaps we can just wait for a driver update. In the long term a menu option could be implemented for it in the game too.

I asked @herb_fargus for permission beforehand, and he seemed OK with the idea, with the caveat that the Pi 1/0 may run too slowly with the SDL2 port. If this is the case, then I may modify the PR to build against Herb's branch for armv6 targets and your SDL2 branch for everything else, but I'm not sure yet.

Regarding the atexit issue, I've updated the patch according to your notes; see: https://github.com/RetroPie/RetroPie-Setup/compare/fkms_rpi4..psyke83:smw_rpi4#diff-e5ffc17da6c78407eb2c7c3746833990

Unfortunately, a segmentation fault on exit still occurs about 80% of the time. Here's a backtrace:

---------------- shutdown ----------------
[Thread 0x6e3ff3a0 (LWP 10205) exited]

Thread 1 "smw" received signal SIGSEGV, Segmentation fault.
0x76aeee78 in _int_free (av=0x76bc97d4 <main_arena>, p=0x22f2d8, have_lock=<optimized out>) at malloc.c:4334
4334    malloc.c: No such file or directory.
(gdb) bt full
#0  0x76aeee78 in _int_free (av=0x76bc97d4 <main_arena>, p=0x22f2d8, have_lock=<optimized out>) at malloc.c:4334
        size = 288
        fb = <optimized out>
        nextchunk = 0x22f3f8
        nextsize = 32
        nextinuse = 0
        prevsize = <optimized out>
        bck = 0x52d2f8
        fwd = 0x3008
        __PRETTY_FUNCTION__ = "_int_free"
#1  0x6f10fa9c in ?? () from /usr/lib/arm-linux-gnueabihf/libEGL.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) bt
#0  0x76aeee78 in _int_free (av=0x76bc97d4 <main_arena>, p=0x22f2d8, have_lock=<optimized out>) at malloc.c:4334
#1  0x6f10fa9c in ?? () from /usr/lib/arm-linux-gnueabihf/libEGL.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

If I add back this part, the segmentation fault stops happening (nor is there any double free error):

diff --git a/src/common/gfx.cpp b/src/common/gfx.cpp
index d1d38a3..0df951b 100644
--- a/src/common/gfx.cpp
+++ b/src/common/gfx.cpp
@@ -35,7 +35,10 @@ void gfx_settitle(const char* title) {
     gfx.setTitle(title);
 }
 
-void gfx_close() {}
+void gfx_close() {
+    gfx.Close();
+}
+
 bool gfx_loadpalette(const std::string& palette_path) {
     return gfx.getPalette().load(palette_path.c_str());
 }

The reason why the above is necessary seems to be the delete rm; call here, as commenting that out instead of modifying the gfx_close function also prevents the segmentation fault.

I'm not sure of the best way to fix this properly...

fluffypillow

@psyke83 I see, thanks for testing. Not sure yet why that happens on the Pi, the freeing shouldn't be platform specific and rm doesn't seem to have anything related to it... I suppose we could patch it out for now.

If this is the case, then I may modify the PR to build against Herb's branch for armv6 targets and your SDL2 branch for everything else, but I'm not sure yet.

You can build the fork to use SDL 1 too, just remove the USE_SDL2_LIBS config parameter. This way we don't have to provide different version to the Pi 1 users.

fluffypillow

@psyke83 Would you like to open a pull request for these changes? Or it's okay if I add them myself?

psyke83

@fluffypillow said in Super Mario War on RPi4:

@psyke83 Would you like to open a pull request for these changes? Or it's okay if I add them myself?

Maybe it's best to hold off a bit, as I was seeing crashing on x86 via KMS, so the patches may not be fully correct. I haven't had time to troubleshoot properly yet. Thanks.

navi87

Hey guys, Ive got myself a Pi 4 B and did the manual install for RetroPie but Ive noticed Super Mario War is missing from the RetroPie setup sh, would you be able to help me get it installed? @ledow
I have basic Linux knowledge, FYI.

roslof

@navi87

Close RetroPie Setup

Edit smw.sh in ~/RetroPie-Setup/scriptmodules/ports.

Find the line: rp_module_flags="!mali !kms"
Remove !kms

Restart RetroPie Setup.
Search for smw in Optional

Remember this is not supported at this time.

navi87

@roslof Thanks for the install guide, just waiting for it to finish installing now. Cheers!!