Incline eXoDOS v6 — It's coming!

[PorkyThePaladin]

Imagine playing DOS games when you could be playing:

OR

 

[Grauken]

Imagine playing DOS games when you could be playing:

OR

Yeah, you might miss out on stuff like this

 

[octavius]

Yeah, I might be wrong, but I don't think they test on Win 7 or care about it... Staging still runs on Win 7, btw, but that might change going forward if support becomes too cumbersome. In reality, 99% of people are on Win 10+.

People living in the past, but with the newest versions of Windows...

BTW, I never got any error messages with eXoAppleIIGS.

 

[Grauken]

It's a highly curated form of the past, few can stand it raw

Though admittedly what is the real "raw" experience in this case is up to debate

 

[Rincewind]

Yeah, I might be wrong, but I don't think they test on Win 7 or care about it... Staging still runs on Win 7, btw, but that might change going forward if support becomes too cumbersome. In reality, 99% of people are on Win 10+.

People living in the past, but with the newest versions of Windows...

BTW, I never got any error messages with eXoAppleIIGS.

Well, it's a moving window (no pun intended)—the goal of eXoDOS and Staging as well is to provide the oldschool experience on *current* operating systems. To be fair, Win10 was released in 2015 and Win7 in 2009, and M$ stopped supporting it 3 years ago. We have Win11 now, Win12 previews have been released, so Win10 is hardly the newest. It's simply the most widely used.

