Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited


About NY00123

  • Rank
    Green Marine

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. I'll first begin with a small bit that I forgot to mention earlier: The versions which I previously named HEXDM10A and HEXDM10B in the hexen repository were renamed HEXDEMOA and HEXDEMOB, respectively. The retail store beta is identified as HEXRBETA, and the 3-level shareware demo of Heretic is TICSBETA. The rest remain unchanged. Great to see that all of these worked as expected! Thanks for testing. Now, if anything differs in behaviors, on the other hand... Well, as there are differences in the recreated EXE (like global variables having a different order), this is expected, especially in cases where the exact EXE layout matters, like buffer overflows. What I mean with these 3 functions is that you'll find differences if you make your own exe (even with DMX), and then compare the generated code to the original, side-by-side; Maybe these differences don't have an impact on the functions' behaviors, but this is still what I saw. Regarding the fly, while it might be missing from the early demo's maps, you can still find code and data for it, including sprite graphics. However, as they're quite small (around 2x2 pixels), it can be easy to mistake them for placeholders. In particular, I assumed that there are larger sprites in the retail store beta, but it doesn't seem to be the case. Of course, this assumes that the sprites were actually intended for use, and weren't placeholders. One thing I can say for sure, is that the small size of them can make it difficult to view them in certain programs, since they can make the sprite images look blurry. You're welcome! I can probably wish you good luck with your endeavor, heh. That's interesting. I don't recall myself using Kali.net in the last 10 years, and especially not staying in a descent channel. It was probably about 20 years ago when I tried to use it for Duke Nukem 3D, in a kind of a demo/trial mode. All that I remember is one attempt to join a session, for which a game launch probably failed, heh.
  3. So, it's possible that anybody who tries to cover all versions from a single EXE might find it difficult to do so at this point. That is, unless you go for what I did in Reflection Wolfenstein 3D, as it more-or-less covers separate builds of different game versions in a single exe. As of this post, the following additions are now in: - 3-level shareware beta of Heretic (Dec 20 1994). - Retail store beta of Hexen (Sep 26 1995). These will probably be the last additions related to Heretic and Hexen. As usual, there's no promise regarding any future endeavor. To summarize, we ended with 5 distinct DOS builds of Heretic, and 7 of Hexen. As I suspected, it still took significantly more time to work on the beta release of the 4-level Hexen demo (given preceding work on v1.0 and the demo re-release), compared to the work on the aforementioned two betas of Heretic and Hexen. In certain technical manners, the two Hexen betas might be close, even if obviously not identical. The aforementioned removed fly code is the same, just for one example. I did have issues with the generated layouts of the following functions in the Hexen betas again: A_Quake, P_XYMovement and P_ZMovement. As mentioned earlier, the latter's C code was actually not changed by me at all. In the case of Heretic, I suddenly spotted a different layout for M_FindResponseFile in a recent build of 1.2. I did it see beforehand, also in Hexen, but I thought that it was not reproduced after I finished working on each of the differing Heretic versions, excluding the beta. At the least, the code size, including padding for alignment, remained the same, so the other functions did match in layouts and locations. To finish, I've attached an archive consisting of new builds of all covered versions, again using the Apogee Sound System wrapper instead of DMX. https://bitbucket.org/gamesrc-ver-recreation/audiolib/src/ad045a8d066d4f806b73b008afa134aabd3ac973/ https://bitbucket.org/gamesrc-ver-recreation/apodmx/src/848d85cd2015b7df0b3dbd26e3be3da429282786/ https://bitbucket.org/gamesrc-ver-recreation/heretic/src/9e456d7e201aee5f067314c2c44fa6ca57ced83f/ https://bitbucket.org/gamesrc-ver-recreation/hexen/src/1847583de60fdfe66476c30746740f0a6aa11dca/ STRIPTICHEX_20210521.7Z
  4. Hey there, I've gotten another addition for the Hexen repository. To make this short, it should now cover code which is more-or-less fully equivalent in behaviors to the 4-level beta (Oct 2 1995). There's probably too much to write about the code itself, so I'll simply mention the following examples of information: - This revision has code for the removed fly creature (https://doomwiki.org/wiki/Fly). - The 4-level demo from Oct 18 1995, previously named HEXDMO10 in my repository, was renamed HEXDM10B, while the earlier demo was named HEXDM10A. - I considered renaming HEXDM10B back to HEXDMO10, while HEXDM10A would be renamed using (a subset of) the EXE's original modification date; Reason being, the latter is identified as a beta in-game, and I already did a similar thing with a Wolf3D proto. beforehand. - However, both versions are referred to as demos in the README.TXT files from 1995. I also don't currently recall any mention of a version number, like 1.0. For now, I just keep using the names of HEXDM10A and HEXDM10B. - I originally started to inspect the 4-level beta as a possibility after finishing with Heretic 1.0-1.2. I eventually returned to the beta more recently. What's clear is that it required more work to recreate the code than the previously covered versions of Hexen; Maybe even more than all previously covered versions of Heretic and Hexen, combined. - In addition to the previously known issue of global variables not being fully ordered as in the original EXE, there are also a few functions that I couldn't get their compiler-generated layouts to fully match. Unless I missed anything, they should still match in behaviors. The functions in question are A_Quake, P_XYMovement and P_ZMovement. The latter's C code was actually not changed by me at all. Following preceding interest, I'm attaching an archive with a build. As with the other builds, it's using APODMX, so expect it to sound different from the original. As usual, the actual Hexen code should still match, more-or-less. Given the use of GPLed code, I'll reference the relevant revisions again: https://bitbucket.org/gamesrc-ver-recreation/audiolib/src/ad045a8d066d4f806b73b008afa134aabd3ac973/ https://bitbucket.org/gamesrc-ver-recreation/apodmx/src/848d85cd2015b7df0b3dbd26e3be3da429282786/ https://bitbucket.org/gamesrc-ver-recreation/hexen/src/a53dad15370b86de58cabed95b80589a46b7c50b/ STRIPHEX_20210509.7Z
  5. Thanks for the interest in the ports! I've had a bit of chat with Blzut3 on my preceding post, emphasis on support for input devices. It's still early to say if anything will be changed, but I'll at least bring a possible suggestion. Right now, you can use the launcher to bind game controller buttons to in-game actions, like jumping in Keen Dreams. In practice, these buttons are actually mapped to the corresponding keys (as originally used under DOS). For jumping in Keen Dreams, this is "Ctrl" by default. If you change this key in Keen Dreams' control panel, the game controller mapping will be updated accordingly. As a side-effect, if you start Keen Dreams, change the jump key to "F1", then start a game and press on a game controller button mapped to jumping, chances are you'll see the help sections instead. Thus, the suggested change was to simply map game controller buttons to very specific keys. For instance, instead of mapping a button to "Jump", it'll be mapped to "Ctrl". Of course, this means that the button will not be usable for jumping if you change the jump key the way it's originally done under DOS. I'm not entirely sure which option (currently used or suggested one) is better, or at least less confusing for the user, but the suggested one will be simpler to implement. One may similarly consider launcher-side keyboard overrides, so you can use e.g., keys that the game wouldn't even let you choose at all. There should probably be no such overrides at all by default.
  6. Thanks @Arno! Great to see that this brought you back to playing Wolf3D's first episode, initially even doing so the way you originally did in the early 90s. It's also good to see that you didn't encounter a bug. There's still the aforementioned vanilla bug related to pushwalls, not faithfully replicated at the moment. Vanilla Wolf3D indeed doesn't support concurrent use of a WASD keyboard layout and the mouse for turning. Something like DOSBox' mapper can let you assign separate keys for strafing, but Vanilla Wolf3D still doesn't let you turn and strafe concurrently. This might be a good chance to see if anybody has a comment on a bit technical topic. I can't say if I'll change anything, but right now, the way the ports handle user input has limitations. - Since the ports aim to be Chocolate Doom equivalents, it should be possible to use a keyboard and mouse in ways which behave more-or-less the same as under DOS. - For instance, when Wolf3D's IN_ClearKeysDown function is called, it should have the same effects as in the original exes. - Also, unlike Doom, the games Keen Dreams, Catacomb 3-D and Wolfenstein 3D let you select keyboard and mouse actions from the game itself. Question is how to make this work when you want to use a different input device, not originally supported in the 90s (at least not in the same manner). What I did for now was the following: - Some form of support was added for modern game controllers and touchscreens. When in use, what the game sees in practice is still the old-style keyboard and mouse events. - This works by translating uses of the input devices via internal mapping tables. The tables change according to context (e.g., menu navigation vs. general gameplay). Unfortunately, this approach has obvious disadvantages. Just for a few examples: - You cannot configure the keyboard in ways which the game didn't originally allow you to. In particular, you can't configure it at all for the Catacomb Adventure Series. - If you assigned the same key to two actions in the game's menus, each of the controller buttons mapped to one of these actions might also, in practice, trigger both actions. While originally adding the support to Keen Dreams, initially, I considered disabling the keyboard settings while a modern game controller is in use. However, I also wanted such controllers to be usable out of the box via hot-plugging, at least by default. Therefore, this eventually didn't look like an option to me. To finish, if you check any of the "altcontroller.c" files, currently present in the source ports and covering input mappings, you can see that - well - they aren't exactly simple txt or xml files which you may write in a short time. Obviously, describing locations of touch input controls without visual input is expected to be more difficult, but even if we ignore touch input, properly creating the mappings needs some work.
  7. Good to see that you figured out these two differences in rendering, and also that you fixed the visual differences in the status bar. Originally, I thought that the use of a different font for the numbers was intentional. I can see that this is actually the font used for words, textual descriptions and similar. Given your description of the differences in rendering, it sounds like it's doable to replicate the above-mentioned properties of the original renderer, at least up to some level; You basically just need to tell your renderer to position the player and in-game sprites a bit differently, using a bit of math. If you ever get to support loading of DOS-compatible saved games, you might consider working on such a renderer option as a challenge, just to see how close can you get things to look like for saved games.
  8. You're welcome! One thing I forgot to mention, is that in Catacomb 3-D's menus, pressing on Esc brings you back to the preceding menu. So, maybe it's better to follow these behaviors for the rest of the games, not just for consistency with Catacomb 3-D, but also since it seems to be a more common convention than Doom's. I also forgot to attach two screenshots for comparison. It looks like even with the minimal FOV of 25, CatacombGL shows a bit more. Of course, it's not intended to look exactly like the original (and especially not reproduce original glitches), but for the curious ones, I've attached these.
  9. 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.
  10. Great work as usual! The isometric map view is a nice addition, and it's not even the only possible appearance of the map. I don't know how difficult is it in the technical sense, but since the automap is now at least a bit more accessible, can it be optionally changed in Catacomb 3-D to not show where are destructible walls present? Additionally, as other non-vanilla changes are acceptable, following are a few additional suggestions (other than mouse navigation in the menus, which was acknowledged): - Skipping to a menu option by using a letter (mostly like Vanilla Cat3D/Wolf3D/Doom), or alternatively by using Page Up/Down or the mouse wheel. - Going back to the main menu from a different menu by using the Esc key (or possibly another mouse button). In Vanilla Doom, Esc is reserved for hiding the menu, while Backspace is used for showing the preceding menu, so I guess that's another option. - Add the overscan border, or at least a short screen flash for specific occasions. While the border can't be seen with a lot of modern DOS setups, including real DOS installations as well as DOSBox-based ones, it can be very useful for indicating when the player loses health. Such a border is drawn in my ports. I'll finish with a few bug reports, which should also be added as GitHub issues by me: - Using F10+W in Catacomb 3-D, level numbering is mistakenly started from 0 instead of 1. - Suppose that you press on F10+W in Catacomb 3-D, then press on "Esc" to go to the menu, and finally leave the menu. In such a case, you get the dialog again. If you then ask it to warp to the current level i.e., stay in the current one, you'll then be back to the game, but without music. - The same occurs if you display the automap, show the menu and then return to the game. Great work again.
  11. It's great to see that the recreated Heretic 1.0 sources have already become useful for someone. The way it's usually done, I prefer to not write much before I finish working on something, or at least get sufficiently close to such a state. As previously mentioned, doing the work covering Heretic and Hexen, but for Doom, is expected to be significantly more difficult, due to the lack of original DOS sources. There's also the question of DMX; So far I could use (for the purpose of creating EXEs) very specific versions of DMX header and library files, which turned out to be the same for all currently covered versions of Heretic and Hexen. At some point, I got word from Hendricks266 that Jaguar Doom might be a good reference. It is reportedly based on Doom v1.2, which Heretic is apparently also based on: https://doomwiki.org/wiki/Versions_of_Doom_and_Doom_II What Nuke.YKT remembered at the time is Linux Doom's headers being quite different. This can greatly have an impact on restoration efforts; Especially if you also want to get global variables (at least the ones in the BSS and not assigned specific values) to be ordered as expected. I didn't even get that sufficiently close with the older Hexen versions, albeit with the help of a script, I could at least find out that the recreated EXEs are still more-or-less the same as the originals, ignoring the order of variables. Back to Linux Doom's differing headers, consider DOOMDEF.H. It was originally larger, something which be observed by inspecting the Heretic and Jaguar Doom sources: https://github.com/OpenSourcedGames/Heretic/blob/1f4d3de8d639d62d52e7383f01acc1e81fc1b7f9/Heretic Source/DOOMDEF.H https://github.com/Arc0re/jaguardoom/blob/392d665438909aab8b8e28852a86f68c1797d619/doomdef.h For Linux Doom, a great deal of DOOMDEF.H's contents was moved out of it: https://github.com/id-Software/DOOM/blob/4eb368a960647c8cc82d721d0183629ae10759d1/linuxdoom-1.10/doomdef.h
  12. I'll first begin with a small bit which I forgot to mention earlier. When you made the October 30 reply following my post about additional Hexen versions, it was more-or-less when Hexen turned 25 (counting from the day of initial release). I checked at least one of the builds in DOSBox. It looks like another instance of the side-effects of using the Apogee Sound System instead of DMX. I recall briefly checking if I can adjust one of the volumes, but IIRC it reached the maximum. Unsure about the details, because the sound and music volumes can be controlled independently of each other, but this is what I recall. It might just be a lucky coincidence that STRIPTIC.EXE v1.0 didn't crash in your case. Generally, the global functions and variables present in the Heretic code base itself should be ordered in mostly the same manner with or without DMX, but there can be a greater impact, depending on various factors. I write "mostly", since if you replace even the original DMX.H header with an alternative, this can impact the order of global variables in OBJ files, due to the way the compiler works. On a side-note, I'm not even sure where to host this, so I'll just attach the file here. Basically, at some point, I decided to try and replicate the older behaviors of Hexen's A_SoAExplode function (i.e., reproducing the -nomonsters bug), but with modified ZScript code for GZDoom. I otherwise have no practical experience with ZScript at all; This is technically my first released ZScript (more like a modification), so the way it's packaged can be wrong in any way, but I'm still attaching it. hex11a.pk3.zip
  13. While I'm posting almost a month late about this, the first "Strife Forever" comic has been up since Nov 1st. It's the first out of a three part episode. The second part is expected to be published tomorrow (Dec 1st), followed by the third part on Jan 1st. The Strife Forever website and/or Discord can be checked for future updates as usual.
  14. Yeah, I noticed this as well while working on the code. I already found the the original EXEs to share a common file size, which was a very great hint, albeit I didn't think about episodes 4-5 as much; Then again, I'm not sufficiently familiar with Heretic to fully remember which EXEs were or weren't distributed with Shadow of the Serpent Riders. Since the added episodes didn't introduce new weapons or monsters, maybe almost all coding was done before a great deal of the mapping for episodes 4-5 was being conducted. To compare, following Doom Wiki pages, The Ultimate Doom was released on April 30, 1995, albeit its (most recent?) EXE was actually date-stamped 1995-05-25. I'm not sure what happened here. Either way - assuming this wasn't known in Raven beforehand - chances are that the release of The Ultimate Doom convinced them to similarly add more to Heretic, thus leading to the additional code in v1.2's EXE. Other than a really small amount of differences related to the addition of episode 4-5, v1.3 added to P_MAP.C a few pieces of code related to missiles. ok, so while I'm careful of making any promise as usual, I'm wondering which Heretic and Hexen executables are known? Ignoring Hexen95, these are the versions that I'm currently aware of: Heretic: - 3-level Shareware beta (1994-12-20) - Shareware v1.0 - Registered v1.0 - Shareware/Registered v1.2 (same exe) - Shadow of the Serpent Riders v1.3 Hexen: - Retail store beta (1995-09-26) - 4-level demo beta (1995-10-02) - v1.0 (1995-10-13) - v1.0 with added i_CDMusic check in P_SetupLevel (1995-10-15, but with VERSIONTEXT still defined to "FINAL 1.0 (10 13 95)") - Demo v1.0 (1995-10-18, but with VERSIONTEXT defined to "DEMO 10 16 95") - v1.1 (1996-03-12) - v1.1 with A_SoAExplode fix (1996-03-22)
  15. That's an interesting find. The SHRD sprites seem to be unused, even in v1.0. It seems to be the case, at least in the code. Since I'm not that familiar with Heretic/Hexen terminologies (e.g., monsters' names) again - and more generally - I'm just not aware of the unused code's purposes, I can simply write what I currently have for v1.0 regarding the Phoenix and more. P_PSPR.C: There are some code changes. P_RepositionMace was modified, and P_CloseWeapons also has in v1.0 code related to Maces; I'm wondering if these are the Firemace changes mentioned by PVS. There's the aforementioned function which I called A_Flash; And then, there's another unused function, which I called A_UnnamedPhoenixFunc, and it simply multiplies the actor's momz field by 2. INFO.H (v1.0): - The following states are present right after S_PHOENIXFXI1_8: S_PHOENIXUNKNOWN1, S_PHOENIXUNKNOWN2, S_PHOENIXUNKNOWN3. - S_PLAY_FDTH19 and S_PLAY_FDTH20 don't exist. - The following mobj type is present right after MT_PHOENIXFX1: MT_PHOENIXUNKNOWN INFO.C (v1.0): There's a full struct definition for MT_PHOENIXUNKNOWN and other differences in states, present here: You're welcome! That's interesting. So you can't open Bitbucket from this PC? I'm wondering if you can run another browser, and/or use a git client to download the sources instead. One of the shareware demos indeed has an instance of looking up, so it's obviously impacted. I did spot these couple of differences between G_GAME.C and an older version of it, G_OLD.C. It was probably before figuring out that I could use G_OLD.C as a base for v1.0. I also used D_NETBAK.C instead of D_NET.C. G_OLD.C (v1.0): if(lookheld < SLOWTURNTICS) { lspeed = 3; } else { lspeed = 5; } G_GAME.C (v1.2/1.3): if(lookheld < SLOWTURNTICS) { lspeed = 1; } else { lspeed = 2; }