Add Sega Model3: supermodel

[DirtBagXon]

Just pushing this to see if there is any interest. Feel free to close if it's considered too problematic, I am aware it can require lots of tweaking per install.

This is the ARM optimised code, as used from Exarkuniv's "RetroPie-Extra", based on mechafatnick's original arm mods.

This branch has received tweaking, from the Sinden Pi guys, to Supermodel.ini and Games.xml for some time and is maintained.

It also has the following additions to the arm optimizations:

'Absolute' Mouse Input for light guns in Linux
Multiple Mouse Support : Allowing 2 players in lightgun games
Support for selecting a clone from within merged ROM set
Per game .commands file for individual game configuration
Log based Framerate Monitoring
Built-in Sinden border

The repo branch is here for reference: https://github.com/DirtBagXon/model3emu-code-sinden/tree/arm

I have made this rp_module_id="supermodel3" to avoid existing unofficial installs which seem to be just supermodel

It's now using a .commands file, based on game, to alter arguments.
With the addition of -game to select a clone within a MAME style merged ROM set, this has become particularly useful.

/opt/retropie/emulators/supermodel3/supermodel3 /home/pi/RetroPie/roms/arcade/scud.zip -game=scuddxo

It will run on a Pi4 and P5, without too many issues, on many games, so perhaps there should be a restriction in the scriptmodule for those model - looking for feedback or disinterest. Either is fine.

[DirtBagXon]

A 2 player demo can be seen here on a Pi4: https://www.youtube.com/watch?v=qplfGymaDPI

And here is a video series of tests using the Pi5:

https://www.youtube.com/watch?v=ZODiTiOgxSg
https://www.youtube.com/watch?v=17IHchP2TG4
https://www.youtube.com/watch?v=3pZQiBrqQ10
https://www.youtube.com/watch?v=klzTTg5DSNU

[cmitu]

@DirtBagXon thanks for submitting this. The best way to gauge the interest would be the forums, but since this is already opened, we can continue here. I'll take a look at installing this to see how it works, but I have a few general questions first. As is, the scriptmodule will need modifications and I'm questioning whether it should be made available for other platforms and not only Pi4/Pi5 (PC/Rockchip 3399/Odroid/etc.)

• Why is a desktop needed (X11/Xorg) to run the emulator ?
• Does it needs an overclocked Pi4/Pi5 to run any game or the overclock is needed just for a few games ?
• I'm only aware of @Exarkuniv's scripts, what other 3rd party installs are there ?

[DirtBagXon]

Why is a desktop needed (X11/Xorg) to run the emulator ?

I'm aware X11 is legacy these days, but in many ways this emulator seems reliant on many specifics. The Sinden Pi guys have been the driving force for this project and spent hours attempting to get it working on the Pi5 bookworm release via Wayland. This solution was the best performing they were able to figure. cmitu - I bow to your knowledge of the RetroPie drivers if you are able to offer any other working solution.

The gldriver-test was required on Bookworm as it changed some X11 setup: https://github.com/raspberrypi-ui/gldriver-test/tree/master/usr/lib/systemd/scripts

This pkg could happily be removed after the first install and the emulator would continue to run after the changes were made.

Does it needs an overclocked Pi4/Pi5 to run any game or the overclock is needed just for a few games ?

@Widge5 has been testing this and documenting for some time, as seen in the linked videos, and a small overclock does give a bump in performance of course. But I believe some games will run happily on a Pi5 without. Perhaps the guys can comment further on their findings here.

This branch has been merged into other distros like Rockchip and PR's raised to aide that limited environment. i.e. ROCKNIX/distribution#45 - So I'm certain it will probably work, but don't have the hardware to confirm. I run this branch on my X86 linux, without issue, and it's far less demanding on GPU hardware than the current official Supermodel codebase. But we are running the -legacy3d engine by default here too.

I'm only aware of @Exarkuniv's scripts, what other 3rd party installs are there ?

@Exarkuniv's was the main one, for sure. But when we started this there were other attempts floating around that we attempted to avoid interfering with, hence the adoption of the supermodel3 name. There is an svn based one still I think I saw recently, with svn in the module name, but based from similar like this, but not arm optimised it seems.

