Chocorenderlimits/CRL 1.8 (May 19, 2024)

[Julia Nechaevskaya]

CRL is a continuation of Chocorenderlimits source port created by RestlessRodent.

 

Armed with new features, QoL and technical improvements, it provides the ability to assist mappers in creation of Vanilla compatible maps, as well as checking some specific scenarios via additional ingame modes. The grave/tilde [~] key opens the in-game menu which can be used to change the settings and features, few extra key bindings are available in Setup executable / Configure CRL Controls menu.

 

Major idea is still same - this is crash-prone source port, which will print ingame warnings instead of crashing. However, no changes were made to to drawing code and important bugs like Tutti-Frutti and Medusa are still here, to preserve DOS executable behavior and look. Medusa is no longer critical though, and not crashing Windows executable. For vanilla-compatibility purposes, despite of being crash-prone in complex game scenes, this is not limit-removing source port and it will not be able to load huge maps.

 

Important bits of code has been ported from International Doom, Crispy Doom and DOOM Retro.

 

CRL Doom, version 1.8 (May 19, 2024)

• Windows (64-bit): crl-1.8-win64.zip
• Windows (32-bit): crl-1.8-win32.zip

 

CRL Heretic, version 1.0 (June 12, 2023)

• Windows (64-bit): crl-heretic-1.0-win64.zip
• Windows (32-bit): crl-heretic-1.0-win32.zip

 

GitHub repository

• github.com/JNechaevsky/CRL

 

Project's Wiki with additional info about counters, game modes and cheat codes

• github.com/JNechaevsky/CRL/wiki

 

Edited May 19 by Julia Nechaevskaya

[Arsinikk]

This is super awesome!

 

Glad to see a successor to Chocorenderlimits that's more modern with support for-dehlump and with an actual menu accessible via the "~" key.

 

After testing some maps with CRL, this will definitely be a goto for testing VPOs and Drawsegs! :)

[slowfade]

Sounds very good! Haven't launched it yet but I will once I get back to vanilla mapping. The spectating mode sounds really useful.

[Redneckerz]

This is fabulous @Julia Nechaevskaya. Chocorenderlimits is a great tool for Vanilla mappers alike and someone like @esselfortium will likely enjoy this a lot.

 

Ill probably give it a go against Knee-Deep-in-Knee-Deep-In-ZDoom and see how that fares. Should run it.

[taufan99]

Now this is spectacular! Everyone has been wondering for an updated version of the original Chocorenderlimits, including but not limited to me.

[esselfortium]

Thanks for this! Which version of CRL is this based on? I ask because there were two very different CRLs with some significant feature differences between them, with things like a more intuitive display style and an archvile-jumping key (extremely useful for testing hotspots) only existing in the older one. (I know the source code for the earlier version was believed lost at one point, but it was dug up a couple years ago.)

[Synami]

Holy shit.

 

Hooooly fucking shit.

[Julia Nechaevskaya]

Hey, thank everyone! Honestly, I wasn't sure there will be any interest for this project. I know, it is a bit odd that after five years it appears from nowhere, but decision was made to "turn around", make things properly (build system now using CMake, so source code must be friendly with other than Windows OS) and apply all experience I've got while working on Inter-Doom.

 

Have to say frankly: at the beginning of work (the end of January 2023), I wasn't having any plans to add new features, but the more I was digging into project, the more ideas starts to come. Finally, I've come up to philosophy: "if this port is used to check vanilla limits, why can't it be used for normal playing along with checking? Some small gameplay-safe features will do their good things".

 

@esselfortium, yeah, if I'm getting things right, there were two versions of Chocorenderlimits: old one, based on Chocolate Doom 1.5 and new one, based on Chocolate Doom 2.x presumably, which was never released officially but source code was preserved in Chocolate Doom archive, and this version becomes a base for CRL.

 

Funny to say: I literally wasn't know about old version until looked closely to screenshot at DoomWiki and noticed, that render counters are aligned a bit differently. Much later I was able to find source code of old version, but technically it wasn't needed already.

 

As about Arch-Vile jump - yep, I've seen it, but was too afraid to port it, considering it as a "dangerous" feature. But thinking now, it should be handy and safe enough, if it will be limited to single player only for preserving demo compatibility. Demos are critically important thing, not only for automated testing, but also because it's a Right Thing to have. There are even few features like demo bar and timer, to make them more comfortable to watch.

 

Couple of ideas for future version:

