Pickle wrote on 2022-05-11, 12:21:

maybe you could include it but keep off by default and allow these extra features to be enabled by command line?

You mean include the fullscreen option (without status) on the MPU-only version but make it hidden? I mean, it's already technically included AND off by default (because you have to select your view size in Change View), but is hiding it and enabling it only via command line a necessary step in your opinion?

Note that I also already have a hack to the config file so that the vanilla EXE can still run properly even if the user selects the fullscreen view size on the wolfdosmpu EXE, so there's no worry of accidentally "breaking" things for the user.

Gmlb256 wrote on 2022-05-11, 12:48:

The fullscreen on the MPU-401 version can be kept barebones and the users can be warned that they won't be able to see the stats.

I'm leaning towards this solution, since it obviates the need for a command line option, and it's helpful to the user...

Okay, I've released version 1.50 on github!

As earlier mentioned, this new release now supports fullscreen mode! Just head to Change View and resize the window all the way up until the whole screen is black (including the instructions' background), then press Enter and then Y to the warning message. 😁

Some notes on fullscreen:

• For the MPU-only version, the config file is written so that you can still use your vanilla EXE with it -- the vanilla game will revert to the (unofficially-supported) borderless view size.
• For the modern-controls version, pressing the Tab key now shows your lives, health, ammo, and keys, to compensate for the status bar being hidden in fullscreen.
• Fullscreen mode uses much more conventional RAM than borderless mode due to the way the auto-generated wall-scaler code works, and your hard drive will thrash by the time you enter the large middle area in E1M1 if you have just 576KB of RAM and no EMS/XMS. Consider fullscreen support as "experimental". 😁

Other changes:

• Fixed rendering of door sides that are adjacent and perpendicular to each other, where one of them would occasionally render as a regular wall instead of a door side (and the door would appear to recede into the wall when opened). This bug can be observed on E2M8 and E5M5 (on the vanilla EXE) -- look for these doors in areas with one-tile-wide wooden corridors.
• Fixed noclip cheat (Tab+N) where the player cannot walk through blocked tiles on the first row or column of the map. Also made the cheat available in Wolf3D (instead of just SoD).
• Warp cheat (Tab+W) now removes your keys.
• Fixed F1 boss key (for commercial/demo releases) so that the menu music does not start playing (only to quickly turn off as the C> appears).
• Fixed F1 help key (for shareware/registered releases) so that the CORNER music is played, to be consistent with the Read This menu option.
• Fixed some out-of-memory issues on 576 KB of conventional RAM.

Works great so far!

A little feedback: In fullscreen during a game session there is no visible fade-in effect when entering the main menu (or pressing certain function keys) then returning into the game, making it look like there is a small delay.

Gmlb256 wrote on 2022-05-12, 01:45:

A little feedback: In fullscreen during a game session there is no visible fade-in effect when entering the main menu (or pressing certain function keys) then returning into the game, making it look like there is a small delay.

I've been meaning to ask about this. The code by default fades in just the UI after leaving a menu (except when loading a new level or savegame).

Should I just render the scene before the fade in? Also, to be consistent, should I do this for all view sizes (not just fullscreen)? (It's somewhat non-purist, but it's a very tiny detail and I can't justify adding it as a COMP flag...)

Alternatively, should I just remove the delay when it's fullscreen?

p.s. I already have code working to render the scene before the fade in. The level music also has to be restarted before the fade in (otherwise it's just kinda weird). Now it works okay, though not very "pure" feeling and might throw off players used to the original post-menu behavior. Should I keep it like that, though? (One can argue that it's just more consistent with how a level starts...)

ericvids wrote on 2022-05-12, 06:35:

Should I just render the scene before the fade in? Also, to be consistent, should I do this for all view sizes (not just fullscreen)? (It's somewhat non-purist, but it's a very tiny detail and I can't justify adding it as a COMP flag...)

Alternatively, should I just remove the delay when it's fullscreen?

I would prefer consistency by removing the delay when it's fullscreen because it doesn't make any sense to wait when the borders and status bar aren't visible. The rendered scene would still appear instantly that way though.

Okay, fixed it as you suggested!

Version 1.51 is now available on github! Threw in some very minor fixes too.

Changelog:

• Removed the half-second delay before the play screen starts rendering in fullscreen mode. This was due to the game trying to fade in the play screen's UI elements, which do not exist in fullscreen mode. (If the game is not in fullscreen, these UI elements will still fade in as usual.)
• The warning to enter fullscreen mode is now only shown once in a session (in case the user wants to switch often, e.g., to temporarily view the stats in the MPU-only version).
• Customize Controls screen now prohibits essential keys (Esc, F1-F10, and Tab for the modern-controls version) from being customized.

Glad you removed the delay in fullscreen, it was the right decision. And I'm loving fullscreen mode. Makes the game so much better, even after 30 years and playing it halfway to oblivion. Thanks again.

Nice job on adding the borderless view, ericvids!! 😁 It seems to work just fine.

For the 30th anniversary of Wolfenstein 3D, this 'expansion pack' was also uploaded to Mod DB: https://www.moddb.com/mods/wolfenstein-3d-30t … versary-edition
This version also has borderless view implemented. I'm curious if he took the same approach as you did 🙂

Unfortunately, wolfdosmpu does not seem to work with this mod. First it reports no .WL6 files can be found (mod uses .WL9 files), and after renaming the files, I get a compatibility error after the first loading screen.

It's a shame really that the creator did not approach you, and/or used your mod instead, although he probably does not know about your awesome mod!
Do you think you can make this add-on (easily) compatible with your mod? 🤔

mOBSCENE wrote on 2022-06-06, 21:43:

For the 30th anniversary of Wolfenstein 3D, this 'expansion pack' was also uploaded to Mod DB: https://www.moddb.com/mods/wolfen […]
Show full quote

For the 30th anniversary of Wolfenstein 3D, this 'expansion pack' was also uploaded to Mod DB: https://www.moddb.com/mods/wolfenstein-3d-30t … versary-edition
This version also has borderless view implemented. I'm curious if he took the same approach as you did 🙂

Unfortunately, wolfdosmpu does not seem to work with this mod. First it reports no .WL6 files can be found (mod uses .WL9 files), and after renaming the files, I get a compatibility error after the first loading screen.

It's a shame really that the creator did not approach you, and/or used your mod instead, although he probably does not know about your awesome mod!
Do you think you can make this add-on (easily) compatible with your mod? 🤔

Most of these Wolf3D "standalone TCs" tend to make changes to the source code and this one is no exception (in-game messages, new weapons, etc).

Also adapting this "add-on" would be out of scope for wolfdosmpu because it intends to be compatible with the vanilla executables.

Gmlb256 wrote on 2022-06-06, 22:18:

Most of these Wolf3D "standalone TCs" tend to make changes to the source code and this one is no exception (in-game messages, new weapons, etc).

Also adapting this "add-on" would be out of scope for wolfdosmpu because it intends to be compatible with the vanilla executables.

So you're saying that part of the resources could be located inside the executable/source mod itself? I was under the impression all resources are inside the .WL6 files (or .WL9 files in the case of this add-on), and the source mods just add extra features and remove limits. For the same reason that wolfdosmpu works correctly with the "Super Upgrades" add-on pack (official pack with 800 new levels). Although I don't know if this pack also contains new/replaced resources.

From the description of the add-on on Mod DB: "30 new levels, 10 levels in each new episodes, two new guns (both that can be located on the original levels too)", which led to me believe this add-on only replaces existing resources, not adding new ones. I understand that wolfdosmpu is vanilla based, and can't be made compatible with every add-on out there, but maybe in this case it is just some resource limit that could be adjusted?

But perhaps asking the creator of this add-on to provide wolfdosmpu compatibility is a better approach 🙂

mOBSCENE wrote on 2022-06-07, 14:39:

So you're saying that part of the resources could be located inside the executable/source mod itself? I was under the impression all resources are inside the .WL6 files (or .WL9 files in the case of this add-on), and the source mods just add extra features and remove limits. For the same reason that wolfdosmpu works correctly with the "Super Upgrades" add-on pack (official pack with 800 new levels). Although I don't know if this pack also contains new/replaced resources.

From the description of the add-on on Mod DB: "30 new levels, 10 levels in each new episodes, two new guns (both that can be located on the original levels too)", which led to me believe this add-on only replaces existing resources, not adding new ones. I understand that wolfdosmpu is vanilla based, and can't be made compatible with every add-on out there, but maybe in this case it is just some resource limit that could be adjusted?

But perhaps asking the creator of this add-on to provide wolfdosmpu compatibility is a better approach 🙂

Yes. Not all the changes are inside the data files (.WL1, .WL6, .SOD, etc) as they just usually contain the maps, graphics, demos, text mode screens that gets displayed after exiting the game and the "Read This!" content. It requires a modifed EXE for the additional features to work as the rest is hardcoded.

The "Super Upgrades" add-on pack just replaces the maps without adding any new feature to the game and that's why it works with wolfdosmpu.

mOBSCENE wrote on 2022-06-06, 21:43:

Do you think you can make this add-on (easily) compatible with your mod? 🤔

As Gmlb256 has stated, it is out of scope for wolfdosmpu's intended purpose. It would usually have to be the other way around -- source-changing mod authors will need to build their mod on top of wolfdosmpu instead of the original id release.

I could not personally assess whether I can make this specific add-on compatible, because the author did not include any source code (at least I could not find any in the moddb downloads). I'm aware that id's original license does not force people to release the source code to their own modifications, so this is rather unfortunate.

Hi, tried this mod for the first time and it is absolutely great!

I wonder if some enhancements are still possible, like on the sound engine part. It seems that still the engine can only handle 1 PCM sound at a time. Is it possible to improve on this? Or maybe add Gravis Ultrasound support which can mix 32 sound channels at the same time?

carlostex wrote on 2022-07-02, 13:48:

I wonder if some enhancements are still possible, like on the sound engine part. It seems that still the engine can only handle 1 PCM sound at a time. Is it possible to improve on this? Or maybe add Gravis Ultrasound support which can mix 32 sound channels at the same time?

Handling more than 1 PCM sound at the time will definitely require real-time mixing; as you said, Gravis Ultrasound support for hardware-based mixing (I believe there's a mod called "UltraWolf" for this, which I have never tried because I never had a GUS), or a DMX-like software mixing solution (not sure if anyone has done this on wolf3d specifically). I don't know when/if I will be able to work on doing one or the other though... When/If I do get around to it, it would entail gutting out the id sound code in its entirety, which also means refactoring the new MPU code with it...

The problem I foresee for software mixing is whether a 286 can still handle the load. Apart from the inherent speed limitations, it will be limited to 16-bit x86 code, and thinking in 20-bit segment-offset memory is a pain, AND we also need to preserve compatibility with TSRs that emulate the MPU.

ericvids wrote on 2022-07-07, 15:09:

Handling more than 1 PCM sound at the time will definitely require real-time mixing; as you said, Gravis Ultrasound support for hardware-based mixing (I believe there's a mod called "UltraWolf" for this, which I have never tried because I never had a GUS), or a DMX-like software mixing solution (not sure if anyone has done this on wolf3d specifically). I don't know when/if I will be able to work on doing one or the other though... When/If I do get around to it, it would entail gutting out the id sound code in its entirety, which also means refactoring the new MPU code with it...

Never heard of that mod before! I just watched a video of it and though it supports several sounds at once the pitch is altered. It's a curiosity i guess. But yeah i understand the difficulties of adding GUS native support. The reason i'm mentioning it is because i honestly think this is the best DOS source "port" of Wolf3D ever. It really becomes a good base to improve on the game, specially considering the music in General MIDI is sounding great, and the WASD + Mouse implemented controls work very well. I won't even mention the in game map option which is also fabulous.

So that's basically it, since the audio, in the music department got such a good treatment, i was wondering if it would be worth to improve on the game further and give it anothe rboost, this time on the PCM side. But yeah, i understand the difficulties.

ericvids wrote on 2022-07-07, 15:09:

The problem I foresee for software mixing is whether a 286 can still handle the load. Apart from the inherent speed limitations, it will be limited to 16-bit x86 code, and thinking in 20-bit segment-offset memory is a pain, AND we also need to preserve compatibility with TSRs that emulate the MPU.

Hmmm, i find it admirable that you still want to keep it playable on a 286 but honestly, with these kinds of "ports" that enhance on a game chances are its only going to get worse on those machines, unless you use a better C compiler than the one that was originally used, or maybe use inline assembler for specific critical parts of the code.

All in all, this is great work. Whether you keep improving on it or not, this is pretty amazing already.

There's one thing I've always wondered about: the PCM audio in the DOS version. The fidelity of the samples taken in 1992 was very poor; something like 8-bit at only 5512 hz. Do modern 16-bit 44100-hz fidelity of these same samples exist anywhere? Is it possible for the DOS version to use true 16-bit audio samples as opposed to merely upsampling the original 8-bit poor-fidelity samples?

That is possible, with the original audio source files or replacements. With the source code, you can likely up the quality of what you can work with, if you have good programmers.

It should be possible to support higher quality samples in Wolf3D but it would require making adjustments in the sound engine. However, the memory usage would be higher (especially with a real-mode game).

Hi! any tips to make wolfdosmpu qith QEMM386? i tested both version 7 and 9, and wolf hangs at start at "WORKING..."

Works fine with emm386

thanks!

theelf wrote on 2023-06-13, 21:41:

Hi! any tips to make wolfdosmpu qith QEMM386? i tested both version 7 and 9, and wolf hangs at start at "WORKING..."

Works fine with emm386

thanks!

Weird, wolfdosmpu worked with QEMM 97 on my old computers.

Try adding X=F000-FFFF parameter for QEMM, I use it for stability reasons.