Julia Nechaevskaya

I was caught in the act! 😳 Well, yep, that's true, Inter-Heretic is WIP for now. Working on true color support for Crispy Heretic gave me a huge boost of motivation and the story repeats, I have used CRL-Heretic as a base to go a full path again. True color, triple resolution and painless resolution toggling are also there. In general, it's done for about ~70%, but not all plans and features are done, not every my previously written function is reviewed/rewritten. Attention to details will be needed as well. My aims for Heretic are same to Doom: Completely resource independent, i.e. no included PWADs or assets. Demo and multiplayer compatibility with Chocolate and Crispy Heretic. Without any single correction/fix in game mechanics. Demo-safe exceptions are made for some gameplay features, but no more than that. Vanilla-like defaults. Various options will allow user to customize visuals for their taste. No "features for features", keeping reasonable amount. Something like that. But I really can't say when it will be done, I'm trying to do it calmly and without hurry, and have some small responsibilities in Crispy Doom and Woof source ports from time to time. Somewhere in the end of February 2024th, maybe. Meanwhile, please use any of recommended port from messages above. Every of them have own pros. 😉

Thank you too for heads up, it was a good practice for my memory! This case made me curious why brightmaps were never applied to translucent sprites (or "columns", speaking technically), neither here, nor in friendly ports. But it seems to be possible, and even give small notable result, pay attention to red light: This is different engine 🫢, but I'll gladly take care about it in Woof.

It is done and merged already, but same to Doom, it's a compile-time option because of 1st paragraph of FAQ. Technically, true color reveals colossal potentinal for visual improvements, besides from perfectly clean colors for game world rendering and translucensy, it gives completelly palette-independent map colors, nice background shading and much, much more, but we decided to don't go nuts and go conservative way, so true color in Heretic will do exactlly it's thing: just a cleaner colors for diminished lighting and non-tablified translucensy. Probably it will be fair if I'll post true color binaries as not all of us are programmers, but only if @fabian will allow me to do that. It's not about release a new versions though (I'm not authorized to do this), just a binaries with TC compiled in. Another notably good news is: all four games now have support for negative gamma-correction levels on same manner as in Woof, and updated binaries are available on http://latest.chocolate-doom.org/ 😉

Found this one! So, using a "Boom" format will be needed for WhackEd. To disable translucency, just set off it's flag from Bullet Puff in Things section: Vanilla's "Draw as shadow" will not help here - it will make thing drawing with spectre's fuzzy effect. I hope this helps. 🙂

Pardon me, I wasn't meant be! 😦 Was adressing @rfomin with this technical stuff. AFAIR, for mods, there must be something like disabling of translucensy for selective sprites. But I can't remember how exactly it should be done - was it a Dehacked flag? Or was it Bex specifics? Honestly can't remember, I never tried it. 😕

Not 100% sure, but it could be related to translucensy. Bullet puff is using it while function for drawing translucent columns doesn't handling brightmaps at all.

Clear, thanks for explanation @Flambeau! Let's hope for best then. 🙂

Yes. :( Getting to secret level is possible, but it returns to E3M7, just like in original Doom. I'm afraid this is the only part that can not be solved without source code editing. As about support for main version in Crispy, we better should ask @fabian. It's not that trivial unfortunately, since it will require either proper support for UMAPINFO (a bit complicated, require many changes), or couple of small hacks to handle E6 properly (really a no-go).

I made a small experiment trying to make a "compat" version which is working in Crispy Doom. Basically everything E6 is replaced with E3*. It took just about ~15 minutes to get everything working: Level names, graphics and PAR times. Killing Spider Mastermind isn't finishing E3M8. Demos in demo reel (little HEX edit magic). Vanilla-friendly sky. "Bunny screen" (well, just a copy of existing assets, dark and normal). Intermission screen. Needs some extra work, that's easy part. But. I highly respect time and efforts mr. Romero and other members spend on this project, and simply can't let myself just upload it without asking permission! I was just curious, is it really not compatible with source port that I know technically very well, and it seems to be working absolutely fine, though some more testing is needed. Just hope that there are no Boom-specifics were used, they will lead to soft-lock since Crispy doesn't support them. So... What should I do? Ask John Romero by e-mail, or am I worry too much about such thing? Or is it deserves a new thread, on same manner it was done with vanilla-compatible Sigil I? Perhaps, there will be next version and 1.0 is not the last one, I really don't know, so maybe it is too early to even speak about "compat"? Lots of dilemmas.

Thanks @plums! Heretic true color reveals protentional for Hexen and Strife true color support, but both these games will not give up that easy, unfortunately. As about per-game flag, if I'm not mistaking it's not, there is no such flag, as true color code is placed in upper level code, and there doesn't seems to be a way to compile something with and something w/o true color code. However, you still can perform a small tick: compile Doom without enabled true color, then just make a backup copy of Doom executable and compile Heretic with true color.

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.