• Variable framerate capper. At this moment, there is only vanilla 35 fps (capped) / vsync limited framerate (uncapped).
• Print which exactly patch is causing V_DrawPatch error. For some graphics it's very easy, for some, however, it's not. For now, "broken" patch is simply isn't drawing and "critical" message is appearing.
• Spectator’s camera movement is not interpolated in uncapped framerate. Should be easy implement, but I wasn't lucky to it. 
• Spectator’s vertical camera movement is possible and it respects player run mode: holding "shift" is moving camera by 32 map units, while not holding by 64 map units. For now it’s hard-coded to mouse wheel, and adding bindable keys will be useful. Then again, what about amplitude?
• Freeze mode isn't very optimal, as it keeps level time ticking. From another hand, this feature is more handy for watching sprite rotations or just for fun.
• Z_Malloc errors. This is pain, and this is must happening to represent vanilla Doom behavior. Otherwise, a false impression can be formed, that if something not overflowing in CRL, it will not overflow in DOS executable, but in fact it will, and in worst case, will lead DOSBox/real DOS machine to lock up.
• Extend port's description and/or document some features. This is the thing I'm always doing just bad...
• Collect some feedback. Despite of playing Doom from 1994 and knowing more or less how things are working, last time I was making maps was 2004 (couple of soccer stadiums). I've made couple of testing maps for Crispy Doom and Inter-Doom, but all them were just for selective testing purposes only.
• Keep. It. Small. And. Simple.

[Breezeep]

About time. The original Chocorenderlimits desperately needed an update of some kind. I'm really digging all the new features on display here.

[esselfortium]

8 hours ago, Julia Nechaevskaya said:

As about Arch-Vile jump - yep, I've seen it, but was too afraid to port it, considering it as a "dangerous" feature. But thinking now, it should be handy and safe enough, if it will be limited to single player only for preserving demo compatibility. Demos are critically important thing, not only for automated testing, but also because it's a Right Thing to have. There are even few features like demo bar and timer, to make them more comfortable to watch.

Glad to hear! It's a really useful feature for stress-testing visplane-heavy areas, so it'll be great to have it available in a newer version of CRL.

[Midway64]

This is gonna come in real handy as I'm mainly aiming to make Vanilla WADs, looking forward to your work!

[Julia Nechaevskaya]

CRL 1.1 is out! I hope this update will provide useful features to make the port even more handy for both testing and common playing. 

 

Download:

• Windows (32-bit): crl-1.1-win32.zip
• Windows (64-bit): crl-1.1-win64.zip

Changelog:

 

Spoiler

 

Technical improvements

• Added support for imitation of Arch-Vile's attack jumping, key can be binded in Setup/CRL Controls/Movement section. Note: to keep demo sync compatibility, jumping is not allowed while demo recording/playing and while network game. (thanks @esselfortium)
• Support for drag-n-drop of IWAD/PWAD/DEH/LMP files into executable now working as it should (thanks Clang compiler...).
• Added support for WAD/DEH files autoload from Chocolate Doom. An autoload folder will be placed in source port directory.
• Added dedicated button for toggling Always Run mode. Default is CapsLock, can be rebinded in Setup/CRL Controls/Movement section.
• Added dedicated buttons for moving camera up and down in Spectator mode. Can be binded in Setup/CRL Controls/Movement section.
• Extended "Bad drawpatch" error message: now it's showing which exactly patch is causing error (i.e. is drawn off-screen).
• Added VSync toggling, framerate limiter and framerate counter (thanks @fabian, @rfomin, @mikeday and @LexiMax).
• Optimized Chocorenderlimits palette handling for non-colorblind mode - this will fix barely noticeable fps dropoffs on palette changing (gamma-correction, pain and bonuses).
• ENDOOM screen is now showing in same window as the game.
• Multicolored HOM effect now framerate-independent and always using 35 fps speed.
• Game setting now always saved, even after error message.
• Hovering mouse over inactive game window no longer mover camera; mouse is always grabber in windowed mode while active Spectator mode.
• Added Control Setting ingame menu. Mostly a replica of few setting from Setup executable.
• Updated SDL2 library to version 2.26.5.
• Windows OS only: Icons in error dialog boxes now using modern flat style.
• Windows OS only: console output windows is no longer hot-swappable in game menu. This will fix small hiccup at program startup and fix window "flashing". However, fully operational console is still available by using -console command line parameter.
• Other small technical improvements.

Gameplay features

