Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
So basically this thread should be read as "we're reinventing Dosbox to eclipse and overtake all other inferior Dosboxes out there, but we ain't gonna have their features because they're teh hard… but look at these pixel-perfect reverbs, that's the shit, man!"
Dunno, I guess you can ask on their Discord? The usual answer from eXo is: when it's ready. But probably soon. Not sure if they wanna wait for the final version of Staging v0.81.0 or not. In v6 they'll have a mechanism to push updates of the emulators themselves too, so slowly but surely they'll migrate everything over to Staging in a gradual upgrade process.
(Having some strange texture(?) glitches in Ravenloft: Stone Prophet though - but they are probably not related to shaders, as I see them with output=texture also)
I don't know what are the specific issues concerning DOSBox, but I understand that creating a "save state" of a system that interacts with an external file system, as is the case, can be a big headache. Especially if the player doesn't realise that and uses multiple save states together with saving; you can end up with files in corrupt states.
I don't know what are the specific issues concerning DOSBox, but I understand that creating a "save state" of a system that interacts with an external file system, as is the case, can be a big headache. Especially if the player doesn't realise that and uses multiple save states together with saving; you can end up with files in corrupt states.
That's one of the major headaches, correct. The other is to support all the millions of combinations of possible settings and configured hardware, and restore everything correctly.
AFAIK ECE did not have savestates for this reason. Daum had a horribly messy and unmaintainable implementation; probably one of the reasons that contributed to the eventual demise of Daum as no one wanted to maintain it. There are similar savestate patches floating around, the team had analysed them in the past; they're hacky, buggy, incomplete, and a mess. We won't take such code, that harms the project long term.
DOSBox X has a savestate implementation, probably the cleanest of all, but Staging and X have diverged a lot and have very different goals. My understanding is their implementation is still flaky and very fragile, and probably there are lots of weird bugs.
Adding savestate support for home computer emulators and console emulators especially is almost trivial, but very hard for emulators of fully configurable PCs. Even WinUAE only supports savestates for floppy equipped base Amiga models. If you start adding peripherals, turbo cards and an emulated HDD, savestates were never officially supported, and I think in the latest version they're hard disabled.
So don't hold your breath, no one has cracked this nut for complex emulators yet in a satisfsctory manner...
Of course, if someone sends a few hundred thousand dollars in our way, we'll start a research project Other than that, you'll have to wait until someone from the team is enthusiastic enough to sink a few hundreds or thousands of hours of his life into this...
(Having some strange texture(?) glitches in Ravenloft: Stone Prophet though - but they are probably not related to shaders, as I see them with output=texture also)
(Having some strange texture(?) glitches in Ravenloft: Stone Prophet though - but they are probably not related to shaders, as I see them with output=texture also)
(Having some strange texture(?) glitches in Ravenloft: Stone Prophet though - but they are probably not related to shaders, as I see them with output=texture also)
Ok, potential regression then. Can you please raise an issue ticket about this on GitHub with relevant info? Then we'll investigate. If it's a regression, this is important.
(Having some strange texture(?) glitches in Ravenloft: Stone Prophet though - but they are probably not related to shaders, as I see them with output=texture also)
Yeah, most likely Ok, potential regression then. Can you please raise an issue ticket about this on GitHub with relevant info? Then we'll investigate. If it's a regression, this is important.
Ok, potential regression then. Can you please raise an issue ticket about this on GitHub with relevant info? Then we'll investigate. If it's a regression, this is important.
Well, yesterday I downloaded the latest dev build (dosbox-staging-windows-msys2-x86_64-v0.81.0-alpha-1793-g068b4) and you know what - no more texture glitches in Stone Prophet!
Loading the same save file, being in the same dungeon, doing the same things - I immediately see issues with textures when I use any of
It's like textures keep randomly redrawing for 5-6 seconds after your party comes to a halt - sometimes ending up with weird black tiles.
BUT dosbox-staging-windows-msys2-x86_64-v0.81.0-alpha-1793-g068b4 works like a charm - all good, no glitches whatever I do. Fantastic!
Looks like it has already been fixed somewhere between alpha-1745 and alpha-1793, so I reckon there's no need for a separate ticket anymore.
I'll be keeping an eye on this as I'm going to play Stone Prophet for a while anyway. If I run into the same glitches again in the following DosBox Staging builds I'll raise this issue.
Tried this recently and most stuff that runs fine in dosbox classic simply doesn't run in this staging. So much for all that better 'code quality' (whatever that means) and complete lack of actual quality.
Tried this recently and most stuff that runs fine in dosbox classic simply doesn't run in this staging. So much for all that better 'code quality' (whatever that means) and complete lack of actual quality.
Ok, potential regression then. Can you please raise an issue ticket about this on GitHub with relevant info? Then we'll investigate. If it's a regression, this is important.
Well, yesterday I downloaded the latest dev build (dosbox-staging-windows-msys2-x86_64-v0.81.0-alpha-1793-g068b4) and you know what - no more texture glitches in Stone Prophet!
Loading the same save file, being in the same dungeon, doing the same things - I immediately see issues with textures when I use any of
It's like textures keep randomly redrawing for 5-6 seconds after your party comes to a halt - sometimes ending up with weird black tiles.
BUT dosbox-staging-windows-msys2-x86_64-v0.81.0-alpha-1793-g068b4 works like a charm - all good, no glitches whatever I do. Fantastic!
Looks like it has already been fixed somewhere between alpha-1745 and alpha-1793, so I reckon there's no need for a separate ticket anymore.
I'll be keeping an eye on this as I'm going to play Stone Prophet for a while anyway. If I run into the same glitches again in the following DosBox Staging builds I'll raise this issue.
Thanks for confirming, that's great to hear! Yeah, the dev builds are fast-moving; it's always recommended to test with the latest you downloaded on the same day at least. Regressions spotted a few days ago might have already been fixed
Please report / raise any issues or regressions you find; we're here to help.
Tried this recently and most stuff that runs fine in dosbox classic simply doesn't run in this staging. So much for all that better 'code quality' (whatever that means) and complete lack of actual quality.
If you run into any actual regressions, please report them on our GitHub issue tracker so we can fix them.
It's not impossible to run into regressions, of course. But be aware that the team & community is constantly regressions testing with thousands of games, plus the eXoDOS project is gradually moving to Staging. That's ~10k DOS games, the best comprehensive regression test suite one can hope for.
So yeah, please report issues, they'll be fixed.
Btw, the "simply don't run" scenario seems to be fishy, I'm talking about glitches here when I say "regressions". Minor things, mostly, not the game not working *at all*. If lots of games "simply don't run", I'm suspecting something went wrong with your setup. Compatibility in general is *better* across the board than using legacy (and defunct) original DOSBox. So "complete lack of actual quality"—that's a bit rich, man
" 'code quality' (whatever that means)" — for you, the non-coding end-user that means that the project remains maintainble long-term and you will see continuous improvements and fixes. Unlike original DOSBox which hit a bit of a dead-end in many areas, making improvement next to impossible. Probably one of the reasons why most development on it stopped more than a decade ago. If code becomes an unmaintainable mess, a project becomes effectively dead or near-dead.
I'm having a problem reinstalling GUS in version .80, as it's not registering that a GUS card is installed in the installation. I have GUS enabled and Soundblaster disabled. I'm using GUS version 4.11 that I got from here if that's a problem.
Edit: It seems to be working despite not installing properly. Weird.
I'm having a problem reinstalling GUS in version .80, as it's not registering that a GUS card is installed in the installation. I have GUS enabled and Soundblaster disabled. I'm using GUS version 4.11 that I got from here if that's a problem.
Edit: It seems to be working despite not installing properly. Weird.
Use that ZIP as the official samples have looping problems with some instruments; that ZIP contains the fixed patch set. Probably emulation bug but tedious to track down and the fixed patchset is perfect.
Getting the GUS installer work without errors would be vaguely nice I guess, but DOSBox only needs the patch set from it, so very low priority issue.
For GUS native games where you can select Gravis in the game's sound setup utility, that is. If you want to use the Roland emulation of the GUS, well that's more complicated. But there's not much point in that unless you're on some weird nostalgia trip as FluidSynth or SCVA is superior for Roland MIDI (General MIDI / Sound Canvas / GS / SC-55, or some other confusing name in the game's setup util...)
Cross-posting a release announcement *once* here as well because I only posted it in my other 0.81.x specific thread a while ago. From now on, I will only post new release notifications in this thread, then hopefully people can find them. Thanks spekkio
DOSBox Staging v0.81.1 has been released, containing important regression fixes and a few new enhancements.
v0.81.0 was an absolute monster of a release; we went a bit crazy with it and put in about three regular major releases' worth of stuff. Because of that, this patch release is quite on the large side too—it's almost like a regular "non-obese" major release