Aspect Ratio Stretching on Some Emulators
-
Ive noticed a few standalone emulators have begun stretching their aspect ratios to fullscreen as of the past few updates, namely Linapple, DOSBox and Daphne. You can trick Linapple to a 4x3 aspect ration by setting:
Screen Width = 600 Screen Height = 600
in the
linapple.conf
. DOSBox only stretches when the joystick is set to:joysticktype=none
in an external
.conf
at run time. For games that need to have the joystick set to 'none', this can be worked around by setting it in the maindosbox-SVN.conf
file ahead of time and for some reason, the DOS environment will run at it's OAR, despite the two.conf
files being identical in content. Daphne, on the other hand, is unable to be tricked back into it's OAR outside of temporarily setting the television to squeeze the 16x9 image to 4x3 during game play, which always works in a pinch.I know that SDL has proven to be problematic in the past and is tied to both graphics display and input control. Considering the strange DOSBox issue where a joystick setting is affecting graphics display, could this be the issue? Are other people experiencing any of this as well?
Pi Model or other hardware: RPi3
Power Supply used: 5.1V 2.5A
RetroPie Version Used: 4.2.13
USB Devices connected: 128 GB External Thumb, Logitech RumblePad 2, Mouse, Keyboard
Controller used: Logitech RumblePad 2
Emulator: Linapple, DOSBox, Daphne (perhaps more)
How to replicate the problem: See above -
I'm not aware of Daphne having been updated in ages (though I can't say I have tried to update it).
Can you check in some way what's the build date for Daphne?
I'm thinking it may be more likely that it's related to updating the underlying OS or firmware, if you've done it as well?
Edit: just not to sound like a useless commenter, the idea is that perhaps you'd be able to reinstall am older OS or firmware version if that would have been the case.
-
I'm not aware of Daphne having been updated in ages
I'm almost positive it hasn't. That's one of the reasons I thought it could be an SDL issue. Perhaps a somewhat recent update to SDL.
-
@mediamogul said in Aspect Ratio Stretching on Some Emulators:
joysticktype=none
For dosbox just put -c "joysticktype=none" (or whatever you want) in the .sh file before the drive mounts. Everything that is in the dosbox conf file can be added to the .sh files. I do this for old games that i need to force a cpu speed to slow them down.
-
That'll definitely work too. I've found several ways to adapt the emulators to use their original 4x3 aspect ratio again. The main purpose here is more to raise the question as to when and why the issue arose and if it's widespread, or isolated to myself. Out of the three emulators I listed, Daphne is the easiest way to reproduce the issue and probably has the highest install base. Can anyone confirm if it's stretching to full screen on a 16x9 display?
-
@mediamogul I just ran Cliff Hanger and it rendered in the usual 4:3 aspect ration with the black borders.
That being said, I haven't updated the OS in ages.
Linux 4.4.38-v7+ armv7l GNU/Linux
-
Nothing has changed with SDL either. OS/firmware or a configuration issue.
-
It's been a while since I started over with a fresh image. I'll give that a shot over the weekend.
-
I happened to be playing a combination of emulators today that revealed the source of the issue here. I started off playing some LinApple, and when I noticed the aspect ratio was correct, I checked Daphne and got the same result. I assumed it was a recent update that corrected everything, but then I went on to play some AdvanceMAME and after I was finished, I went back to Daphne and discovered the AR was incorrect again. After confirming the same with LinApple, I rebooted and the AR again returned to normal. As a final test, I launched AdvanceMAME and afterwards, the two emulators were indeed stretched. So, I guess the issue is with how AdvanceMAME leaves some part of the environment that affects certain emulators after it exits.
-
@mediamogul Ew. . . that's kinda messy. I use AdvMAME for a bunch of stuff. What ROMs were you launching with advancemame and which version of advmame (does it matter?)?
-
I'm running 3.5 and the issue has occurred with every ROM I've launched so far. If I'm remembering right, I was on 3.4 back when I first started this thread a few months ago. Fortunately, it only seems to affect a few emulators and perhaps only the two that I've mentioned.
-
I raised this issue around the same time you started this thread. Due to a lack of response and not seeing any advantages of AdvanceMAME 3.5 over version 0.94, I resorted to sticking with the earlier version.
It happened for me with DOSBox, jzIntv and Stella 4.7.3 as well as a number of ports, Crispy Doom and eduke32. As RetroArch emulators didn't seem to be affected, I came to the conclusion that the aspect respect stretching just affected non-RetroArch emulators and ports.
Curiously this includes AdvanceMAME 0.94 so if anybody wishes to reproduce this on their system with the same rom, then you can do the following.:
- Launch the rom in AdvMAME 0.94, then in 3.5 and then in 0.94.
You should see the aspect ratio in 0.94 stretch from 4:3 on the first launch to 16:9 on the second one. I used the 0.78 rom of Ninja Baseball Batman to test this.
My suspicion was that, as AdvanceMAME 3.5 uses the framebuffer, it's being left in an unusable state upon exit but I could well be wrong. I'm not really knowledgeable in these things. In any case, I believe it's an issue relating to AdvanceMAME rather than RetroPie or any of its libraries.
-
@dudleydes I noticed in that older post that you have
device_video auto
while I have always useddevice_video fb
. I don't know if it matters, as it is supposed to use the frame buffer anyway, but I have this setting for both of my 3.5 and 1.4 .rc files. Although I am just throwing ideas out there--my system is not running a widescreen display anyway, so I might not even notice the problem is happening. -
@caver01 Thanks for the suggestion.
During my testing in the summer, I noticed the difference in the
device_video
settings in the 0.94 and 3.5 .rc files. I'm sure I changed the setting in the 3.5 .rc file todevice_video fb
with no luck.In any case, I have just updated 3.5 from binary which has set
device_video fb
in the .rc file. Still no luck. -
@dudleydes Yeah I guess I forgot that the issue is what happens AFTER, not so much what advmame is doing going in, because the problem is occurring on other emulators.
It sounds like something should be logged on the dev site for advancemame, or perhaps @andrea_ita has some input here. In the mean time I wonder if we could use a
tvservice
or maybe anfbset
command to reset the framebuffer/video in a post run scirpt. -
I think I may have found another possible culprit to this issue. If you look here,
sdtv_aspect
is being set to '1', or 4x3. This is to ensure that the image is stretched to all sides, so that the proper aspect ratio will be displayed within that image. The problem may stem from the fact thatsdtv_aspect
was always a hack to achieve this goal and is technically a bug itself, seeing as how the setting should only ever have an effect on composite out.I tried running
vcgencmd get_config sdtv_aspect set 3
, or 16x9, after advmame exited and launching subsequent emulators still yielded a stretched picture. However, seeing as how the setting should never have even worked when set to 4x3, it could be that this is the expected behavior. I'd like to get any possible thoughts here before engaging the AdvanceMAME forums as to whether or not this could be an issue. -
@mediamogul I'm noticing the same thing w/ advmess and linapple. Did you ever figure out how to set/unset the framebuffer settings after launching advmame?
-
@telengard
Did you ever figure out how to set/unset the framebuffer settings after launching advmame?
Unfortunately no. I reported the issue back in April of this year, but unfortunately the same behavior still exists in the latest AdvanceMAME 3.9. Currently, I believe the only solution is to reboot RetroPie after AdvanceMAME has been launched during a session to reset the framebuffer.
Like any big project with limited contributors, bug reports known to affect more users are often prioritized. That being the case, it might help for those affected here to add a comment to the thread. Nothing pushy of course. Just a simple "same here" type statement would do the job.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.