• Added "Restore monster targets" feature, which will restore targets and aggression from savegames. It's hot-swappable and does not require resaving after toggling feature on/off. Can be handy for checking/rechecking some combat situations. Default option is off to keep vanilla behavior (thanks @fabian).

Automap

• Changed green color of IDDTed items: now it's showing countable items.
• IDDTed items no longer looking always top while Spectator and automap rotate mode.
• Player arrow will glow and extra triangle will be drawn while active Spectator mode on automap.
• Command line parameters
• Added -shorttics parameter for playing with low turning resolution to emulate demo recording.
• Added -coop_spawns parameter to start single player game with items spawns as in cooperative netgame.
• Windows OS only: added -console parameter to allocate text console for program prints output.

Bug fixes

• Saving setting in Setup executable no longer resets game window position.
• Fixed pressing F11 was not able to select gamma-correction level 4.
• Window position no longer resets to centered after starting game in full screen mode.

 

[esselfortium]

Thank you!

[Somniac]

I had a quick test run with this last night, as I've been using chocorenderlimits for mapping a lot more lately. First thing I noticed was that the render counters are much more legible and stand out more, making it much easier to ascertain those stats at a glance. Very nice! Its a small thing, but definitely useful. Can't wait to try out the other new features, this is a crucial utility for vanilla mapping and I had occasionally wondered if/when somebody would make an updated version. Thanks for sharing this! 

[Julia Nechaevskaya]

Thank you! I was trying to put as much attention to visual aspects (widget lines, coloring, menu, etc.) as possible. Honestly, I don't know if other than Spectator modes can be useful, and nearly all features were added in assumption that they can be handy, or at least fun to play around.

 

Couple of done things and TODOs:

 

Done:

• Extended "Triggered intercepts overflow" message. Now it's showing when All-Ghosts effect is happening, and when it's just an overflow.
• Implemented optional, hot-swappable Doom-plus engine limits. Not the Right Thing to exist in this project... But it gives ability to play more detailed levels like Sigil w/o HOMs and overflow warnings. May be useful for users who prefer to use this port for common playing, not for map-development purposes. Anyways, default limits are still vanilla, and support very big maps with extended nodes is out of question.
• SEG counter now able to show overflowed values like 333/256 and thus, can blink yellow-red.

Possible TODOs:

• Spectator camera is still not interpolated in uncapped framerate, while the rest of game world is. I was going a lot in a circles, wrong circles, and now it is obvious that camera should be handled differently. But it's still not that easy as may sounds.
• Probably, better error handling of map errors. Nowadays map editors and node builders are polished to perfection, but some levels from 90th era are still able to lock-up executable. PrBoom+ handles such cases just fine.
• Investigate what can be done for optimizing colorblind palette handling. Colorblind mode was written by RestlessRodent in pre-3.0 codebase, presumably as a part of possible A11Y settings, and I want to keep it as a part of original Chocorenderlimits. But I don't want to lie, this is not in high priority.
• Target's health widget is not optimal, it's showing health only when player is aiming at monster. Ideally, health should be displayed for about 1 second even after player is no longer have a target.
• Try to push Openings to its real limit. Not sure how exactly to do this, and if there are some demo maps existing, that's worth gold.

[Julia Nechaevskaya]

CRL 1.2 is out! Everything went just as planned.

 

Download:

• Windows (32-bit): crl-1.2-win32.zip
• Windows (64-bit): crl-1.2-win64.zip

Changelog:
 

Spoiler

 

Technical improvements

• Changed behavior of "Triggered intercepts overflow" message: now it's showing in-game warning only when All-Ghosts effect is happening. Console output is still showing both cases.
• Optimized "Traget's health" widget and extended indication to "top / top + name / bottom / bottom + name". Names are Dehacked-friendly.
• SEG counter now able to show overflowed values like 333/256 and thus, able to blink yellow-red.
• Improved MAXOPENINGS limits handling. Openings counter (OPN:) now able to catch MAXOPENINGS overflows and print in-game warning.
• In-game warnings now print when MAXLINEANIMS or MAXPLATS is overflowed.
• Updated libsamplerate library to version 0.2.2-1.
• Increased vanilla screenshot files cap from 100 to 10000, a "screen shot" message is appearing only in -devparm mode.
• Added support for up to 8 pages of savegames.

Spectator mode

• Movement and rotation now interpolated in uncapped framerate mode!
• Saving and pausing now possible while spectating, slightly improved mouse cursor capturing in windowed mode.
• Controls are now automatically returned back to player when level exited in spectator mode.

Freeze mode

