Julia Nechaevskaya

Unfortunately, I have almost zero knowledge of MIDI code. Current MIDI implementation comes directly from Chocolate Doom where it was written by @ceski and @rfomin, so perhaps they can give an advice about this case? Or maybe even better to do such check in Chocolate Doom itself, as this case seems to be related to accurate emulation of DOS executable. I'm merging latest changes from Chocolate code base from time to time to keep everything in sync. And could you please provide a testing MIDI or WAD?

Maybe it is worth to try to generate composite textures while level precaching? An example from Crispy Doom may be handy. This should fix notable hicups upon first time entering areas with non-generated composites (notable example is computer room behind the first door on E1M1), but from another hand, this will require some extra memory and will increase level loading time.

Oh, it was available until 7.0 version, where I decided to be far more conservative with such features. I'll gladly explain why it didn't make a final cut: it's too big change in original game mechanics. Even if it will be guarded by "single player only" condition (i.e. not while demo recording/playback and not while multiplayer to prevent desyncs), it still can potentially break some game scenarios with monsters, which were made by design. Imagine, player have a group of monsters, placed in sector slightly below player's position. In vanilla mechanics it is impossible to run over monster's heads to skip this fight. By using this feature, however, it is possible to perform such trick. Please correct me if I'm wrong, but AFAIR none of existing compatibility levels are allowing such trick at all. There are still few compatibility-breaking features, though. Three ones in same named section in Gameplayer Features, plus three physical ones. All of them are guarded to be in "single player only" as described above, but Physical ones should be safe for common scenarios: Corpses sliding from ledges. Just a nice effect, comes from MBF. Preventing monster corpses to be stuck on ledges if only just a few pixels are placed on ledge. In some rare instances corpses starting to slide like on a ramp, but I made a time limitation for about ~15 second to prevent infinite sliding. Point-blank SSG tear monsters. Splat! But even teared (i.e. in x-death state) monster can still be resurrected by Arch-Vile or crushed by a door. Items are tossed when dropped. Dropped weapons and ammo clips from monsters will not appear on floor immediately, but fall "like from hands" instead. What does it means exactly? As about FluidSynth and GUS, I think I need to add an in-game tips if respective variables (fsynth_sf_path and gus_patch_path) are not set. This is especially important for FluidSynth, since there is no any SF banks included, and setup executable now acting as a multiplayer launcher, while FluidSynth itself is working just fine. Thanks!

Sure, here it is: inter-doom-7.3-pre1-win64.zip I don't use automated builds on GitHub, preferring to release exactly the same executable as I get using the MSYS build system and have everything under my own control. Not much has happened since 7.2.1, just mostly demo playback improvements and latest request. All changes are in "chages.txt" inside the archive.

So Doom is a direct fork of Crispy Doom, but ID is not, through a lot of Crispy energy is running through ID's veins. 🙂 I've seen mentions of "SSG in Doom 1" in Crispy code but never tried it. Thanks for the link! I'll have to investigate, this could be important for possible mods/TCs compatibility. Edit: done in commit 6b67a50.

FOV is done and it's based on both DOOM Retro and Nugget Doom (thanks, colleagues!). Changing kinda reminds me "that" cinematic effect, but please, do not expect any special effects like teleporter zoom and etc!