Yeah, there are Win7 holdouts and I have it installed on a secondary partition (just for audio work, haven't touched that installation like in 5+ years, it just works in its "frozen" state with no network drivers), but simply running Win7 will increasingly become a "retro activity" itself going forward

 

[Grauken]

Calling Win 7 retro, daaaamn

 

[Unkillable Cat]

IIRC the de facto-window on the term 'retro' is 15 years, meaning it's not really valid for Win7 until next year.

(I've always been slow to switch OS's BTW, so that's nothing new to me.)

But back to eXoDOS - is there another 'release' of the torrent imminent? Or how exactly will the collection be updated in the future?

 

[Alex]

IIRC the de facto-window on the term 'retro' is 15 years, meaning it's not really valid for Win7 until next year.

(I've always been slow to switch OS's BTW, so that's nothing new to me.)

But back to eXoDOS - is there another 'release' of the torrent imminent? Or how exactly will the collection be updated in the future?

As I understand, minor updates will depend on the bundled updater, which will check if any of your game definitions need to be updated. The updater only works with the full eXoDOS version, not the lite one.

 

[Rincewind]

Yep, what Alex said is my understanding too about the updates.

See in this comment of mine.

 

[octavius]

BTW, I never got any error messages with eXoAppleIIGS.

I guess because it uses an older version of LaunchBox.
Anyway, I'm gonna use Win7 until the motherboard, the CPU or the world blows up.

 

[Rincewind]

octavius I found a reference to this on their Discord; some guy was having the exact same issues like yourself on Win7. Not many people use v6 with Win7 these days, so very few people run into it I guess!

The solution for him was this:

I replaced ssr.exe and SetConsole.exe with the ones frome ExoWin v2 and I can confirm it works fine !

You could grab those EXE files from this old v5 pack:
https://archive.org/details/eXoWin3x

I might be able to get the old EXE files and upload them somewhere for people stuck with Win7. By the way, it appears to be some LaunchBox compatibility thing or something.

For the record, running a *networked* computer with full internet access on Win 7 or earlier is still a *terrible* idea, 3 years after official support ended and no new security patches will be released. But it's your life guys :shrug:

 

[Rincewind]

octavius Okay, so one of the eXoDOS maintainers has kindly provided me with the two EXE files in question that get eXoDOS v6 working on Windows 7 64-bit. People stuck on Win7 32-bit are out of luck—get a better OS, guys...

The files are hosted on my personal Google Drive account, so you'll get a virus scan on downloading if you don't particularly trust me
Just replace "ssr.exe" and "SetConsole.exe" in your v6 installation with the ones in the ZIP.

https://drive.google.com/file/d/1YDqkTAHFIZ0zhUDYTLyeowjCTLC-2Be8/view?usp=drive_link

Some technical details if someone's interested:

The issue with these files and why we replaced them was that they are not compatible with terminal and windows 11 uses terminal by default. The new versions of these files were built by Timber [a guy from the eXo team] using python so that they are now compatible. Windows 7 however doesnt like the new versions now but as that OS is old we just moved on. Also Launchbox doesnt support 32bit anymore so the only people who can actually use eXoDOS as intended on win7 are those that use the 64bit release and we felt this wasnt a large group and most likely will upgrade at some point

 

[Rincewind]

Problem solved octavius?

 

[octavius]

Well, I didn't get any error messages when reinstalling, but I still get the python39 messages when starting a game. But Launchbox doesn't crash and things are working well enough now, although not quite as smoothly was the eXoAppleIIGS did.

 

[Rincewind]

Well, I didn't get any error messages when reinstalling, but I still get the python39 messages when starting a game. But Launchbox doesn't crash and things are working well enough now, although not quite as smoothly was the eXoAppleIIGS did.

Well, that's the most we can do here. Ultimately, you'll need to upgrade to Win10 eventually.

 

[Naraya]

Some shader porn (I know this thread is technically about eXoDOS, but still):

 

[Rincewind]

Some shader porn (I know this thread is technically about eXoDOS, but still):

That's a nice overview and comparison of my new adaptive CRT shaders, yeah.

 

[Kirben]

Other options include, as Unkillable Cat mentioned, ScummVM. This one has a completely different approach, trying to reimplement the engine of each game they support. This can lead to implementations that are actually very different from the original, although as far as I know most ScummVM games are actually pretty faithful. Furthermore, you can end up with interesting new features, such as the ScummVM version of the Might and Magic game being able to use the mapping system and interface of M&M 4-5. One downside of this approach, of course, is that you only support a limited number of games, since you aren't recreating the DOS environment.

The main problem with ScummVM is the implementations are often incomplete, the earlier games (SCUMM games in particular) were based off reverse engineering, which didn't exactly match the originals, and lead to differences. This is slowly been resolved by rewrites, but I don't think they are there yet.
More recent games added to ScummVM tend to be lacking in the sound area too, due to lack of developers in the area. The Might & Magic and Ringworld games are still lacking Roland MT-32 support, which I hope will be added eventually. Lure of the Temptress took years to finally get proper sound support, and may still have other walking issues too.
My main issue is there is currently no easy way to see what exactly is lacking and missing in games supported by ScummVM.

 

[Rincewind]

Another ironic thing about ScummVM is that they don't support the C64 versions of Zak an Maniac Mansion. Those were the two games that started it all; SCUMM was invented for the C64 version of MM (it stands for Script Creation Utility for Maniac Mansion).

But yeah, it's a hit and miss with all games, you simply don't know what they screwed up. It's not all roses.

 

[Nifft Batuff]

Some shader porn (I know this thread is technically about eXoDOS, but still):

That's a nice overview and comparison of my new adaptive CRT shaders, yeah.

A tangential question: Are your shaders available only for DosBox Staging? Is the source available or is there a way to use them in emulators for other systems (via retroarch maybe?)

 

[Alex]

Another ironic thing about ScummVM is that they don't support the C64 versions of Zak an Maniac Mansion. Those were the two games that started it all; SCUMM was invented for the C64 version of MM (it stands for Script Creation Utility for Maniac Mansion).

But yeah, it's a hit and miss with all games, you simply don't know what they screwed up. It's not all roses.

Does MAME suffer from the same communication problem? If not, it might be worth to look into how they avoid. I mean some of those arcade architectures saw much more use than any old game engine. But ultimately you still have the situation where you have a project that is implementing a variety of unrelated systems, so they are bound to have differing levels of completeness and of emulation quality.

 

[Azdul]

Other options include, as Unkillable Cat mentioned, ScummVM. This one has a completely different approach, trying to reimplement the engine of each game they support. This can lead to implementations that are actually very different from the original, although as far as I know most ScummVM games are actually pretty faithful. Furthermore, you can end up with interesting new features, such as the ScummVM version of the Might and Magic game being able to use the mapping system and interface of M&M 4-5. One downside of this approach, of course, is that you only support a limited number of games, since you aren't recreating the DOS environment.

The main problem with ScummVM is the implementations are often incomplete, the earlier games (SCUMM games in particular) were based off reverse engineering, which didn't exactly match the originals, and lead to differences. This is slowly been resolved by rewrites, but I don't think they are there yet.
More recent games added to ScummVM tend to be lacking in the sound area too, due to lack of developers in the area. The Might & Magic and Ringworld games are still lacking Roland MT-32 support, which I hope will be added eventually. Lure of the Temptress took years to finally get proper sound support, and may still have other walking issues too.
My main issue is there is currently no easy way to see what exactly is lacking and missing in games supported by ScummVM.

ScummVM does reverse engineer scripting engine - but the scripts themselves are taken from game files. They avoid supporting games where the logic is hardcoded - like in Dynamix games.

Might and Magic support is relatively fresh. I believe support for MM1 was added in 2023. Give it a decade or two - ScummVM becomes the definitive edition - with bug fixes that were available only in obscure re-releases - applied across the board.

Getting MT-32 support right is sometimes much harder than it looks. It is not quite General MIDI device - and it is reprogrammable.

If the game supports Roland SC-55 or SC-88 - you can be pretty sure that Roland GS extension of General MIDI is how the instruments supposed to sound like.

Sometimes MT-32 was the lead sound platform - like in early Sierra games - and you can be pretty sure that translating instruments to closely match MT-32 is the right way to go. Unless MT-32 was reprogrammed - like in Space Quests.

Sometimes - MT-32 support was added as an afterthought. Maybe original developers didn't even have MT-32 - and just played the soundtrack as if it was General MIDI instrument - with varying levels of success ? Not to mention clipping or buffer overflows of MT-32 hardware - when it was pushed too hard.

 

[Rincewind]

Some shader porn (I know this thread is technically about eXoDOS, but still):

That's a nice overview and comparison of my new adaptive CRT shaders, yeah.

A tangential question: Are your shaders available only for DosBox Staging? Is the source available or is there a way to use them in emulators for other systems (via retroarch maybe?)

Sure, have a look here:
https://github.com/dosbox-staging/dosbox-staging/tree/main/contrib/resources/glshaders/crt

Most of them are the CRT shader from Hyllian without changes, plus some of my minor hacks. Then `vga-1080p-fake-double-scan.glsl` and `vga-1080p.glsl` are my own special "remixes" of several shaders, but yeah, the rest are just basic Hyllian.

The "magic" is in the tweaked shader parameters so things look close to the real thing and good at various resolutions. That took me about a year, on and off. You really have to "live" with the settings for prolonged periods and make minor incremental tweaks. The "CRT effects" on PC monitors are rather subtle.

So in theory you could use the Hyllian shader in RetroArch with the same settings, but sadly that won't really get you there. Shaders are just one part of the solution, the rest is of course the auto-switching logic to make these really "adaptive", that's C++ code. Then another essential thing is to feed the shaders with the correct input. E.g. 320x200 VGA is really 640x400 at the signal level after the built-in hardware-level double-scanning of VGA adapters, so we need to send the shader effectively a 2x integer scaled input for most low-res VGA modes (that's a bit more complex in actual reality, but that's the gist of it). Then EGA modes on a real EGA adapter (so when not emulated on a VGA adapter) are not line-doubled, but I still pixel-double them to emulate the horizontal dot pitch of the rather sharp EGA monitors, otherwise you get a blurry picture which is not authentic for EGA. So, for example, for 320x200 EGA the shader gets 640x200. But CGA monitors have lower dot-pitch, so 320x200 CGA stays 320x200. And so on...

All I'm saying, getting the shaders right is just half of the equation. There's lots of custom code to feed them with the correct input, and that's at the core emulator side, outside of the shaders. Technically you could transfer some of the line/pixel doubling to the shader side when using a multi-pass architecture (we only have a single-pass architecture now), but still, you'd need to pass the correct configuration and flags to the multi-pass shaders from the emulator side... That won't happen by magic. I doubt any of the DOSBox cores on RetroArch have this level of sophistication... well, because I'm pretty much the first one who did all this correctly of all existing DOSBox forks (and crazy enough to pour a few hundred hours into it, but I love CRTs).

Well, and the upcoming version of Staging will be the first DOSBox variant with correct, authentic VGA emulation out-of-the-box (i.e., correct double scanning applied in all VGA modes, SVGA/VESA modes, custom VGA modes such as Mode X, etc.) Large parts of that done by yours truly, again

 

[Rincewind]

If the game supports Roland SC-55 or SC-88 - you can be pretty sure that Roland GS extension of General MIDI is how the instruments supposed to sound like.

Not so fast. Life isn't that simple. Many games lie about this and "advertise" GM/SC-55 support while they really have MT-32 soundtracks. Just refer to this table for the best results and always use the correct ROM versions as indicated by the table:

https://www.vogonswiki.com/index.php/List_of_MT-32-compatible_computer_games

Or vice versa; some claim MT-32 compatibility while in reality, they have GM soundtracks. There's an entire section devoted to this including a rather HUGE number of games, and not just obscure titles:
https://www.vogonswiki.com/index.ph...#Games_that_falsely_claim_MT-32_compatibility

The TL;DR is, you just wouldn't know (as an ordinary end user, without analysing the MIDI data, the drivers, and/or doing background research). You can't reason about this, and the game manuals lie too sometimes. Almost 20 years of research went into this table...

 

[Rincewind]

Btw, there's also DREAMM developed by a former LucasArts employee, Aaron Giles.

https://aarongiles.com/dreamm/

Check out the documentation for details:
https://aarongiles.com/dreamm/docs/v21/#intro-games

Here's how it differs from ScummVM and DOSBox (TL;DR it uses the original game executable and data files, so it's *not* a game-engine reverse engineering exercise like ScummVM—that's a crucial difference):

https://aarongiles.com/dreamm/docs/v21/#faq-scummvm

Key sentence:

That said, since ScummVM is not actually running the original interpreter engine code, it is difficult to claim 100% perfect reproduction of the original behaviors.