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

[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: https://github.com/cmitu/RetroPie-Setup/commit/807ccd6a92605034ce3c191faf11e801133067a4

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:

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.

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

[Widge-5]

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.

[DirtBagXon]

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:

• _SDL_WINDOW_FULLSCREEN, for "real" fullscreen with a videomode change_

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 :)

[cmitu]

[...] 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.

[mrcmunir]

@cmitu doesn't run due res=%XRES%,%YRES% doesn't seems return resoluton working correctly value and back to emulationstation

[cmitu]

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

[mrcmunir]

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

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

[cmitu]

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 ?

[mrcmunir]

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.

[DirtBagXon]

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.

[cmitu]

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.

[Widge-5]

Ah, so I see you're still forcing the emulator to run at a higher resolution by default.

[cmitu]

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

[DirtBagXon]

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

[DirtBagXon]

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.

[cmitu]

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:

• 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. The -borders is gone, but we'll document the usage of the params file.
• Since scaling with -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.

[Widge-5]

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

[cmitu]

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.

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

[Widge-5]

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. :(

[cmitu]

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 ?

[Widge-5]

Are you talking about the supermodel3-scaled emulator entry or the regular supermodel3 ?

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.

[DirtBagXon]

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.

[cmitu]

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.