Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

Super Mario War on RPi4



  • 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.



  • @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).


  • Global Moderator

    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.



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



  • @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.


  • Global Moderator

    @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...



  • @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.



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


  • Global Moderator

    @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.



  • 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.



  • @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.



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


Log in to reply
 

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.