• Whole game world including level timer now properly freezed (excluding player, of course).
• Freeze mode now keeping across levels.
• Puffs from hit-scan attacks no longer able to appear below floor and above ceiling levels.

Static Engine Limits

This is a new submenu with two following items:

• Prevent Z_Malloc errors. Prevents "Z_Malloc: failed on allocation .." errors when Doom runs out of Zone memory.
• How-swappable limits between vanilla and doom-plus levels.

Please note: do not consider preventing Z_Malloc errors and Doom-plus limits for making vanilla or Chocolate Doom compatible maps! This is not how the things should work there. However, for regular playing it is completely okay to don't get memory errors and have an ability to see more complex scenes like on Sigil.

 

Multiplayer

• Updated networking code. This provides compatibility for playing multiplayer game with Chocolate Doom, Crispy Doom and Woof! (in vanilla complevel). Support for DeathMatch 3.0 and improved coop spy (an actual status bar values and sound separation for spied player) are also included.
• Netgame chat now working.

 

Compiled using GCC 12.2.0 under MSYS environment.

 

 

Edited April 30, 2023 by Julia Nechaevskaya

[taufan99]

Thanks for the latest update! I have the "Enable ENDOOM" setting enabled, but for some reason, every time I quit the game, it just skips the ENDOOM screen after loading for a short while.

[Julia Nechaevskaya]

Confirmed and fixed, thank you! Will work as intended now, i.e. showing in same window as game itself and be able to resize "on fly" (not really needed, just looks cool).

[maxmanium]

Would there be a way to implement checking against this limit?

[Julia Nechaevskaya]

It's already here, inherited from Chocolate Doom. However, instead of exiting with error message, an in-game warning will be printed if overflow of this limit is happened. In fact, there is no limit for save game size, you even can save game in KDIKDZD, and warning can be disabled in Setup / Compatibility menu. Same applies to recorded demo size.

[esselfortium]

I'm back with a few other requests :)

 

A feature that's extremely useful in old CRL is the ability to use a hotkey to snap the player position back to the highest recorded visplane count, and another hotkey to reset the recorded highest. It would also display that highest recorded value onscreen so that you can more easily recognize whether you've hit an overflow while bouncing around haphazardly.

 

And something that was never in CRL but arguably should be: the solidsegs limit.

 

I'd also find it handy if there were mappable one-key binds for god mode and noclip.

 

Thanks again for your work on this!

[Bobby :D]

2 hours ago, esselfortium said:

A feature that's extremely useful in old CRL is the ability to use a hotkey to snap the player position back to the highest recorded visplane count, and another hotkey to reset the recorded highest. It would also display that highest recorded value onscreen so that you can more easily recognize whether you've hit an overflow while bouncing around haphazardly.

Super hard agree, that feature is why I stick with old CRL, just being able to know what exact viewpoint is causing issues gives me so much valuable information.

[Julia Nechaevskaya]

I was going to work on this little known game, but Doom is in priority №1, and if these features will be helpful, sure, I'm all for it. 🙂

 

Replication of MAX should be doable, I think I'll handle it. First easy part of gathering/keeping/clearing MAX value is done (screenshot), but moving player to MAX is a bit more complicated - I need to understand how to update player's position in BLOCKMAP after jumping as well, otherwise engine will simply locks up.

 

Is it okay if I'll leave "Jump to MAX" and "Clear MAX" unbound by default? ChocoRenderLimits was using F-Keys for this, but I would like to keep vanilla behavior for them, just for easy checking of how help screens and etc. will look in vanilla.

 

Important question: should MAX be gathered while spectator mode? Spectating allows to move camera where real player can't get, including outside of level bounds, and thus, jumping to such MAX may be not that helpful.

 

11 hours ago, esselfortium said:

And something that was never in CRL but arguably should be: the solidsegs limit.

 

Do you mean counter or overflow catcher? If catcher, it's already here, inherited from Chocolate Doom, but instead of bombing out, CRL prints in-game warning (screenshot). If counter, this get's a bit complicated because vanilla Doom is using limit of 32, while Chocolate Doom is using limit of 161. Not sure which value should be used as counter's max value in this case.

 

12 hours ago, esselfortium said:

I'd also find it handy if there were mappable one-key binds for god mode and noclip.

 

This definitely deserves a full set of bindable keys for every cheat, I'll do it. 😉

[esselfortium]

Thanks so much!

 

Leaving them unbound by default is fine, as long as they're bindable :)

 

