[DOSBox] official thread

mitu

@jamrom2 said in [DOSbox] official thread:

@mitu I'm definitely on buster... at least that's what it shows on the RetroPie-Setup Script header.

In this case you should have the binary install option - doesn't that work ?

jamrom2

@mitu I have the binary option but when I try to load it, it gives me that error at the end. Claims I don't have the correct version of meson, which makes no sense.

I also tried the source version, but it crashed as well.

Strange because I had already loaded the source version a while back without issue.

mitu

@jamrom2 said in [DOSbox] official thread:

I have the binary option but when I try to load it, it gives me that error at the end.

Please post the binary install log (from $HOME/RetroPie-Setup/logs) on pastebin.com.

jamrom2

@mitu said in [DOSbox] official thread:

@jamrom2 said in [DOSbox] official thread:

I have the binary option but when I try to load it, it gives me that error at the end.

Please post the binary install log (from $HOME/RetroPie-Setup/logs) on pastebin.com.

all set

https://pastebin.com/DvRGiKgC

mitu

@jamrom2 said in [DOSbox] official thread:

all set
https://pastebin.com/DvRGiKgC

Not quite, this is not a binary installation, it's a source installation.

For some reason though, your version of meson is not the one from the RPI repos - did you remove the RPI repos from your apt sources list ? Otherwise, apt update && apt full-upgrade should install version 0.56.1.

jamrom2

@mitu said in [DOSbox] official thread:

@jamrom2 said in [DOSbox] official thread:

all set
https://pastebin.com/DvRGiKgC

Not quite, this is not a binary installation, it's a source installation.

For some reason though, your version of meson is not the one from the RPI repos - did you remove the RPI repos from your apt sources list ? Otherwise, apt update && apt full-upgrade should install version 0.56.1.

Sorry... I took from the top of the log list thinking first last, when it's last first.

Here is the correct binary install I just did now.

https://pastebin.com/xf6KgvN6

No, I didn't remove anything manually, but that's not to say something else I've loaded did. I have a few emus that may have twisted my install a little. The Atari800 video script, MESS and Daphne/Singe installs I did I think somehow changed things a little.

I'll try what you posted and see if it works.

jamrom2

@mitu just tried

sudo apt update && apt full-upgrade

it came back with an error:

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

I'm logged in as pi what does it mean by root?

mitu

@jamrom2 said in [DOSbox] official thread:

Here is the correct binary install I just did now.
https://pastebin.com/xf6KgvN6

Seems to me you're using an older version of the Dosbox-Staging setup script, that you copied manually ? As @nemo93 mentioned at some point, it's now part of the RetroPie-Setup script, so you should remove the install script you copied manually and update your RetroPie-Setup script to the latest version. Afterwards, you can install the binary without issues.

I'm logged in as pi what does it mean by root?

The correct command is

sudo apt update && sudo apt full-upgrade

jamrom2

@mitu that might have happened while I was helping to test the newer versions of Staging a few months ago.

Where do I find that script to delete? Is it here?

/home/pi/RetroPie-Setup/scriptmodules/emulators

yeah... that extra "sudo" was missing. It's running the RPI repos update now.

also.. is 4.7.11 the latest RetroPie-Setup script version? If not... then I'm definitely having larger issues.

mitu

Where do I find that script to delete? Is it here?
/home/pi/RetroPie-Setup/scriptmodules/emulators

Yes.

also.. is 4.7.11 the latest RetroPie-Setup script version? If not... then I'm definitely having larger issues.

No, that's not the current RetroPie-Setup script version. If you have trouble updating to the current version, you should open a separate topic.

jamrom2

@mitu ok. I will. At this point, I think that's what's happening here. I'm not getting the current setup script.

@nemo93 I'll be back to help once I get this issue sorted. Not sure how this happened, but it seems to be the cause of all the headaches I'm having.

nemo93

@mitu much appreciated the time you spent here to assist @jamrom2. Thank you.
@jamrom2 I did check your other thread and I'm glad you get it sorted. Next time please be sure to rely on an official image :-) This is really the only way for all of us to ensure things will work as intended. I've started (and not finished) an article to guide users to setup a clean and easy-to-maintain DOS environment. Feel free to have a look.

jamrom2

@nemo93 All set. Long story short... when I loaded in the MESS build, I switched repositories from the true RetroPie set to the fork that the MESS build was based on. I never realized this, even though I did do it, I had no idea what it would do to my build. All is as it should be...

DosBox-Staging 77.1 is now loaded from the binary and working ... WOW! Amazingly fast.

For testing I chose:
NASCAR Racing
INDYcar Racing II
Aces Over Europe

All are running smoothly other than what I pointed out in an earlier post with A10 Tank Killer in regards to music slowing down when text boxes are posted.

NASCAR and INDYcar are very smooth and fluid. Considering these are mid-90s games with a lot of 3d polys and textures, that says a lot for Staging running on a Pi3b+.

What else do you need me to test? Can I now run any shaders on Staging? I'd like to try that.

nemo93

@jamrom2 glad you have everything back in a stable state. Regarding your game slowing down, as stated earlier this is likely related to the cycles count. Try setting a fixed cycles count for that game (eg. cycles = 15000 to start with).

For now testing is focused on the ARM64 dynarec. It's a kind of priority for the time being given everything else is stable. There might be updates to the controller-side. Shaders is something being looked at but it's really tricky to implement given the current codebase (details there). This would require quite heavy code change hence not sure when (and if) it will be implemented.

I'd say just enjoy your good old gems and report back should you hit any issue(s).

jamrom2

@nemo93 OK. Will do. Thanks!

I dropped it to 5000, seemed to be good now. The 15000 was too fast.