In fact, @Dasperal is now full-right owner of the previous codebase and the whole "Russian Doom" project itself. Not to leave things unsaid and prevent any father misunderstandings -- In the first half of 2023 I switched to full-time development of the CRL source port. There was no real plan, just an improvisation and thoughts about what kind of strict features and QoL improvements might be useful to make this port suitable not only for displaying render counters, but also for extending it for some additional game modes, error messages, play state counters and so on. Suitable for normal play as well. Here's how it looked like in the beginning (screenshot, does the menu look familiar?), the codebase was just a draft of Chocorenderlimits 2.0 left by RestlessRodent and barely adapted to SDL2 by myself back in 2018. Some time after the release of CRL 1.0, @esselfortium and other respected mappers came up with valuable suggestions that helped a lot to make this port even more useful. Sometime in March of 2023 I decided to take a fresh look at the old Inter-Doom (6.x) and found myself, let's just say, totally unhappy with its evolving state. The only reasonable solution besides "burn everything to hell and start over" was to give it away to @Dasperal, who helped me a lot and did a huge amount of code improvements at that moment - I just couldn't let myself destroy all his work. It's not just "work", it's a time of real life. And that's what happened. A few days later I decided to make a small-big experiment: to run Sunder MAP15 in CRL to take a look at the render counters in such a complex map, just out of pure interest - what kind of values will appear on visplanes etc. without engine optimizations? Support for such maps should not be done in original CRL, simply to not give false impressions like "okay, it can be run in CRL, then it can be run under Chocolate Doom and DOS version". So, a copy of the CRL codebase was made for such experiments, and the more code was changed just to load Sunder at all, the more inspiration came to reassemble Inter-Doom entirely. I decided to leave it's translation and resource dependent past behind and redo everything in a more conservative way, not with "features for features and fix all vanilla bugs", but with "actual code, demo and multiplayer compatibility". AFAIR, it took about two months to reassemble as well as review/rewrite my own code. After a huge amount of changes, not much code from CRL itself remained in Inter-Doom, except for the menu API and a few game modes. Nowadays both ports are mostly identical in the upper level code, which is mostly identical to the actual Chocolate Doom code. And believe me, this makes maintaining both CRL/Inter-Doom ports as easy as possible. Just a note: Sunder requires Boom-compatible engine, and both RD and ID are not such kind. But it's Map15 has been used a lot for benchmarking purposes, it's a true paragon for such cases. Guess, that's all the story. I'll principally left untold my tantrums about "I don't understand this, let's remove it!", but it's kinda fun to remember in retrospect. Finally, I can only wish only best with farther development of Russian Doom! But the only thing I'd like to ask is to don't make any farther posts or requests about RD in ID thread. Despite of being somewhat same in it's features, now it's a different ports with different aims, and once I left RD's code base, I haven't touched it all.

Quite interesting topic, have to admit. I'll add my two cents not from player's, but from technician/programmer's POV: "Quad" or "any" resolution: neat feature to have, but trust me, despite of giving nice view, it's... Voracious in the meaning of CPU resource usage. Technically, it is absolutely same to mid-res (2x), except with higher resolution multiplier and larger screen buffers for player view and status bar background. We have suffered absolutely same performance issue between Inter-Doom and friendly Nugget Doom port, and the best we can do in this case is to explain: "If your CPU handle this mode well, please use it. If not, please consider using middle resolution", and as @Alaux said before, support any possible resolutions, especially without performance penalties is not that easy. The cause of the problem lies not in mid/quad res code, it is in slightly different plane: we still have a single-thread process, which is using GPU just to scale picture and put it to the screen. Switching to hardware accelerated render could resolve performance issue entirely, but this is not that easy as well. Demo support. Demos are friends, not foes. While demos are fun to watch and record, they also helping a lot with automated tests. Funny enough, but the longer demo is, the more helpful it is for testing (notable example is six hours demo of Alien Vendetta by blue cultist). Another useful thing is "-timedemo" which is helping for performance benchmarking and engine stress-testing. Needles to say that demo support require untouched game mechanics, so... Game mechanics. As we are all know, there are a lot of small oversights in vanilla Doom, and nearly all of them are documented in DoomWiki. Fixing memory/visual/render oversights is okay, but touching anything related to play state is a direct way to possible demo desync. Yes, it is possible to guard such fixes with conditions like "not while demo recording, not while demo playing, not while multiplayer", but this will lead to another confusion: what if player expects to meet this bug in casual single player game? But uh-oh, it's unconditionally fixed. Having a dozens unclear micro-switches for any possible fix doesn't sound like a good idea at all. Boom/MBF/MBF21 support. A lot of modern projects using this specs, which are offering amazing things for gameplay, and it's really great. But porting this specs into engine from scratch is a huge challenge, which will require a lot of attention and patience, because even pure Boom is not just a couple of extra line specs, it is also changes in render code, support for custom COLORMAPs and so on. Command prompt hell. On Windows OS especially. Probably, this problem can't be solved entirely, but most of today's source ports are allowing to drag-n-drop files onto the executable. Programmer's coding experience. Especially if programming is time-to-time a hobby. That's the real problem of everything, speaking for myself.