I think it would make sense for it to apply regardless of whether you're in spectator mode. Users should be able to figure out whether they're in a place that's physically reachable during gameplay or not. (In old CRL it was possible to record a max visplanes count while noclipping, it's fine. You just hit the key to reset it if it's a place that isn't relevant.)

 

Good to hear there's an overflow catcher for solidsegs. If a counter is added, it should be for the original vanilla 32.

[Julia Nechaevskaya]

Good news, everyone! All requests seems to be done. For now:

 

- MAX planes counter and clearing/jumping is working. I've spent couple of hours on it, and in the end decided to verify with old ChocoRenderLimits source code to see what I have potentially missed. RestlessRodent's implementation was far better and simpler, so I decided to use it with small fine-tunings: jumping position is more precise in uncapped framerate and MAX is reset after level finishing. Clear/move keys can be binded in Setup/Configure CRL controls/Visplanes MAX value menu. Moving player to MAX is also possible while spectating, but beware, you can drop player right into the monster's hands. :)

 

Also, render counters position is now more flexible, if level time/KIS stats are off - they will be shifted down, but always leave one free line for map name in automap.

 

- SolidSegs counter ("SSG:") is done and operational. Have to correct myself: despite of raised limit in Chocolate Doom, overflow is still considered on values 33 and higher. Here's the save file I was using for testing on MAP15 of Doom II, just carefully rotate camera left-right to see and overflow.

 

- Cheat shortcut keys are done, can be binded in Setup/Configure CRL controls/Cheat shortcuts menu. This is not exactly how it should work, because you can hold button for toggling on/off, while ideally key should be released first, but this is most fast and painless implementation.

 

Now, before considering everything done, please check this build: crl-pre-1.3-win64.zip

It must be stable enough, and keybinds will be friendly with future release, but maybe there still some more suggestions, or requests, or recommendations?

[esselfortium]

Perfect, thank you very much for this!

 

One bug I've noticed is that pressing move to max very quickly after resetting max will teleport the player to 0,0. Everything else seems great.

[esselfortium]

It also appears that visplane counts above 128 aren't counted. Knowing the actual number reached can be useful for knowing whether you're just a little bit over and can reduce something simple, or whether you need to completely rethink an area.

[Julia Nechaevskaya]

Thanks! MAX jumping to 0,0 now fixed, as well as spontaneous player jumping to camera position while clearing MAX in spectator mode.

Archive with updated executable on same link: crl-pre2-1.3-win64.zip

 

Count above 128 is possible, but this is complicated. :( Higher values are appearing while "checking/drawing" overflow (screenshot), however when engine bumps into "finding" overflow, it stops drawing any farther visplanes, and thus, only 128 are counted/drawn (screenshot). Not sure I can explain it properly, but RestlessRodent left a comment about check/find here.

 

And here comes a crossroad. RestlessRodent wrote a bullet-proof condition to prevent render go any farther once visplane overflow is happened. Engine jumps back to the start of rendering order while vp overflow and can't go any farther until vp overflow is gone from player's view. That's why sprites stops from being rendered - they are next in drawing order. This condition also making error messages obsoletely accurate to vanilla.

 

I can omit this condition and render will be able to count all visible planes and even show sprites while overflow (visible vp amount is still limited to 128 in vanilla / 1024 in doom-plus limits), but this will omit "find" error message as well, making overflow error messages inaccurate comparing to vanilla. I'm not sure what is more important: either accurate error messages or real vp counter. :/ Here's how it will looks in second case: 

 

Spoiler

 

How should I proceed? Left overflow handling "as is" for accurate error messages, or omit bullet-proof condition and "find" message to let engine always show overflow and sprites? Or perhaps, try to make an option in Engine Limits menu (and if so, how to name it? 🤔)

Edited May 8, 2023 by Julia Nechaevskaya

[esselfortium]

I would say there's probably not much practical value for mappers in the difference between the two different visplane errors you can get, and having the accurate number would be more useful.

[Julia Nechaevskaya]

Agreed, it's not about accurate messages after all. I will increase inner visplanes limit to 32767 and disable "find" message, this should be large enough to handle any scene in non-extended map nodes, but overflowing 32767 now will cause real silent engine crash. Barely it is possible to image such scene, though. 🙂

Sprites will also be drawn normally, and vp counter will still be accurate (yay!).

 

Just one question left: should visplanes still turn into HOM when limit is hit? It it possible to keep drawing them even after overflow of 128/1024 values.

I believe HOM should remain, as it is most critical vanilla limit, and such indication is helping to don't miss it.