Ashpool

@nemo93 et al., So far I haven't run any DOSBox on my Raspis, but as I sadly noticed that GoG's (Battle Isle Phase IV) Incubation+Wilderness Missions ain't running under Windows 10, I thought that maybe now is the time to give it a try - and done some RTFM to the various versions, especially for 3dfx support (For Incubation IMHO a must) and noticed that it ain't that simple under *nix as it is under windows, or better to say with the prebuild GoG Installs.
Is DOSBox-X the only one that comes with OOBE 3dfx Support , or does any of the builds available for retropie support Glide Games and I haved missed that Information so far (Searching the Forum for Glide &| 3dfx ain't getting me any results)?

P.S.: Even if I doubt that it may be suited for a Pi(4), but as I still have my Battletech II 3dfx CD that came bundled with my Voodoo Card in my times of yore... well, it would be nice to get that up & running again too :Dreaming:

nemo93

@ashpool thanks for your comment. There's no 3DFX support in DOSBox Staging as we speak. There might be some ongoing work started but for sure nothing will land in the short term. No specification or even details have been shared thus far so please don't set your expectations too high on that.

DOSBox-X as well as DOSBox ECE are your best bets for that but not sure it will just work on Pis. Feel free to share any feedback if you give these a try. Thanks!

Ashpool

@nemo93: Thanks for the Info about Staging and about DOSBox ECE (just heard of it in the context of DOSbian before and wasn't aware that it features Glide support)!

Feel free to share any feedback if you give these a try.

I'll try to remember that, but as both games I've mentioned are in fact Windows Games (9x) I am doubtfull about any (playable) success . But inspired by this MagPi Article about installing Win98 on a Pi4, I am eager to give it at least a try ;)

Ashpool

@nemo93 And here it is, a shortened (mostly rant free) summary of my last weeks experiences with dosbox-x and dosbox ECE with a slight taste of 3dfx gaming (for dosbox-x with compiled OpenGlide as a wrapper).

Building ECE is imho a real PITA compared to dosbox-x, but nevertheless...
Under retropie (terminal) i had to experience, that as soon as usescancodes is true, and apparently thats valid for internationel keyboards if set as such (I am on a german one), the keys are shifted by 8 (backspace is u, c is right shift, etc.) - to keep it short, I had to set scancodes to false and using the keymap I found in a german forum here: Raspbian und DOSBox - Tastatur (still had to swap yz in it, but it spared me the time of making one myself).
For a quick Glide test I used (an image) of my "Extreme Assault (GER)" Cd patched within dosbox* to xa_110 (the first patch added a 3dfx exe, before it was plain/mmx enhanced only) and well... being unable to use opengl in the (pure) retropie environment, 3dfx gaming on it was unbearable as dosbox-x used its internal glide-emulation (and music was only midi, the tracks from the .cue/.bin image weren't recognized). For dosboxECE it was a complete failure, as that one was complaining/aborting the start of xa_3dfx with a "Fatal error: unable to load DLL".

Ok, switching over to Raspberry OS (not sure whether needed or not, but with enabled experimental OpenGL set in raspi-config)... compiled both forks again... no german keyboard trouble, and at least i was able to play the first three missions with openglide in dosbox-x (here the mounted image played the cda tracks just fine)... wasn't that bad an experience, but in further runs... from time to time the gfx lost the textures and showed just polygons or major glitches. Dosbox ECE had the same problem as before "unable to load DLL".

So for now, I think to skip further Glide/Voodoo experiments on the raspberry and try it under Ubuntu and Windows (later one with the option of dgVoodoo and/or nGlide vs. Openglide could be the better option... if not, german keyboard again, dosbox-x would suffer from this unfinished issue AltGr issues when using MS-DOS which is, with my intend of running a W95B/W98SE in it, somewhat a nogo. Under Ubuntu there are no keyboard problems so far. And I haven't tried ECE in WIN/UBU so far. ... but those experiences are better to be told elsewhere.

P.S.: I really don't get it why under x11 environments the scancodes have to be shifted by 8, or why the sources assume that to be true if it is a *nix system.

Edit: The .dll problem with dosbox ece was that I had forgotten that I had replaced the glide2x.ovl in the game directory with the one from dosbox-x (for the openglide wrapper test) - but dosbox ece turned out to be unplayable slow too (retropie environment, raspberry os not tested yet)

aftermath17

@nemo93 said in [DOSbox] official thread:

as per my other post above, run DOSBox Staging to get to the DOS prompt C:\>. Once you get there type in: C:\>config -wc. This will automatically upgrade your dosbox-staging.conf with all the new parameters.

provided you're running the 0.78.0 version, copy over my dosbox-staging.conf file from that page. At least the important sections which are: [sdl], [dosbox], [render] and [cpu].

I am running dosbox-staging (0.78.1) as per my binary and my config file. I renamed my dosbox-staging.conf and then ran "C:>config -wc" as per your post. Dosbox re-generated a new dosbox-staging.conf as expected. The problem is, I'm not see the settings set the way you are describing. Have the defaults changed? I see these (to select a few):

fullscreen         = false
display            = 0
fullresolution     = desktop
windowresolution   = default
window_position    = auto
window_decorations = true
vsync              = false
vsync_skip         = 7000
max_resolution     = auto
output             = opengl
texture_renderer   = auto
capture_mouse      = seamless middlerelease
sensitivity        = 100
priority           = auto,auto
mapperfile         = mapper-sdl2-0.78.1.map
raw_mouse_input    = false
waitonerror        = true
priority           = auto,auto
mapperfile         = mapper-sdl2-0.78.1.map
screensaver        = auto

frameskip          = 0