https://github.com/mictjs/RetroPie-Extra-WIP/blob/master/scriptmodules/emulators/supermodel.sh

The compile is noisy as hell, but so is the official codebase for all OS on most recent commits, you can see these in the main branch of my repo in the GitHub actions section how noisy it is:

https://github.com/DirtBagXon/model3emu-code-sinden/actions/runs/8952871828

[DirtBagXon]

I left "Allow edits by maintainers" enabled - you are of course able to do as you see fit with the scriptmodule.

[Widge-5]

Perhaps I can help answer the question about the necessity of the overclock.
In my video of The Lost World (the last of DBX's linked videos) my Pi5 wasn't overclocked. Nor was it overclocked in my earlier video of Star Wars Trilogy (https://youtu.be/K3yawtKgTfc) and the performance seemed to be very acceptable.
I first overclocked the Pi5 to try to help with LA Machine Guns which is notoriously heavyweight, but that one still could not play at full speed. I then left the overclock in place for my subsequent Supermodel 3 tests to get the best results. But I have recently tried Sega Rally 2, SCUD Race and Magical Truck Adventure all without overclocking and they all seem to run quite well without.
So as long as the game itself isn't too demanding, then overclocking isn't always necessary

[cmitu]

@DirtBagXon, @Widge-5 thanks for the info. I'll test the emulator over the week-end and see what modifications we'll need. So far, my ideas are:

• name the ARM optimized emulator supermodel-legacy and make it ARM/SBC only (i.e. no x86), retricting it to only the more powerfull platforms (pi4/pi4, rk3588 - OrangePi5/Radxa 5 - and maybe some tegra variants).
• have a separate module named supermodel, which would pull the code from upstream, for x86 (PC). AFAIK, it needs OpenGL4 and won't run on a Pi5 (there are a few issues around it).

[DirtBagXon]

Sounds good.

"pull the code from upstream" - Are you referring to https://github.com/trzy/Supermodel or to my main branch ?

ABS multi-mouse for Linux and the other enhancements aren't in the "official" repo, my main repo branch is up-to-date with official repo, and contains the ManyMouse and other "unofficial" additions. It doesn't currently have the -game argument, but I plan on adding that.

Also it is worth pointing out that the -new3d is now very hardware intensive since fairly recent improvements on emulation (huge floating point calcs) and will be default in both "official" and my main branch for the PC scriptmodule you propose. You can of course switch it back down in the .ini or via cli argument*.

_{* Just in case you aren't familiar with the recent changes in the official repo.}

[mrcmunir]

Some notes install or remove xorg package by default it's a bad idea for sbc devices needed hold xorg for working GPU fine in mainline distros

Edit: And Xinit i'ts only needed for devices without Desktop

[cmitu]

OK, I've done a few tests and I'm late to report the results.

I have modified the module in the PR here here, but I don't want to overwrite it yet with my changes.

Changes/simplifications from the proposed PR:

• I removed the explicit X11 dependency. The emulator seems to run ok witthout it on a Pi with SDL2 using the KMS/DRM video driver. I'm not sure though why X11 was added as dependency, maybe it's used for better lightgun/mouse support ? I've asked previously, but if you can test the changes and see how the emulator runs without X11, that would be great.
• I have replaced all the (confusing for me) symlinks for configs and left everything that should be user writeable in $configdir/arcade/supermodel3. AFAICT this include saves/NVRAM and emulator config. games.xml is left writeable, but overwritten by upgrades.
• initially I intended to have the upstream code added for PC/X86, but if @DirtBagXon's repo is tracking upstream in the main branch, then we can use just one repository. For the cases where - on a PC- the legacy3d renderer is preferred, I've added a separate emulator type. The arm platform will get the legacy renderer anyway.
• for games supporting Lightguns and Sinden lightguns are used, I've added a supermodel3-borders emulator entry.

What doesn't work/needs change:

• resolution change doesn't seem to have an effect. We can add explicitely the display's resolution since runcommand sets this via env vars (lik here, but using -res=X1,X2 doesn't seem to have an effect.
  @DirtBagXon is this supposed to work via CLI ? If I set resolution via the .ini file, it does have an effect, so something is taking this into consideration.

• platform support is now limited to Pi4 or up. I'm not familiar with the Tegra family and how powerfull it is. @mrcmunir if you can test this and see how it runs, I'll add the necessary platforms to the list of supported ones.

[DirtBagXon]

X11 was added, as in testing we could only get the display in the top left corner without it. This was in both the older (4.8 Pi4) RetroPie and early testing with the PI5 using Bookworm Lite. There are outstanding issues in the official Supermodel repo covering Wayland and Linux display environments, this worked, gave usable centered game display, so we went along with it.

-res cli most certainly works on the desktop environment, I have just run with -res=1024,768 and -res=1920,1440 (on both the main and arm branch binaries) and behaviour is as expected. This, and the previous issue, could all be related to the KMS/DRM environment.

Provided the mouse co-ordinates, within KMS/DRM, are "absolute" within the game video window, these are detected by the third party manymouse libraries - then lightgun accuracy should be fine. But will need confirming.

The $HOMEDIR of this app, and where it expects to find sub-folders, in the official build is still an issue in Linux on the official repo, the devs seem to be mostly Windows orientated as seen in this, and the display issues, on the official forum.

The symlinking could most certainly be simplified in the scriptmodule when $HOMEDIR is settled.

[DirtBagXon]

In regard to the -res argument, the values are assigned to config "XResolution" and "YResolution" these are then just used in an SDL_SetWindowSize() call in Src/OSD/SDL/Main.cpp:

  totalXRes = xRes = s_runtime_config["XResolution"].ValueAs<unsigned>();
  totalYRes = yRes = s_runtime_config["YResolution"].ValueAs<unsigned>();
  sprintf(baseTitleStr, "Supermodel - %s", game.title.c_str());
  SDL_SetWindowTitle(s_window, baseTitleStr);
  SDL_SetWindowSize(s_window, totalXRes, totalYRes);

[mrcmunir]

@cmitu I've tried under Jetsonnano compile from source and running near ~45-60fps at -res=2560,1440 working fine no graphicals errors detected in Sega rally 2
The only thing you have to be careful with is what I mentioned before, the graphical binary is linked to the xorg ABI for prevent break gpu will be only for mesa3d maybe?.

[DirtBagXon]

@cmitu - Just to confirm which .ini parameters are you using for which you see the resolution change take effect?

I'll see if I can trace it back where I might be able to patch into the -res command...

I assume in the [global] section too, i.e. not a game specific .ini section ?

[cmitu]

X11 was added, as in testing we could only get the display in the top left corner without it.

OK, so this was the reason for adding x11. I'll have to re-test then on the current (Buster based) release, because the SDL version may have an issue with it. The version we're using in Buster is old and the KMSDRM video driver has gained the ability to change the resolution at runtime.
FWIW, with a more recent SDL (like the one used by RetroPie in Bullseye/Bookworm) I don't get this behavior, the viewport is always centered (vert/horiz).

@cmitu - Just to confirm which .ini parameters are you using for which you see the resolution change take effect?

I'm using the expected ones (XResolution and YResolution in the global context). I may have been mistakenly imagined what -res would be doing - I was expecting the emulator to change the resolution to the specified and the -fullscreen to scale the image. But I think scaling is not implemented and if the -res only applies to the SDL window and not the (visible) viewport, then it doesn't matter that much.

RetroPie can do the resolution change ('desktop resolution') with the runcommand menu, so using -fullscreen would probably scale the window to the resolution chosen. I'll re-test this part, but I think we don't need to use -res anymore.

[cmitu]

The only thing you have to be careful with is what I mentioned before, the graphical binary is linked to the xorg ABI for prevent break gpu will be only for mesa3d maybe?.

My modifications to the scriptmodule don't assume nor install any X11 related libs. If your distro's SDL is support x11, then it will be used if a desktop/x11 environment is used to launch the emulator.

[mrcmunir]

@cmitu I mean reference to supermodel3.sh has dependencies xserver-xorg and remove xserver-xorg-legacy
Also no needed gldriver-test for the run supermodel in non rpi.
This dependences will be rpi specific

[DirtBagXon]

@mrcmunir - Refer to cmitu's proposed scriptmodule changes here: cmitu@807ccd6

It has none of the packages you are concerned about.

[mrcmunir]

@mrcmunir - Refer to cmitu's proposed scriptmodule changes here: cmitu@807ccd6

It has none of the packages you are concerned about.

Ah ops I'm undestand now I recheck that and doesn't view due exclude tegra i'm added aarch64 for run script but seems doesn't download git correctly.returned git error 128 .

= = = = = = = = = = = = = = = = = = = = =
Getting sources for 'supermodel3' : Super Model 3 Emulator
= = = = = = = = = = = = = = = = = = = = =

git clone --recursive --depth 1 --branch master "" ""
fatal: repository '' not exist
HEAD is now in branch 'master' at commit '9a15d3bc59aa9909a28ec9b09a3114021556c5c3'
/media/aresuser/4169bcf3-2cfe-40ff-81c5-a5442c4893e5/home/aresuser/ARES-Setup
Error running 'git clone --recursive --depth 1 --branch master  ' - returned 128
Errors:
Error running 'git clone --recursive --depth 1 --branch master  ' - returned 128

Edit : Seems _get_branch_supermodel3 not working correctly

[cmitu]

Ah ops I'm undestand now I recheck that and doesn't view due exclude tegra i'm added aarch64 for run script but seems doesn't download git correctly.returned git error 128 .

Hm, I don't see why the errors show up. Are you using an older RetroPie version which doesn't know about rp_module_repo ?
For the platform - which of the 'tegra' platform you have ? You can either add your platform to rp_module_flags or remove all rp_module_flags so the module applies to any platform.

[mrcmunir]

Ah ops I'm undestand now I recheck that and doesn't view due exclude tegra i'm added aarch64 for run script but seems doesn't download git correctly.returned git error 128 .

Hm, I don't see why the errors show up. Are you using an older RetroPie version which doesn't know about rp_module_repo ? For the platform - which of the 'tegra' platform you have ? You can either add your platform to rp_module_flags or remove all rp_module_flags so the module applies to any platform.

Ok now it compiles correctly no problem detected :)
It was because I was trying f on a branch older due i'm have different testing branches on my USB and I copied the script wrong branch that was not this new stuff
Thanks your script working fine :D

[Widge-5]

@cmitu Thanks, the revised scriptmodule works well for me. I like the decision to move the shortcuts to subfolders of the arcade location.

I'm currently using a Pi5 running Bookworm Lite with RetroPie installed.

I don't pretend to understand the use cases for the "XINIT:" prefix on the command line, but I can say that from my observation, without it, the game runs in a smaller "window" than when "XINIT:" is used. But other than that I notice no difference to the game's performance. It is centered on the screen, but just smaller.

The absence of XINIT also causes a mouse cursor to become visible, so I recommend adding -nomousecursor to the command line arguments

I suggest that the addition of a duplicate entry in emulators.cfg including the "-borders" argument is superfluous and clutters the emulator list unneccessarily. Considering that there are only a small handful of shooting games available, the use of a .commands file should be sufficient to apply the argument as necessary to those games specifically. I say this as a Sinden Lightgun user primarily interested in Lightgun games myself. Of course, if you think it's absolutely necessary then I'm not going to argue.

[DirtBagXon]

Guys, I have pushed a change to a arm_dev branch of the repo, that uses SDL_GetDisplayBounds() to determine the logical display area more reliably. There is a note in the source:

  // Call only once per program session (this is because of issues with
  // DirectInput when the window is destroyed and a new one created). Use
  // ResizeGLScreen() to change resolutions instead.

I think this may be causing the issue in Linux.

It could possibly address both the -res and the smaller window issue (maybe).

Anyway you could test it by pulling the arm_dev branch - The change is here:

DirtBagXon/model3emu-code-sinden@391ec44

This does fix a weird issue I have seen running -fullscreen on the desktop, so may be a viable fix in any case.

[cmitu]

This does fix a weird issue I have seen running -fullscreen on the desktop, so may be a viable fix in any case.

Thanks, I'll give it a try.

@Widge-5 Thank you for the test and recommendations, I'll include some of them in the module.

I don't pretend to understand the use cases for the "XINIT:" prefix on the command line, but I can say that from my observation, without it, the game runs in a smaller "window" than when "XINIT:" is used. But other than that I notice no difference to the game's performance. It is centered on the screen, but just smaller.

Maybe the modifications added by @DirtBagXon will change this. The difference is in the SDL videodriver used, XINIT forces the x11 videodriver while the default (in the script I added) is to use the platform's default (for Pi4/Pi4 this means the kmsdrm videodriver).

I have updated the module now and updated the build steps so that platform optimization flags are added to the compiler parameter.

[mrcmunir]

Guys, I have pushed a change to a arm_dev branch of the repo, that uses SDL_GetDisplayBounds() to determine the logical display area more reliably. There is a note in the source:

  // Call only once per program session (this is because of issues with
  // DirectInput when the window is destroyed and a new one created). Use
  // ResizeGLScreen() to change resolutions instead.

I think this may be causing the issue in Linux.

It could possibly address both the -res and the smaller window issue (maybe).

Anyway you could test it by pulling the arm_dev branch - The change is here:

DirtBagXon/model3emu-code-sinden@391ec44

This does fix a weird issue I have seen running -fullscreen on the desktop, so may be a viable fix in any case.

Tested With this changes The window looks smaller than before in fullscreen by default .
Now there are more black bands on the ultrawide screen.

[Widge-5]

I've compiled usng the latest scriptmodule, and using DirBagXon's arm-dev repo.
This seems to have fixed the -fullscreen argument, insofar as it removes the mouse cursor now, whereas previously it didn't. So my earlier suggestion of adding the -nomousecursor argument no longer applies.
However, I still see that, without XINIT, the game window is smaller than i would expect with.

Here is a picture of my TV screen running Magical Truck Adventure without XINIT:

And here it is with XINIT.

Both examples are with supermodel set at it's default resolution. The XINIT example is using the 720x400 video mode from runcommand, which offers the largest picture. Making the same video mode selection without XINIT seems to make no difference to me.

I realise now that the window size seen in the "without" picture appears to be similar (if not the same) as if I had chosen a 640x480 video mode with XINIT. Could this suggest that the KMS/DRM driver is automatically choosing a 640x480 mode?

Additionally @cmitu, i realise nobody has answered your question "I'm not sure though why X11 was added as dependency, maybe it's used for better lightgun/mouse support ?" So I have now just tested a shooting game (The Lost World) and I found that the alignment between game and gun is way off without XINIT, but perfectly fine with. So it seems apparent that XINIT is necessary for lightgun use at least.
With that revelation, perhaps a separate entry in emulators.cfg for supermodel-borders is necessary after all, including the XINIT prefix.

[mrcmunir]

The diferences for me on tegra devices are
Before arm branch

After arm_dev

It seems that arm_dev respects the original window resolution and omits any rescaling.

[DirtBagXon]

I'll take a stab and say that the lightgun alignment is due to what the game believes the screen resolution to be and what it's actually displaying in KMS/DRM.

Also the arm_dev fix clearly has no real effect and isn't going to work across systems - I'll remove that.

[cmitu]

@Widge-5, @mrcmunir thank you both for testing and reporting back.

Both examples are with supermodel set at it's default resolution. The XINIT example is using the 720x400 video mode from runcommand, which offers the largest picture. Making the same video mode selection without XINIT seems to make no difference to me.

I think -fullscreen works better with x11 (via XINIT) than with kmsdrm to scale the image to the actual desired size.

I realise now that the window size seen in the "without" picture appears to be similar (if not the same) as if I had chosen a 640x480 video mode with XINIT. Could this suggest that the KMS/DRM driver is automatically choosing a 640x480 mode?

Yes, that's correct, without specifying a resolution, it defaults to 640x480. You can verify the current resolution with kmsprint (from a separate terminal/SSH session). I'm not sure whether it's a KMSDRM video driver default or general SDL default when creating a (SDL)window.

I have re-tested with specifying the resolution explicitely when launching the emulator and it seems to work better w.r.t. window scaling, without using XINIT but using -res to scale. Latest commit is here and it applies a resolution to the emulator based on the current resolution (either default or chosen by the user via the runcommand menu).

I'm interested, @Widge-5, if you could test again with lightguns and see if this time they work correctly. Otherwise, I guess we'll have to use x11 to launch the emulator (either in generally or just when -borders is used for Sinden Lightguns). Thank you again for testing.