Closed DirtBagXon closed 3 months ago
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
@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 ?
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. https://github.com/ROCKNIX/distribution/pull/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
I left "Allow edits by maintainers" enabled - you are of course able to do as you see fit with the scriptmodule.
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
@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:
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).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).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.
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
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.
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.
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);
@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?.
@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 ?
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.
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.
@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
@mrcmunir - Refer to cmitu's proposed scriptmodule changes here: https://github.com/cmitu/RetroPie-Setup/commit/807ccd6a92605034ce3c191faf11e801133067a4
It has none of the packages you are concerned about.
@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
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.
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 torp_module_flags
or remove allrp_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
@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.
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:
https://github.com/DirtBagXon/model3emu-code-sinden/commit/391ec44d97021d9358bd9db5cd12c41c5b674b7c
This does fix a weird issue I have seen running -fullscreen
on the desktop, so may be a viable fix in any case.
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.
Guys, I have pushed a change to a
arm_dev
branch of the repo, that usesSDL_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 thesmaller
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.
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.
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.
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.
@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.
I've used the new scriptmodule and it did add the -res=%XRES%,%YRES%
argument to the command line. This did successfully increase the size of the game's image to fill the entire 640x480 space. Very clever usage. But unfortunately the lightgun aim is still way off without using XINIT.
This is what I think is happening witht he picture sizing. The environment is a 640x480 space and it's rendering the emulator at 1:1 pixel resolution within that space. Sega Model 3's native resolution was 496x384, so that is also the default res of Supermodel 3; consequently it appears to be in a smaller "window" within the space of that video-mode. the -fullscreen
arg does nothing to change that. When using the 720x400 video mode, the vertical space difference is only 16pixels so much less obvious.
Specifying a higher resolution, such as 640x480 using the -res=640,480
argument does enlarge the game to fill the space but I have a couple of issues with that. Firstly, 640x480 is a 4:3 aspect ratio and Model 3 games are actually 31:24. In order to fill the vertical space and maintain the correct aspect ratio, the declared res should be 620x480. But even so, my second issue is that increasing the resolution of the emulator also increases the amount of work it needs to do to render those additional pixels and has potential for a significant impact to its performance on a low-spec device such as a Raspberry Pi. Ideally, this emulator should be kept at its native resolution and aspect ratio by default, applying such an impactful setting should be a matter of choice, not the default condition.
With regard to the variation between where the lightgun is pointing and where shots land on screen: This is behaviour we had observed in Supermodel some time ago, but the issue happily went away after DirtBagXon implemented manymouse enabling multiplayer lightgun gaming in Supermodel on the Pi. I don't know the intricate details but it also allowed for perfect absolute raw mouse positioning which wasn't previously available.
So I have played around with the supermodel code in order to see if I can achieve differing results, but the bottom line is the SDL2 behaviour of this function in KMS/DRM.
SDL_SetWindowFullscreen(s_window, SDL_WINDOW_FULLSCREEN)
Docs state https://wiki.libsdl.org/SDL2/SDL_SetWindowFullscreen:
The KMS behaviour is different to the X11 behaviour on this call and doesn't appear to force the videomode change correctly.
This could be the SDL2 libs still have unresolved issues, from @cmitu quote here: "the KMSDRM video driver has gained the ability to change the resolution at runtime."
I'm not certain this can be remedied on the emulator side without swaying away from the official core functions and resulting in a rewrite to work with KMS/DRM. All hail 'portable' SDL :)
[...] The KMS behaviour is different to the X11 behaviour on this call and doesn't appear to force the videomode change correctly.
This could be the SDL2 libs still have unresolved issues, from @cmitu quote here: "the KMSDRM video driver has gained the ability to change the resolution at runtime."
Yes, it's probably related to the SDL2 version. Note that with the latest SDL2 (but should work with 2.26.3 which is used by RetroPie-Setup on Bookwom) the resolution change does occur.
I'm not certain this can be remedied on the emulator side without swaying away from the official core functions and resulting in a rewrite to work with KMS/DRM. All hail 'portable' SDL :)
No, I don't expect that to be solved by the emulator. Based on the tests so far (thank you again @Widge-5 and @mrcmunir) I think we'll keep the x11
requirement for running the emulator (as it is for instance, for dolphin
). My latest version here will do that; I'll run a few more tests and probably edit the current PR with the changes before merging it.
@cmitu doesn't run due res=%XRES%,%YRES% doesn't seems return resoluton working correctly value and back to emulationstation
@cmitu doesn't run due res=%XRES%,%YRES% doesn't seems return resoluton working correctly value and back to emulationstation
%XRES%
and %YRES%
should be populated by runcommand
and should be also passed on by runcommand
to the emulator(s). EmulationStation doesn't know about the resolution. Are you running in a Wayland desktop env ? If not, do you have xrandr
installed ?
@cmitu doesn't run due res=%XRES%,%YRES% doesn't seems return resoluton working correctly value and back to emulationstation
%XRES%
and%YRES%
should be populated byruncommand
and should be also passed on byruncommand
to the emulator(s). EmulationStation doesn't know about the resolution. Are you running in a Wayland desktop env ? If not, do you havexrandr
installed ?
Yes by X11-xserver-utils package and xrandr working.
aresuser@aresuser-desktop:~$ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
3840x2160 60.02 + 59.98 50.01 30.00 29.97 25.00 24.00 23.98
4096x2160 24.00 23.98
2560x1440 59.96
1920x1080 120.08* 60.00 59.95 50.00 30.00 29.97 25.00 24.00 23.98
1280x1024 120.05 75.03
1280x720 60.00 59.94 50.00
1024x768 120.05 99.97 75.03 70.07 60.01
800x600 120.09 100.00 75.00 60.32
720x576 50.00
720x480 59.94
720x400 70.04
640x480 120.00 100.00 75.00 59.94
DP-0 disconnected (normal left inverted right x axis y axis)
I'm running Ubuntu 22.04 base with X11 session
I'm running Ubuntu 22.04 base with X11 session
Ok, I'll test on a desktop session and see what's going on. What's the output of /dev/shm/runcommand.log
?
I'm running Ubuntu 22.04 base with X11 session
Ok, I'll test on a desktop session and see what's going on. What's the output of
/dev/shm/runcommand.log
?
I was able to solve it now :) For some reason xrandr does not work as expected. I installed x11-xserver-utils Will be needed add x11-xserver-utils as a dependency? in X11 for X,Y working? Edit : I can confirmed it's needed X11-xserver-utils tools for working correct the resolution no problem detected for me.
All good.
As this is an OpenGL implementation, there were no other simple tricks we could have tried, there is no SDL_Renderer
so are limited in choice.
My only comment on the current scriptmodule, supports Widge's comments earlier, that there is no need for the separate $md_id-borders
entry, as this can easily be added to the .commands
file for the handful of games requiring it.
The Sinden Discord guys are all over these settings and are the only group that would require the border currently in any case.
I installed x11-xserver-utils Will be needed add x11-xserver-utils as a dependency? in X11 for X,Y working?
I think x11-xserver-utils
should be pulled by the xorg
package directly. I don't remember having to install it manually for xrandr
to be also installed on a desktop system. Maybe we should add it as dependency for runcommand
on x11
platforms.
Ah, so I see you're still forcing the emulator to run at a higher resolution by default.
(@DirtBagXon) My only comment on the current scriptmodule, supports Widge's comments earlier, that there is no need for the separate
$md_id-borders
entry, as this can easily be added to the.commands
file for the handful of games requiring it.
I see. As far as I'm concerned it's easier to use the menu (with the gamepad) to change a config than, but I guess if users are knowledgeable enough we can leave it out and just document it.
(@Widge-5) Ah, so I see you're still forcing the emulator to run at a higher resolution by default.
Yes, I intend to test it with and without -res
and see if there's a difference.
(@cmitu) I see. As far as I'm concerned it's easier to use the menu (with the gamepad) to change a config than, but I guess if users are knowledgeable enough we can leave it out and just document it.
I think it just simplifies and also removes potential questions on "what is this option?" from non-Sinden users. Also if you wanted to apply the border on a PC using -legacy3d
you would have to add it to the commands file anyway. So better to just document and make consistent throughout I feel, but your call.
The resolution issue has come up on the official repo issues again, my feeling is that there maybe should be an option to be able to not pass a -res
argument and allow individual game resolutions to be set in the .ini
This should be an option for SBC's, while the PC could force the higher resolution via -res
if desired.
Those non-standard resolutions are what kill the performance on the Pi, most PC should be fine to handle some upscaling.
But also the native resolution for these games is 496x384
so that should be an option, for the purists.
Ok, I've modified the PR with my changes. I took into account your comments and - also based on the testing done - I've modified to original code:
setBackend
functions to add X11 support, it's clearer this way. The -borders
is gone, but we'll document the usage of the params
file.-res
has a perf penalty, the default emulator entry is without any scaling. I've added a -scaled
variant that's scaling the window to fullscreen in order to scale up to the display's dimensions.I've kept my changes for the configuration. All game configs/nvram are in $configdir/supermodel3
, so no symlinks are necessary. Since the folder is available via file shares, can be easily backed-up and transferrred to a new system when needed.
You can give it a testing shot again (or let me know if I've mis-spelled/mistaken anything), but I think this is ready to be merged.
- I've kept the X11 requirement so that lightguns would work better. I know that there aren't many, but X11 would have to be installed and configured anyway so we might as well do it wholesale. I've used the
setBackend
functions to add X11 support, it's clearer this way.
I'm sorry for my lack of understanding here, but I don't see how this is meant to be clearer. I can't make sense of what is supposed to be happening.
Having run the latest version of the scriptmodule I see that the XINIT:
prefix is still missing from the emulators.cfg command line. The setBackend
functions seem to do absolutely nothing as far as I can tell.
As before, without the XINIT prefix, the emulator runs in a smaller window, applying a runcommand video mode has no effect and the lightgun accuracy is still out the window, so whatever setBackend is supposed to do isn't happening succesfully. The net result here is no different from the earlier version.
Adding XINIT:
to the start of the command line, and removing -fullscreen
fixes this.
Having run the latest version of the scriptmodule I see that the
XINIT:
prefix is still missing from the emulators.cfg command line. ThesetBackend
functions seem to do absolutely nothing as far as I can tell.
Yes, the XINIT
prefix is not needed when the setBackend
is used. The backend configuration was introduced quite some time ago - what RetroPie version are you using ? Do you have a file /opt/retropie/configs/all/backends.cfg
? At the very least, the supermodel3
entry should be in the backends.cfg
file (the -scaled
variant had a bug that's fixed now).
Thanks for your patience. the backends.cfg
file was indeed created and contained supermodel3="x11"
. My RP version was 4.8.6. I've now updated Retropie-Setup bringing it to 4.8.7 and updated all the core packages from that. And after running the corrected scriptmodule the -scaled
variant was added to backends.cfg
.
However, this has had little effect. I see only one difference: when launching a game, after the runcommand launching screen is shown, and before the game starts, a "desktop-style window" flashes on screen for a moment with "Supermodel" on the title bar and an X (close) icon in the right corner. Setting the videomode in the runcommand menu will alter the appearance of this window. At my preferred 720x400 mode, this fills the 16:9 space of my display, setting it to 640x480 makes it fill a 4:3 space the full height of my display, and clearing the video mode makes it fill the 16:9 space but thinner (presumably higher resolution). But, whilst this desktop-style window is affected by the videomode, the game itself is not. It always occupies the same space within the screen, the same space as before, and the lightgun is still inaccurate. :(
But, whilst this desktop-style window is affected by the videomode, the game itself is not. It always occupies the same space within the screen, the same space as before, and the lightgun is still inaccurate. :(
Are you talking about the supermodel3-scaled
emulator entry or the regular supermodel3
? If it's the former, then I'd expect the lightgun to be inaccurate since this seems to happen with -res=X,Y
. The only changes from the original (submitted) emulator setup is the addition of -fullscreen
to the command line (I doubt -vsync
influences the videoport calculation) - can you try the same test without -fullscreen
?
Are you talking about the
supermodel3-scaled
emulator entry or the regularsupermodel3
?
Regular supermodel3, I haven't been using the -scaled
variant at all. The command line in emulators.cfg is supermodel3 = "/opt/retropie/emulators/supermodel3/supermodel.sh %ROM% -fullscreen -vsync"
The only changes from the original (submitted) emulator setup is the addition of
-fullscreen
to the command line (I doubt-vsync
influences the videoport calculation) - can you try the same test without-fullscreen
?
OK. I removed -fullscreen
from the command line and this is what happens:. The emulator runs within the desktop-style window. Adjusting the runcommand videomode has an effect, here are some pictures of how The Lost Word appears using different videomodes in this test:
No video mode applied - presumably using the Pi's native resolution. I have mine set to 1920x1080 in cmdline.txt
Video Mode set to 640x480
Video Mode set to 720x400
This is really odd to me. I've never seen this windowed appearance before, not even when using XINIT on the old installation without -fullscreen. Sadly, i can't say whether the gun accuracy was better or not as the outline of the window was confusing the gun's border detection.
It appears to me that setBackend "x11"
is in no way establishing the same X11 environment as XINIT:
At least for this emulator.
Is XINIT:
simply starting the raw X11 display without any "Desktop" or "Window Manager" environment?
setBackend
most definitely seems to be starting a "Window Manager" that is taking control of the "window" sizing and placement. That's the only explanations that makes sense in my head for the behaviour seen.
Edit: Thinking further about the "raw" display theory with XINIT
- This would also explain fullscreen behaviour, without the -fullscreen
argument being required.
Is
XINIT:
simply starting the raw X11 display without any "Desktop" or "Window Manager" environment?
The only difference is setBackend
is starting a minimal WM (matchbox); there's no 'desktop' per-se started either with XINIT
or setBackend
.
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:
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 justsupermodel
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.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.