[NY00123]

[UPDATE: Oct 14 2022] Web page link for reading a bit about the project: https://reflectionhle.com/

[UPDATE: Dec 31 2021] The project is titled ReflectionHLE as of writing this. Ignoring the URL, the rest of this post currently remains unedited by me.

Hi all,

Let me introduce you to the following source ports inspired by Chocolate Doom, now also covering Wolfenstein 3D: https://github.com/R...ionHLE/releases

This is a 6 years anniversary release. On September 26 2014, I released a new port of Keen Dreams, initially titled "Chocolate Keen Dreams".
Although Keen Dreams was released earlier in the same month, I actually started some work on it even earlier, after the Catacombs were open-sourced (in June 2014). Reason is that I already knew that a lot of the code was common.

Following Keen Dreams, I added Catacomb Abyss, then Catacomb 3-D, and finally the rest of the Catacomb Adventure Series.

Recently, I've been working on the source ports again. With the assistance of the gamesrc-ver-recreation/wolf3d tree, the last release introduces support for Wolfenstein 3D, Spear of Destiny (excluding the mission packs) and Super 3-D Noah's Ark (DOS version).

For Wolfenstein 3D, this currently covers Apogee shareware versions 1.0, 1.1, 1.2 and 1.4 (the one with cheats), as well as 6-episodes Activision v1.4.
For Spear of Destiny, this covers FormGen demo v1.0 and Activision v1.4.
For Super 3-D Noah's Ark, this covers the one Wisdom Tree DOS version that I'm aware of.

There are still some problems. In particular:
- You can't save games or load saved games in Wolf3D and the games based on it.
- These games have no support for the "modern" game controller scheme. I think that the other games should still have it, though.
- For technical reasons, you can't load the Spear of Destiny mission packs.
- More generally, you can't load TCs made to work with original EXEs from the 90s (as released by id and/or related publishers). I still haven't decided how to approach this.
- In order to detect game data, you also need the original DOS exe (albeit the 2015 edition of Keen Dreams is an exception).
- For Super 3-D Noah's Ark, this exe currently has to be named noah3dos.exe, as this is the way it arrives from Steam right now. Currently, there's no good way to support auto-detection of data with alternative file names.
- The rate of palette updates in Wolfenstein 3D is at least somewhat imprecise.
- VSync is disabled by default for now. There are other potential problems with timing in Wolfenstein 3D, which might partially be related to instances in which the game tries to render more often than the host display's refresh rate.
- Stereo panning remains unimplemented.
- For the Wolfenstein 3D based games, if you try to use a wall right after pushing it, the behaviors are essentially undefined.

[MrFlibble]

This is a great update, congrats! I gather this is going to be essentially the Chocolate Wolf3D, right?

Will it be possible to turn off the wall bump sound effect, like in ECWolf?

Any plans to add other titles on the same engine at some point?

[NY00123]

MrFlibble, on 27 September 2020 - 07:38 AM, said:

This is a great update, congrats! I gather this is going to be essentially the Chocolate Wolf3D, right?

Thanks for your feedback!
The goal of this is being a Chocolate Doom equivalent. I eventually used "Reflection", even in 2014, in order to be a bit more original. Also, there's already this unrelated port titled Chocolate-Wolfenstein-3D: https://github.com/f...-Wolfenstein-3D

Quote

Will it be possible to turn off the wall bump sound effect, like in ECWolf?

Since I think that the originals don't allow this, then as a Chocolate Doom equivalent, I believe that the same should apply to Reflection Wolfenstein 3D as well.
If I ultimately do get to figure out a way to let the user load an add-on originally made for DOS exes as distributed by id and/or publishers of the game, then replacing the sound might be an option.

Quote

Any plans to add other titles on the same engine at some point?

As usual for me, I tend to not talk about a future plan before I have something ready, or at least underway, heh.

I kinda made an exception for Reflection Wolfenstein 3D, when I brought it up in a few places last July (at least in public Discord and Matrix rooms). Reason being that this was 25 years since Wolfenstein 3D and Spear of Destiny were originally open-sourced. I hoped that I'd have something ready by then. Eventually, of course, much more work was awaiting, and it's still incomplete, but it's at least playable.

By the way, I've uploaded a hot-fix release:

Quote

Sep 28, 2020 (v0.30.1):

* Don't show controller settings specific to the Catacombs for Wolf3D.
* When letting the user choose a root drive on Windows for locating
game data, append a backslash. For instance, use "C:\" instead of "C:".
Otherwise, the wrong locations may get accessed with _topendir.
* Fix dir resource leak in BEL_Cross_DirSelection_PrepareDirsAndGetNames.
* Wolf3D: Fix the occurrence of a stale menu item in the
main menu for the GOODTIMES and SPEAR versions.
* Improve the scrolling in the launcher a little bit,
mostly while pressing on up/down.

[NY00123]

A new release is now available. The most important update is probably the addition of support for the Spear of Destiny Mission Packs. There's more, like the detection of more possible locations for game installations, as well as support for more versions of Wolfenstein 3D.

Oct 16, 2020 (v0.31.0):