Uh. I never tried to play Doom with different FOV, thinking it's more suitable for Quake series. Need to investigate, if it will not require a lot of changes in render code, then maybe it deserves a small menu item in Video Options. Meanwhile, I have done small extensions to demo playing code, so restarting and going to next level, as well as IDCLEVing to any level while demo playback is now possible. These are small changes, but some review is still needed, maybe there are some ways to make it more optimal. Real problem here is demo format itself: it's basically a record of player inputs. There are no markers or indicators like "on this tic player is pressing exit switch and going to next level", so to scroll demo previous level, engine must restart demo entirely and do a "fast-forward" that map by disabling screen rendering and running through the game tics as fast as possible. A bit "expensive" procedure, but even on Alien Vendetta six hour demo by blue cultist, it takes just a few seconds on my i7-12700F to jump from MAP01 to MAP30. Rewind could be even more awesome, but no, I will not handle it's implementation, it's too complicated for me. 🙂

International Doom 7.2.1 is out, this is a "little huge" maintenance release with no new features. Instead, the entire codebase has been diff-verified and updated to the latest Chocolate/Crispy Doom code - some parts of ID code were severely outdated, as ID 7.0 codebase was based on Chocolate Doom pre-3.0.0. This includes a number of fixes and stability improvements, including a fix for a possible random crash on game loading in some cases. Download: Windows (32-bit): inter-doom-7.2.1-win32.zip Windows (64-bit): inter-doom-7.2.1-win64.zip Changelog:

If you are seeking for knowledge/experience/self-realization in Doom programming, then no need to rush into such complicated concept at first place. Start from foundation basis, like hacking or experimenting with Chocolate Doom source code. Probably most easiest part and good starting point will be menu system. And again, don't rush. Seven years ago even menu system was something like rocket science for me (kindly quoting @fabian here), but everything comes with patience, interest, motivation, perseverance and sometimes fanaticism. Even programming is a kind of creativity, where you can do things absolutely different way, but anyways, it's not the thing that can be learned only by ambitions, wish or snap of fingers.

😱 Fixed, thank you! Links are same.

International Doom 7.2 is out! Possible random crashes while changing video settings and visplanes drawing has been finally fixed (no solid background or framerate capping needed, yay 🤩), as well as other improvements were made. Download: Windows (32-bit): inter-doom-7.2-win32.zip Windows (64-bit): inter-doom-7.2-win64.zip Changelog:

Thanks! Could you please try this build? It's in release-friendly condition and both Win-32/64 distributions are included, just in case. Changes are in changelog.txt: https://jnechaevsky.github.io/files/inter-doom-pre-7.2.zip Turns out, there were two notable problems, both should be fixed: Possible crash on toggling rendering resolution, explained by @Alaux. I've tried to fix it in 7.1 by capping framerate to 35 fps while in Video Options menu, and it seems to work on my side, but looks likes it wasn't optimal. Now there is a solid background and rendering of player view is disabled while in this menu. Not very nice, because now it is not possible to see changes immediately, but should work. Possible random crashes on visplanes drawing. My favorite blooper of trying to simplify the code, which is already working fine.

Thanks! Should be fixed now (r_plane.c section). Guess I have to make a small maintance release soon, there are couple of small improvement already.