* Support more than one possible filename for game data and EXE names.
Following this, a file named "NOAH3D.EXE" can now be identified as
a part of Super 3-D Noah's Ark, in addition to "NOAH3DOS.EXE".
This refers just to the matching DOS executable.
File integrity check is done using the size and crc32.
* Additionally, again thanks to the above, support for the
Spear of Destiny Mission Packs is now in. Reason it's related
is that the file extension of the mission-specific game data can vary,
depending on the game installation being in use and its current state.
For all missions (including the original), .SOD and .SD4 are valid
file extensions. Other allowed extensions: .SD1 for the base game,
.SD2 for mission 2 and .SD3 for mission 3.
* Note that as a side-effect, data integrity checks are now done for all
game data (graphics, maps, sounds) read from the Wolfenstein 3D codebase.
In addition to earlier uses of it, the hidden "manualgamevergame" setting
can now be used to disable this, albeit this might make it impossible
to properly start Super 3-D Noah's Ark or any of the Spear of Destiny
missions, depending on the filenames.
* Add support for more versions of Wolfenstein 3D, again by using code from
gamesrc-ver-recreation. This covers Apogee 6-episodes versions 1.1, 1.2 and
1.4, two GT Interactive releases, an id Software release, Apogee 3-episodes
versions 1.2 and 1.4, an Imagineer version and the March '92 prototype.
(Thanks to the wolf3denginepatches repository and Chris for assistance.)
* Add detection of Wolfenstein 3D as it used to be offered via the
last incarnation of 3drealms.com, either on its own or as a part
of the 3D Realms Anthology. (Thanks Lunick.)
* Add detection of Wolfenstein 3D, Spear of Destiny and Super 3-D Noah's Ark
as currently available from GOG.com. (Thanks WayneCa and chungy.)
* Improve detection of game installations which is done by inspecting
the Windows Registry. Basically, this is now done by attempting to
inspect data for 32-bit and 64-bit applications altogether, while
additionally still trying to get data with SHGetValue as usual.
* Wolf3D: The UPLOAD macro was replaced with an UPLOAD variable.
* Internally rename the wl1ap12 namespace to wl6ap11, and do the same with
other mentions of such strings. Most noticeable impact is probably
that when separate Wolf3D EXEs are build, reflection-wl6ap11 is
created instead of reflection-wl6ap12.
* Typo fix: Do show "Wolfenstein 3D Shareware v1.4 (Local)" when referring
to shareware v1.4, instead of mistakenly mentioning v1.2 in the string.
* Use a bit shorter descriptions for certain Wolfenstein 3D and
Spear of Destiny versions, so they can fit as launcher titles
(BE_Launcher_Handler_SupportedGameVersionSelection).
* Add high level XMS and EMS implementations, use them in Wolf3D's
Page Manager, and also remove the REFKEEN_SIMPLIFIED/NOEMS/NOXMS
implementations from Wolf3D. (Thanks Blzut3.)
* Wolf3D: Following the removal of the REFKEEN_SIMPLIFIED-specific code
from id_pm.c, pointers can now be appropriately converted in ShapeTest.
* A small fix for using page up/down in the launcher while
none of the menu items can be selected.
* A couple of fixes for bugs introduced after the audio mixer refactoring,
specific to runs without the audio subsystem.
* Separate more audio and timing related code into more files, while reducing
direct references to SDL (albeit it's still used in the same manner).
* Generally, continue splitting the contents of be_cross_fs.c and
making other restructurings and differing changes related to this code.
* Wolf3D: Fix a possible buffer overflow in US_CheckParm, reproduced by
passing an argument with no alphabetical character. A good example is
the second argument in the following arguments string: "-tedlevel 1".
* Make the codebase more usable with Visual Studio.
* Launcher: Add a missing comment about the impact of the
scale type setting on the border porches.
* Bug fix: Conditionally hide or show the mouse cursor after
toggling fullscreen, depending on game-specific setups.
* Fix an instance in which the in-game contents don't get
appropriately resized after toggling fullscreen.
* Wolf3D: Make the mouse cursor usable while the game
is paused, if a fullscreen isn't used.
* Other misc. fixes/changes.

[MrFlibble]

I take it that the behaviour differences between the Wolf3D versions are reproduced accurately depending on the actual version being played?

TBH I forgot the details but I do remember that there are some different behaviours. Also didn't v1.4 introduce some bugs/odd changes like B.J.'s animation not playing on the level tally screen?

[NY00123]

MrFlibble, on 16 October 2020 - 02:25 AM, said:

I take it that the behaviour differences between the Wolf3D versions are reproduced accurately depending on the actual version being played?

Generally, this is the case. Since I'm using code from gamesrc-ver-recreation which was constructed to let ones make exes which are more-or-less identical to the originals, the original behaviors should stay for most.

Of course, though, there are still differences in behaviors due to mistakes of mine, buffer overflows/over-reads which are difficult to emulate and/or other side-effects of porting.

Quote

TBH I forgot the details but I do remember that there are some different behaviours. Also didn't v1.4 introduce some bugs/odd changes like B.J.'s animation not playing on the level tally screen?

A good question is what is "v1.4" referring to. I think that it is common to refer to the Activision version as "v1.4" these days, while other version numbers are used for the matching Apogee versions. I guess that in this specific instance, "v1.4" may also refer to other non-Apogee versions with game data which is compatible with the Activision one.

Wolf3D was initially made with Apogee Software, Ltd. (i.e., 3D Realms) as the sole publisher. This covered multiple versions, the last of which being identified as 1.4. There was a period in which it was decided in 3DR to disable access to cheat codes, so they hex-edited the EXEs and replaced the "goobers" string with spaces. The "goobers" string was later restored, while for a limited time period, the covered versions were promoted as "v1.4g". The included EXEs were still exactly the same as in the initial "v1.4" releases, though.

Later, id Software moved on to different publishers. The version number shown in the sign-on screen is still "v1.4". There are two separate EXEs made for GT Interactive. There's also one which is the same as the first GT EXE, except for the GT logo being replaced with another copy of the id Software logo. Additionally, there's a Japanese localization made for Imagineer. Finally, the last known DOS build that I'm aware of was made for Activision.

A significant way in which Apogee v1.4 differs from the later non-Apogee releases is in the VGAGRAPH data. In particular, just like SOD, the non-Apogee releases differing from Imagineer's lack the "Read This!" text screens accessible from the menu. The Imagineer one is using pictures instead of pages with textual contents.

Furthermore, again like SOD, during gameplay, the F1 key is used as a so-called "boss key" instead of letting you check the "Read This!" pages (for the versions which lack these).

From what I know, B.J.'s animation not playing in the "LevelCompleted" screen is a game data bug which was introduced with a later GT release that is using the second GT EXE. This bug is also present in the Activision version of Wolf3D, but not of SOD.

Other few differences in between later versions in terms of code:
- Versions of Wolf3D preceding the one with the later GT EXE still show the "CODE" column in the high scores table.
- The Imagineer and Activision versions of Wolf3D, as well as the Activision version of SOD, don't show a textual screen after quitting.
- Even the versions of Wolf3D that lack "Read This!" still need some of the code in wl_text.c for the end screens, unlike SOD. However, I think that when the Activision build of SOD was made, the Wolf3D project was copied and then modified, instead of using an older SOD project. As a side-effect, we_text.c code was probably included in a released SOD exe for the first time. My guess is that it turned out that wl_text.c has code for caching and drawing "Read This!" screen borders, which leaded to compilation errors for SOD, so it was disabled or removed. The same was also done for the Activision version of Wolf3D, because these borders aren't practically in use in the end screens.

[NY00123]

I'm ready to announce another release. It introduces saved games support to Wolf3D. They should be written in the same binary formats as the matching DOS versions. On the other hand, due to the nature of the implementation, there may still be bugs.

I also fixed a bug which, unfortunately, may break (partial) compatibility with Keen Dreams and Catacombs saved games. Then again, such compatibility was probably already broken in the same manner with the matching DOS versions.

Dec 25, 2020 (v0.32.0):

* KDreams, Catacombs (and Wolf3D): Make it possible
to bind actions to a game controller's D-pad.
* Wolf3D: Support game controllers, in a similar manner to
what's already been covered for Keen Dreams and the Catacombs.
Further add mappings for touch input.
* Wolf3D: Support stereo panning. This might not be fully accurate,
but hopefully, it's not that far.
* Wolf3D: Support saved games. They should be read and written using the same
formats as the original DOS versions. This may currently be buggy by nature.
* SD_TimeCountWaitFromSrc/SD_TimeCountWaitForDest timing fix, applying to
all games, but especially noticeable while playing back demos in Wolf3D.
* Add support for Spear of Destiny FormGen version 1.0, as well as the
variation of FormGen version 1.4 which is actually identified as "V1.4"
in-game. Currently, the one mistakenly identified as "V1.0" won't be detected.
The mission packs' data still needs to be the same as in the
Activision version, thus e.g., including the UAC logs.
* When game installations are shown in the launcher, don't print their
locations for now. This might become more useful later, in case it will
be possible to choose any of multiple game installations which otherwise
match the same version (e.g., due to somewhat differing game data).
It shouldn't matter as much for now.
* A change that may potentially break saved games made
with older versions of the KDreams and Catacombs ports:
The macros COMPAT_OBJ_CONVERT_OBJ_PTR_TO_DOS_PTR and
COMPAT_OBJ_CONVERT_DOS_PTR_TO_OBJ_PTR were fixed. The original sizes
of the object structs, as present in the DOS executables from the 90s,
are now used, instead of sizeof(objtype) from the source ports.
* Other misc. fixes and modifications. Thanks to Blzut3 for
assistance with a subset of the changes in this version.

[NY00123]

So, a maintenance release is now available. It should fix a few issues related to the use of game controllers, including a possible crash. If you're using SDL 2.0.14, you can also use the Xbox Elite controller's paddles.

Additionally, thanks to Blzut3, you may now download macOS binaries.

A change log is given later in this post.

One question that may be asked is what's the status of Android support. After all, the last release for Android preceded support for Wolf3D, thus Keen Dreams and the 3D Catacombs are the only covered games.

Thing is, the launcher and game controller support were a preparation for the Android port, at least partially. Later, it also involved adding general support for multi-touch input, preparing an Android project, and more. At the last, SDL2's Android port was already doing most of the important work, including a piece of Java code which is used in conjunction with Reflection Keen's and SDL2's C code. Still, work had to be done.

As of now, with the priority being lower, the work required for bringing Android support back will greatly involve the build system. I already migrated from Ant to Gradle back in 2019. This broke again after I transitioned from custom makefiles to CMake for the other platforms. In theory, using CMake and SDL2 altogether might actually make it easier to build for Android. However, there's still the issue that I have not just one, but multiple Android apps / activities to build (Keen Dreams, Catacombs, Wolfenstein 3D). Also, the general preference of mine, if Android support is ever resurrected, is to build shared SDL2 and Java code just once if possible. I don't know if there's a good way to do so while going through build system changes, though.

Jun 06, 2021 (v0.32.1):

* Redistributable application bundles can now be built for macOS with CMake.
(Thanks to Blzut3 for this addition.)
* Fix a possible crash, reproduced while binding an in-game action
to a controller button in the launcher with SDL 2.0.14 (thanks chungy).
This was a side-effect of an increase of SDL_CONTROLLER_BUTTON_MAX's value.
* More generally, mentions of enumerated controller buttons and axes
from SDL2 were replaced with equivalents defined in be_st.h. A few
related range checks were further added.
* The Xbox Elite controller's paddles can now be used as an additional
alternative to buttons, in case SDL 2.0.14 or compatible is used.
* Fix a significant usability problem with game controllers. When an
axis' value changes sign, a proper "release" notification should now
be sent for the original sign. Previously, the user could unexpectedly
get stuck in a specific state, like a continuously rotating protagonist.

[NY00123]

Version 0.33.0 is now available. Among other things, it has changes and additions related to compatibility (including limited forms of Vanilla Bug emulations).

Users of game controllers (via the "modern" controller scheme) should further pay attention, as other than one bug fix, there were technical changes related to internal game-specific key bindings.

Aug 02, 2021 (v0.33.0):

* Additional restructurings of game-agnostic code.
* Nuked OPL3 is updated to the last revision.
* Keen Dreams: Try to fix memory allocation problems
while using the data from the 2015 port.
* Keen Dreams, 3D Catacombs: For an uncached map, if the map header offset
being read is nonnegative but smaller than 8, just quit with an appropriate
error message. This fixes behaviors which greatly depend on the memory layout,
including a possible hang.
* Catacomb Abyss: Make it possible to warp to map 19, at least in general.
Also fix crashes upon attempts to load map 20 or 21 by
outputting a new error message.
* 3D Catacombs, Wolfenstein 3D: Add a "novert" toggle, letting the user
limit in-game mouse movements for turning/moving left and right.
* Wolfenstein 3D: Add a "lowfps" toggle, used for explicitly lowering the
frame rate. The purpose of this is controlling, to an extent, how far can
pushwalls move. Reason is, they were intended to move for 2 tiles, but
it turned out that they could move for 3 tiles as computers were
becoming faster. The Fake Hitler's fireballs also turned out
to move slower while the frame rate was higher.
* Wolfenstein 3D: Emulate, to an extent, the consequences of a
buffer overflow that follows a press on a pushwall while it's moving.
This is basically a Vanilla Bug, in which such walls are operated as if
they were doors, and unintentional changes to static objects may occur.
* Wolfenstein 3D: Upon trying to load a non-existent level
(say, in the March 1992 prototype), just report that the map isn't 64*64.
This is mostly similar to the outputs of the original executables,
while skipping potential undefined behaviors.
* Wolfenstein 3D: Fix menu navigation with the mouse while using a window.
* Change the way controller buttons get mapped under
the modern controller scheme. Basically, rather than parsing
the game's own configuration of keys and then using it as a base
for the mappings, just use the game's default bindings internally.
For instance, if a button was previously configured to be mapped
to "Jump" in Keen Dreams, it'll now map to the Ctrl key instead.
* Note that such buttons may internally get mapped to mouse buttons
instead of keyboard keys, in case "Motion emulation mode" is set to
"Mouse". The behaviors should remain unmodified in such a case.
* Further note that the above-mentioned changes impact
touch input, albeit the UI remains as-is.
* Amend controller usability fix from v0.32.1 to work better
when the setting "Motion Emulation Mode" is set to "Mouse".
* Add REFKEEN-NOTES.txt files to the source tree, describing technical changes
from the original versions of games, including cases in which such changes
exist for the purpose of emulating vanilla bugs. The information was
collected by looking for mentions of the word REFKEEN in the sources.
* Other miscellaneous fixes.

[NY00123]

Version 0.33.1 is now available. You may find it being called the "Loud Edition", if only due to default sound volumes being higher by default. This was a side-effect of a bug fix related to audio mixing.

Additionally, hopefully more accurate emulation of stereo panning should be available, based on information from a VOGONS forums post of James-F. I also added per-device volume controls.

Note that the volume controls are currently usable just before selecting a game to play (e.g., from the launcher), and not during gameplay. They're also done per-device, meaning, for instance, that you cannot separate the OPL music and sound volumes in Catacomb 3-D or Wolfenstein 3D.

A good question is if this follows Chocolate Doom well. I think it's a bit difficult to make a comparison, as Doom already provided its own in-game volume controls.

To explain why I think the added feature is acceptable for the Reflection Keen ports:
- First of all, most chances are the PC Speaker was really a separate device in the 90s. At least in theory, it could also have its own volume control.
- With the SB Pro and SB 16 (ISA) cards, you got a mixer in which you could control the volumes of OPL/FM/MIDI sounds/music and digitized sounds separately. If you asked Wolf3D to not detect an SB Pro, they would still be in effect.
- Otherwise, Wolf3D would tamper with these, basically setting the FM/MIDI volume to the max and changing digitized sounds' volumes for stereo panning. But tests done by Blzut3 showed to me that for Win9x, you could temporarily leave to the mixer program on Windows, change the FM/MIDI volume and then return to the game. Of course, this may have unexpected consequences related to stability, but it's probably expected.
- Even if the above weren't an option, someone probably used a sound card with volume controls independent of the ones that Wolf3D tampers with. Alternatively, maybe you could even use two separate cards: One for digitize sounds and another one for FM synthesis.

Aug 24, 2021 (v0.33.1):
* Identified as "Loud Edition" in-game, since changes related to audio mixing
increased the default sound volumes, at least outside of the PC Speaker.
* Nuked OPL3 is now at git revision bb5c8d08a85779c42b75c79d7b84f365a1b93b66.
* Introduce slider UI for a few launcher settings.
* Add a new Sound Blaster emulation option, currently relevant just for Wolf3D.
Use SB for mono output, and SB Pro or SB 16 for stereo panning of
digitized sounds. Note that it's more significant after choosing SB 16.
* Volumes for SB stereo panning, and internally also for OPL emulation
with relation to the SB Pro/16, are based on tables of dB values
posted here by James-F: https://www.vogons.org/viewtopic.php?t=54269
* Add user-accessible per-device volume controls, independent of what was
described earlier (e.g., Wolf3D's stereo panning). Note that these volumes
are configurable per-device.
* In particular, you cannot separate the OPL (AdLib) volumes
of music and sound effects in Catacomb 3-D or Wolfenstein 3D.
* Also, before playing Keen Dreams using the data from the 2015 port,
you should use the digitized sound volume slider. Reason is that
the sound effects were re-recorded into digitized forms.
* Balance the default PC Speaker volume, following the changes.
* Fix a sound mixing bug. Previously, the more sound sources were added to
the mixer, the quieter each of them would be in the mixed output. Instead
of taking the average of the sources, take the sum and clamp the result.
* Other miscellaneous changes.

[NY00123]

Hi,

As it should be known by now, Keen Dreams isn't the only game supported by Reflection Keen. Therefore, after close to 7 years, the project is being renamed. It's expected to be titled "ReflectionHLE" as of the following release.

Individual source ports might still be referred to as they have been, say "Reflection Keen Dreams". Additionally, the application icon will remain mostly the same. The main change will be the removal of the alphanumeric characters identifying the game, as a single executable is expected to support all games now. Given that they were all released under GPL-compatible terms, this should be feasible.

[MrFlibble]

Good idea, I guess quite a few people might get confused when being suggested "Reflection Keen" as a source port for Wolf3D or The Catacomb Abyss.

[NY00123]

Version 0.40.0 has been released. Since Keen Dreams isn't the only supported game, the project is being renamed as of this version. It's now titled "ReflectionHLE".

A side-effect of this is that you'll have to manually migrate saved games and settings. Hopefully, it shouldn't be more than copying a directory or two. See the top of the change log for details.

This version has the experimental addition of keyboard and mouse button overrides. They might not always work as expected. For instance, overridden keys may become unusable for cheat codes.

There's also an APK for Android again. Audio resampling isn't included in it, and there might be other problems related to audio. Generally speaking, the Android builds should be considered less supported.

Dec 31, 2021 (v0.40.0):

The project is renamed "ReflectionHLE" as of this version.
As a side-effect, users of earlier Reflection Keen versions will have to
manually migrate older settings and saved games. See paths given below.

Windows: %APPDATA%\reflection-keen => %APPDATA%\reflectionhle

macOS: ~/Library/Application Support/reflection-keen
=> ~/Library/Application Support/reflectionhle

Linux - two paths (assuming $XDG_CONFIG_HOME and $XDG_DATA_HOME aren't set):
~/.config/reflection-keen => ~/.config/reflectionhle
~/.local/share/reflection-keen => ~/.local/share/reflectionhle

* The project was renamed from "Reflection Keen" to "ReflectionHLE".
* A single executable can now be used for running the supported games.
It is identified as "ReflectionHLE".
* Due to using one exe, the application icon had its game identifiers removed.
* Additionally, the cfg file was split, with game-specific settings residing
in their own separate cfg files. Some cfg key and value names were further
renamed. Code was added for automatic migration of these from v0.33.1, but
this does not cover the directories which store the cfg files and saved games.
* The command-line options -skipintro and -showslides were removed. Instead,
you can show the intro or slides with sub-gamever selection via -gamever.
* Added the command-line option -listgamevers. It can be used for listing
supported game versions, instead of -?, which doesn't do so anymore.
* There's now experimental support for keyboard and mouse button overrides,
applying to in-game actions during gameplay.
* Note that these take a higher priority than in-game settings for the
same keys. They also have a higher priority than hardcoded behaviors of them.
For instance, it might be impossible to use a cheat code. You can still
use a cheat code via the on-screen debug keys, though.
* The on-screen keyboard with debug keys can now be displayed even
if there's no use of touch input or any game controller.
* Revert the impact of changes from v0.33.0 to the way controller buttons
get mapped under the modern controller scheme. Instead of mapping to the
default settings of a game, mapping is now done to the matching actions.
For instance, in Keen Dreams, you can map a button to Jump instead
of Ctrl (the default key for jumping in the original releases).
This is still done in a different manner from versions preceding 0.33.0,
as it's now less tied to the original games' keyboard settings.
* As a side-effect, there are changes to the impacts of the analog motion
toggles, even while using a D-pad. Additionally, the novert toggle should
also impact vertical motion from a game controller or touch input.
* Catacomb Abyss: Ensure it's possible to scroll through HELP.TXT using a game
controller or touch input, even if movement keys were changed in config.abs.
* General restructuring of the launcher's menus, following the support for
multiple games from a single exe and the addition of key/button overrides.
* Android builds are now possible again, albeit without audio resampling.
Generally speaking, these builds should be considered less supported.
* For technical reasons, sound output is done somewhat differently on Android.
There may still be problems with audio, including delays.
* Improvements to timing of sound playback during the intermission screen
in Wolfenstein 3D, Spear of Destiny and Super 3-D Noah's Ark. This
might be more noticeable while VSync is toggled on.
* Launcher control bindings for Wolfenstein 3D and Super 3-D Noah's Ark:
The weapons/feeders are now referred to by their numbers,
instead of game-specific descriptions.
* Emulation of mouse motion via game controllers was made
less frame rate dependent.
* Fix a typo impacting startup of Catacomb Apocalypse's hint book. The offset
of a textual screen as present in the original exe was wrong. The bug was
introduced during a refactor after the release of v0.30.1.
This screen is actually used just in the electronic catalog of the supported
shareware version of Catacomb Abyss, upon trying to print the catalog.
* Catacombs, Wolf3D: Fix building in case "char" is an unsigned type.
* Additional miscellaneous refactors, edits and fixes.

[NY00123]

Version 0.40.1 has been released. This update mostly consists of usability improvements. Also, for people less familiar with ReflectionHLE, a web page is now up: https://reflectionhle.com/

This release will hopefully resolve usability problems with keyboard overrides, and possibly also with other input devices. But there are great chances that there's a new bug not found by me, so bug reports will be welcome. You can use the GitHub repository's issue tracker, or report in the forums if you prefer so; Albeit I might not necessarily check all forums in which I posted about ReflectionHLE.

If you are upgrading from a version preceding 0.40.0, please check
migration notes for v0.40.0. The project was renamed to "ReflectionHLE"
at the time, and as a side-effect, older settings and saved games
have to be manually migrated.

Oct 14, 2022 (v0.40.1):

* Add a toggle for showing/hiding the ENDOOM screen on exit,
currently identified in the launcher as "Wait for input on exit".
Regardless of the toggle, it'll still appear in case of a nonzero exit code.
Other screens specific to shareware versions of certain games might
further keep appearing, or introduce their own delays.
* Updated search paths for Wolfenstein 3D and Spear of Destiny game data.
* Keyboard overrides don't fully replace the original uses of the keys
as of this version. For instance, if the launcher is used to select
the key W for moving forward in Catacomb 3-D, it can still be used
as a part of debug keys for warping to another level.
On the other hand, the familiar functionality of the key otherwise used
for the same in-game action will be disabled. To clarify for the example
of moving forward, the key generally used for this purpose from
Catacomb 3-D's own control panel (the Up arrow by default)
will not actually be used for moving forward.
Note that mouse button overrides are still full overrides and there's
no change in behaviors as describe above.
* Miscellaneous internal changes related to user input, related in part to
keyboard overrides. One example is a bug fix, where pressing on a key
moving Keen left, followed by another key moving Keen right, and then
releasing one of the keys, would make Keen stop moving altogether.
Also, as of this version, the analog motion is explicitly reserved for analog
controller axes; novert impacts these, as well as ordinary mouse movement.
* Use more locks for the audio mixer. This particularly
helped resolving unexpected slowdowns in Android builds
with BE_ST_MANAGE_INT_CALLS_SEPARATELY_FROM_AUDIO=1,
during playback of digitized sounds in Wolf3D.
* BE_ST_MANAGE_INT_CALLS_SEPARATELY_FROM_AUDIO=1 is used for Android again.
* Other updates related to Android builds.
* Made a few changes removing dependencies on libgcc and C++ libraries
as long as we don't actually need any of them.
* Other miscellaneous edits.

[Phredreeke]

Any chance of supporting the Capstone games in the future?

[NY00123]

Thanks for showing interest in the project!

Phredreeke, on 14 October 2022 - 12:30 PM, said:

Any chance of supporting the Capstone games in the future?

As usual for me, I prefer to not make promises regarding future plans for any (hobby) project like this. There's also the fact that from what I know, these games weren't open-sourced by any owner of them, and I'm also further unaware of an owner showing support for efforts based on reverse-engineering. So, at least in ReflectionHLE, I prefer to refrain from that. I still made exceptions for earlier versions of properly open-sourced games (e.g., Wolf3D) or greatly related code.

What I do know that's missing is proper support for loading user-made add-ons, say level packs. This excludes modifications which change executables like WOLF3D.EXE.
Actually, ReflectionHLE has a hidden undocumented toggle that lets you load different data, but it isn't well-supported and is quite untested.

Out of the supported games, loading add-ons as described here is probably most relevant for Wolf3D/SOD. I'll still want the support to be game-agonstic, as much as it can, if I implement it. I guess that specifying a folder for loading data is a possibility, and maybe also a ZIP file and/or a subdirectory within a ZIP.

Other cases might need more game-specific solutions, and I can't say anything else about them. The Wolfenstein 3D Super Upgrades, for instance, has custom levels in wolf3dsu.zip -> WOLFM.EXE -> ALLGAMES.LHZ. The levels are given by pairs of GAMEMAPS and MAPHEAD files with different file extensions, if I'm not wrong, and I don't know if I missed anything.

Additionally, I don't know if any example like the following one exists for Wolfenstein 3D, but the legacy 3D Realms website has a collection of Blake Stone user levels available as separate .FLR files. Instead of providing full modified MAPTEMP/MAPHEAD files, you need to have the originals and modify them by importing the levels with MapEdit.

[Phredreeke]

I thought Corridor 7 and Operation Body Count had the same publisher as the Witchaven games (which was bundled with ports made with Les Bird's source release) but turns out they're published by Ziggurat, and I have no idea where they stand on that matter.

[NY00123]

Now, there might not be much to add; Mainly a few notes related to known issues with detection of game data in the last October 2022 release, plus a short visit to what was essentially the very beginning of ReflectionHLE.

While ReflectionHLE's first released version, initially titled "Chocolate Keen Dreams", dates September 26 2014 and supports just Keen Dreams, I actually did some early work before Keen Dreams was open-sourced. June 2014 had the open-source release of the Catacomb games (plus Hovertank). Following that, I did some initial work with the Catacomb 3-D codebase, emphasis on code expected to be useful for a Keen game (at least with CGA graphics).

It wasn't possible to make a working executable. It actually occurred more than once while working on a new port of a game, that the process of porting would be done without observing if there's any mistake in runtime before finally getting to the stage of creating an executable. In particular, I don't recall creating a small test game for DOS as a reference.

I had already uploaded a repository with a kind of a (possibly modified) snapshot of such code back in 2014, but as of today, I took 3 old folders and created archives out of them. I also created a new repository, so you may check them out: https://github.com/R...protos/releases

Referring to the aforementioned issues in the last release:
- It might fail to auto-detect game data from a GOG.com release of Wolfenstein 3D if it's a "recent" download, which may potentially refer to any time from January 2023 and later (and possibly also earlier). Due to lacking a GOG.com copy of my own, I tried asking a few other people and filled details based on what I learnt. It turned out I used the wrong id somewhere (possibly a store id). It was only by January 2 2023 when I added a commit with the fix. While not fixed in the last 2022 release, you should be able to manually locate game data via ReflectionHLE's launcher.
- If you use Android 11 or later then ReflectionHLE might fail to access compatible game data, even if you enable all permissions that you can. I recall discovering this sometime during last year, after changing to a newer device. Another user reported the problem on GitHub, recently. As suspected by me, that's related to Android's 11 introduction of scoped storage. Since I haven't distributed ReflectionHLE via an online store, I've simply made it depend on a permission to manage storage, usually reserved for specific apps. A test APK can be downloaded, albeit as usual, consider this to be less supported: https://github.com/R...onHLE/issues/20

[NY00123]

So, it should be the 10th anniversary of ReflectionHLE's first release. Hence, there's an updated version now. There's one new feature, at least for Wolfenstein 3D and derived games. Basically, you may load modified game assets! That includes map sets and other modifications that change just game data files. Note that for Spear of Destiny (including the mission packs), ReflectionHLE expects the file extension of .SOD to be used. Further note that certain contents won't necessarily behave the same as with matching DOS versions, or even lead to crashes, due to changing memory in unintended manners. A good example is the map set Temporary Insanity.

This is also an opportunity for writing more here, including the question of the future of ReflectionHLE and other ports inspired by Chocolate Doom.

1. First of all, when it comes to ReflectionHLE and other projects, I've often had a tendency to not make promises before releases. In that sense, there's no significant change here. What I'm adding here is that generally speaking, there are various things that someone might want to do while time is limited, even if there is presumably a lot of free time.

Hence, it might not imply I won't ever add anything to the repository itself, but as far as it comes to ReflectionHLE, consider priorities to be elsewhere. While the following person similarly has other priorities, Blzut3 still has repository access. It was originally granted to Blzut3 in order to publish packages for macOS.

Other people might have a look at the code as they could beforehand; Maybe also work on their own forks. They might find it much more convenient for them to remove the launcher code, and potentially also other UI code (as intended for use with game controllers and touch input).

2. The ReflectionHLE website was an attempt suggested to me at some point. As expected, though, ReflectionHLE doesn't have enough audience that I'm aware of, given what has been covered so far.

3. One more general question is, to what level are Chocolate Doom and inspired source ports useful. After all, it's true that these days, if I try a game originally released for DOS for the first time, I might prefer using an original DOS executable initially (before using a source port). Even Chocolate Doom has its differences from Vanilla Doom v1.9 if one knows where to find them. One good example is the use of a GPL-compatible replacement for the DMX sound library. DOS emulation also makes it easier to play old versions of games, possibly including prototype versions.

And yet, projects like Chocolate Doom still have their uses. Just for some examples:
- Adding quality-of-life improvements that might be more difficult to implement, or less convenient to do, with DOS emulation. Examples are improved support for game controllers and WAD merging.
- Depending on how are things coded, ports like Chocolate Doom might make the computer consume less energy than using a DOS emulator.
- Both of the aforementioned points might be even more important when used with mobile devices and operating systems, operated via multi-touch screens.
- To different extents, the codebases of projects like Chocolate Doom might prove to be useful as a reference for other people, including developers of different source ports. Examples being making it easier to understand code originally being lower-level, as well as making an executable with debug symbols in a way that's more familiar than doing the same with a DOS executable.

4. I'll finish with something which is less about ReflectionHLE as a project, and more about Commander Keen, even if I generally didn't get to work on CK-related projects in the last 4 years (outside of exceptions like ReflectionHLE). Yes, multiple Commander Keen games were reverse-engineered. Yes, entities don't have to make source codes available if there's no contractual or legal obligation, generally speaking.

And yet, I'll still bring past (and present) interest in original sources for Commander Keen 1-6 (or at least, 1-5). The sources are known to exist and, about 10-11 years ago, there was an attempt to get them released. It started with a find of Keen 4-6 sources about 11 years ago, followed up by some work about 6 months later that included code reviewing and figuring out how to make working binaries. Access to Keen 1-3 sources were also gained around that time period. Eventually, though, the release had never occurred, even if there was presumably a kind of an approval earlier.

I don't know if the current situation may lead to a change, but still checking. Other products of at least one related company (think of an old operating system) were open-sourced. So was the game code for the 2023 rerelease of Quake II.

[NY00123]

Since my preceding post has been, well, long, I've thought of adding a summary with a list of shorter sentences/paragraphs, along with a few more details:

1. As stated earlier, the last 10th anniversary release introduced an addition mainly beneficial for Wolfenstein 3D and derived games; Namely, the ability to load game modifications not depending on executable changes, including map sets.

2. Also, less than 2 days since the release, Blzut3 uploaded macOS binaries, available from the usual location on GitHub.

3. I decided to add that, while it does not necessarily mean I won't ever add more to ReflectionHLE, my priorities are essentially elsewhere these days.

4. One thing I hoped doing in the past, was transforming ReflectionHLE into a kind of a general framework for Chocolate Doom inspired ports. In practice, it might not exactly be ready (e.g., no proper API and partially inconsistent function naming), but it should still be possible to implement support for other games if anyone wants to.

5. Of course, ReflectionHLE might still be missing features required for other games that people might want to port. One example is MIDI playback, at least for games not necessarily using their own built-in synthesizers or conversion routines.

6. People might still look at the code, as they could earlier; Maybe also start a fork. Chances are they'll want to remove the launcher code, and maybe also other kinds of UI code.

7. Also, people might get ideas from the ReflectionHLE codebase, but good chances are they'll find it easier to reimplement the ideas differently. Maybe not always, but at least on specific occasions (especially the launcher).

8. For one small example, I defined platform-agnostic integer types, like "id0_long" for 32-bit integers, albeit they're game-specific and not a part of the ReflectionHLE backend. For another example, I made use of gamesrc-ver-recreation/wolf3d in order to support multiple versions of Wolfenstein 3D. However, the way macros added by me (like GAMEVER_WOLFREV) assisted can make code harder to read. Then again, there might be no universal solution for this, and the work should probably be done on a game-by-game basis, either way.

9. As brought up earlier, one question is to what level are source ports like Chocolate Doom relevant when you may play the games via DOS emulation, especially more specific versions of them. The answer is that they still bring their benefits. A list of examples is given in my preceding post.

10. Finally, less about ReflectionHLE and more about Commander Keen: While my interests in general have maybe changed over times, my preceding post reminded past (and present) interest in original sources for Commander Keen games. There's indeed no obligation to release them, but there was a past attempt about 10 years ago that seemed to get close. I don't have an answer to this, but maybe the conditions have changed in the last few years, increasing the chances in case of a recheck.