Chocorenderlimits/CRL 1.7 (January 3, 2024)

[esselfortium]

That sounds fine. Thanks again!

 

One other thing I've run into, which might not be fixable easily: Binding the clear/move to max actions to F2 and F3 like they were in old CRL doesn't work because the original fkey functions override them, so I tried binding them to Q and E instead to have them nearby the movement keys. This works fine for the most part, but when typing in a cheat like idbeholdr, I hit E and get warped to the max visplane spot. I think some modern ports have a way of preventing this kind of accidental input, I'm guessing it's done by checking if you've just typed "id". No worries if it would be too annoying to fix, I'm just noting it.

[Julia Nechaevskaya]

Not fixable easy indeed, if fix it absolutely right way. :) But idea of typing "id" makes a big sense, so I can do a simple trick with following logics:

• User has stated to type cheat code "id(something)".
• Right after typing "id", a timer is set for... 3 seconds (should be enough to type any cheat?), and while timer is active, no other player's "actions" than typing can be performed, notably keyboard movement and specific CRL keys. Menu opening and mouse handling are still available.
• Once cheat is typed, timer is set to zero and controls are back to normal.
• This will also fix small strafing right after pressing "d" while typing any cheat code. Yeah! 🤩
• Only one cons, though: if no other than "id" is typed, player is immobile for 3 seconds.

Binding of F1-F12 keys in Setup is also fixed now. Before the fix binding was saved as double-bind, i.e. if "Move to MAX" was assigned to F2, game was still catching F2 in menu responder, and thus, was opening a Save Game menu. Now if F-key is binded in CRL Controls, such F-key will be unbinded from any other action. This is a bit dangerous, because F10 can also be rebinded making quit game slightly more complicated, so I can only hope that user will understand consequences of rebinding F-keys.

 

What is also done:

• Smarter MAX value reset, so user won't jump accidently to incorrect position after entering new level. Now reset is happening only when player is going to literally another level. While level is same on game load, starting new game or level reload shortcut, MAX value and move position remains same.
• PLN counter now always able to show overflow values and sprites are no longer disappear when vp overflow is happening. HOM on planes is still happening for better indication.

And it's all here: crl-pre3-1.3-win64.zip

[SoDOOManiac]

Congratulations on the release, @Julia Nechaevskaya!

[Julia Nechaevskaya]

Thank you, but it's just a WIP-development snapshot, not a release. 🙂

 

[esselfortium]

On 5/9/2023 at 4:57 AM, Julia Nechaevskaya said:

Not fixable easy indeed, if fix it absolutely right way. :) But idea of typing "id" makes a big sense, so I can do a simple trick with following logics:

• User has stated to type cheat code "id(something)".
• Right after typing "id", a timer is set for... 3 seconds (should be enough to type any cheat?), and while timer is active, no other player's "actions" than typing can be performed, notably keyboard movement and specific CRL keys. Menu opening and mouse handling are still available.
• Once cheat is typed, timer is set to zero and controls are back to normal.
• This will also fix small strafing right after pressing "d" while typing any cheat code. Yeah! 🤩
• Only one cons, though: if no other than "id" is typed, player is immobile for 3 seconds.

Hmmm, probably ignore that request then. Thanks for considering it though! I'll check out the latest build and let you know if I run into any more issues.

[Julia Nechaevskaya]

CRL 1.3 is out! Phew, another two weeks of intensive coding marathon. Kind thanks to @rfomin for the hints that's made things better and life easier!

 

Download:

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

Changelog:

 

Spoiler

 

Ingame keyboard and mouse bindings

• Now available in CRL / Control Settings menu (thanks @rfomin). Pages on keyboard bindings can be scrolled by both PGUP/PGDN and arrow keys. Please note, vanilla options menu now accessible via CRL menu only, by selecting "Vanilla options menu".

Technical improvements

• Added support for catching "MAX" visplanes in visplanes counter. Key binds for clearing value and moving to MAX available in Setup executable / Configure CRL controls/Visplanes MAX value and ingame keyboard bindings menu (thanks @esselfortium).
• Added SolidSegs counter ("SSG:") for MAXSEGS limit (thanks @esselfortium).
• Added shortcut key binds for cheat codes, available in Setup executable / Configure CRL controls / Cheat shortcuts and ingame keyboard bindings menu (thanks @esselfortium).
• Improved cheat codes handling. Typing "id.." should no longer invoke other player actions for next three seconds; after typing cheat code controls back to player immediately. This also fixes small strafing right while entering cheat code (thanks @esselfortium).
• Visplanes counter ("PLN:") now able to show overflows in all instances. Sprites no longer disappear while visible overflow is happening (thanks @esselfortium).
• Render counters position now more flexible if level time / KIS stats widgets are disabled. Fine-tuned vertical position for level time / KIS widgets to line up with automap's map name as well.
• Added support for doom-all autoload folder.
• Instead of going into infinite loop, port now exits with error message on level loading if subsector is not a part of any sector (noted on EFIGGY.WAD, thanks figgi for the fix found in PrBoom+).
• Default value of "Playstate Counters" now set to "overflows" (doesn't affects existing configuration files).
• Pages on savegames can be scrolled via arrow keys.
• Warnings about savegame and demo sizes now can be disabled in Static Engine Limits menu.
• Refinements in CRL menu - values of selected menu item now also highlighting and glowing.
• Small technical improvements.

Bug fixes

• ENDOOM screen now working again (thanks @taufan99).
• Repeating last message by pressing Enter now working.

 

[RestlessRodent]

Hi!

 

Original developer of ChocoRenderLimits here, glad to see someone picking it up again and enhancing it! I do wish you the best of luck with it!

[Julia Nechaevskaya]

Dear @RestlessRodent,

 

It is nice to finally meet you! Thank you very much for all your efforts and lovely simple and transparent code, it was a pleasure to work with it! ❤️

 

I do regret that I've come to it a bit late, but back in 2018 I wasn't experienced enough to make some good things, and even simple Doom menu API was something like a rocket science for me back then (despite of @fabian have said it's not, I remember:). Maybe this is for good, because a lot technical improvements happened since then which including uncapped framerate, MIDI music handling, gfx patches coloring, overall code stability and many many others.

 

Speaking of MIDI code, it needs update in CRL, because at the moment it is using mostly initial implementation that @ceski wrote for Chocolate Doom. It lacks some farther improvements and in some rare cases playback can stuck giving "MidiStream error" (AFAIR). Gladly will do it, just a little bit later - I need to take a breath. For last four months I was working on CRL like it's a regular day job, but that's not the thing I do regret. 🙂

[RestlessRodent]

4 hours ago, Julia Nechaevskaya said:

Dear @RestlessRodent,

 

It is nice to finally meet you! Thank you very much for all your efforts and lovely simple and transparent code, it was a pleasure to work with it! ❤️

 

Thank you! I tried to keep the code as simple as possible and make it as standalone as I could.

 

4 hours ago, Julia Nechaevskaya said:

I do regret that I've come to it a bit late, but back in 2018 I wasn't experienced enough to make some good things, and even simple Doom menu API was something like a rocket science for me back then (despite of @fabian have said it's not, I remember:). Maybe this is for good, because a lot technical improvements happened since then which including uncapped framerate, MIDI music handling, gfx patches coloring, overall code stability and many many others.

 

Speaking of MIDI code, it needs update in CRL, because at the moment it is using mostly initial implementation that @ceski wrote for Chocolate Doom. It lacks some farther improvements and in some rare cases playback can stuck giving "MidiStream error" (AFAIR). Gladly will do it, just a little bit later - I need to take a breath.

 

Yeah I know the code is a bit ancient in today's terms, but at least back then it was bleeding edge!

 

4 hours ago, Julia Nechaevskaya said:

For last four months I was working on CRL like it's a regular day job, but that's not the thing I do regret. 🙂

 

Passion projects are always fun projects!

[Julia Nechaevskaya]

CRL 1.4 is out! Just a small maintenance release, please do not expect something extra ordinary. 👀

 

Download:

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

Changelog:

Spoiler

 

Technical improvements

• Game now remember last selected menu item in CRL menu after closing CRL menu by pressing ~ key.
• Better handling of Z_Malloc errors prevention.
• Upgraded WinMidi code to actual Chocolate Doom code, added previously missing winmm_* config file variables (thanks @ceski).

Bug fixes

• Fixed missing glow effects in CRL menu while playing demos in uncapped framerate mode.
• Automap and "send to player" keybinds are no longer clearing when binding same key in other pages.

 

 

CRL-Heretic is going smoothly but slowly. All core RenderLimits features and technical improvements like uncapped framerate, keybinds and mouse look are working, I just need to find some extra will and motivation to finish it. 

Edited June 5, 2023 by Julia Nechaevskaya

[Walter confetti]

Awesome!

[Julia Nechaevskaya]

CRL Heretic 1.0 is out! No, seriously. 🙂 It keeps major idea of being overflow crash-prone source port and keeps almost all CRL features, including render and playstate limits, powerup counters, technical improvements, optional mouse look and in-game bindings menu.

 

Download:

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

In general, in went smooth since all code was perfectly portable, but I honestly don't know, was it necessary at all. Real challenge was to align all the widgets and text lines (mockup screenshot) - Raven's font is notably taller and vertical space is more limited than in Doom because of taller status bar.

 

Alas, disadvantages that I must admit:

* Spectator camera is unable to look up/down. Should be easy on render side, but I've got confused how to properly pass looking direction value.

* No automap rotate/overlay mode. Grid, however, was implemented as BLOCKMAP checking could be useful.

* No demo warp/pausing. The rest of demo like features bar and timer are here.

* "Bad V_DrawPatch" shows only about half of patch names. Some patches require constructing proper name for appearing in error message - doable, but not very exciting process...

* Changing music system require program restart. I wasn't able to handle it in Inter-Heretic, and not able to handle it here.

[Scypek2]

On 5/9/2023 at 10:57 AM, Julia Nechaevskaya said:

• Right after typing "id", a timer is set for... 3 seconds (should be enough to type any cheat?), and while timer is active, no other player's "actions" than typing can be performed, notably keyboard movement and specific CRL keys. Menu opening and mouse handling are still available.
• Only one cons, though: if no other than "id" is typed, player is immobile for 3 seconds.

 

Could menu/mouse movement also unfreeze the player? That seems like a good middle ground!

[Julia Nechaevskaya]

Good idea, thanks! Even muscule memory is not a garantee for preventing typos in cheat codes, and that's should help.

Could you please try this build to see if it's working correct? "ID" timer will be reset if menu is active or player is moving mouse or pressing it's buttons: crl-pre1-1.5-win64.zip

 

Other changes were made since 1.4 release:

Spoiler

Technical improvements

• Implemented keyboard (available on last binding page) and mouse bindings reset function.
• Extended KIS/level timer/player coords widgets to show in automap only.
• Applied latest changes in MIDI/FSynth code from Chocolate Doom.

Bug fixes

• Fixed doubled "FPS FPS" sting in FPS counter when framerate is above 999.
• Fixed visual bug of door jittering on Doom 2 map 19, caused by rendering interpolation (see fabiangreffrath/crispy-doom#1072, thanks @rfomin).

 

[Julia Nechaevskaya]

CRL 1.5 is out! Another small maintenance release. Nasty bug, introduced in pre-1.5 and causing silent crash while mouse movement at program startup is fixed.

 

Download:

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

Changelog:

Spoiler

 

Technical improvements

• Implemented keyboard and mouse bindings reset function (available on last binding page).
• Extended KIS/level timer/player coords widgets to show in automap only.
• Applied latest changes in FL/MIDI code from Chocolate Doom.
• Player will be "unfreezed" after typing "id" and moving/pressing mouse buttons or opening any game menu (thanks @Scypek2).
• FPS widget no longer appearing on text intermission screens (was obstructing text lines).
• Updated SDL2 library to version 2.28.0.

Bug fixes

• Fixed doubled "FPS FPS" sting in FPS counter when framerate is above 999.
• Fixed visual bug of door jittering on Doom 2 map 19, caused by rendering interpolation (see fabiangreffrath/crispy-doom#1072, thanks @rfomin).
• Fixed appearing of jittering player sprite while game paused in freeze + uncapped framerate mode in some instances.

 

 

[Julia Nechaevskaya]

Dear map creators,

 

I have three extra ideas, but would to ask first - are they really needed or useful, and is it worth to add?

 

1) Once MAX value reaches ≥ 128 (or 1024 in Doom+ limits) it will be colored yellow. Not blinking, too much blinking could be annoying, just a yellow color for easier visual distinguishing. Just like that:

 

Spoiler

 

 

2) Add "Buddha" mode/cheat code. If activated, player's health will never drop below 1, matters no how hard they injured. Could be useful for custom red pain palette or ingame checking?

3) Resurrect dead player by typing "IDDQD" cheat code. Could be useful for common playtesting?

[Midway64]

Everything seems good enough to me! 👍

[Walter confetti]

Buddha code YES

[Moustachio]

@Julia Nechaevskaya That all sounds great! Will it be a solid yellow or will it change brightness like in the video? Can we choose our color preference?

[Julia Nechaevskaya]

All done:

• MAX will be colored yellow once reaches 128 or higher values.
• "Buddha" mode, cheat code "BUDDHA" and hot-key bind.
• Added cheat codes "FREEZE" and "NOTARGET".
• "IDDQD" will resurrect dead player.
• Upgraded SDL to latest version 2.28.1.

All here: https://jnechaevsky.github.io/files/crl-pre-1.6-win64.zip

 

@Moustachio, thanks! Just a solid yellow color, it will be cleared once MAX is cleared as well. It is compatible with custom modified palettes, since it is a HSV conversion, not a red-to-any playpal dependent approach. There is no option for changing colors though. To be fair, I'm a little worried by adding new features now, because all core and additional features are up, polished and running, and better avoid "feature bloating" with all costs.

 

However, everything can be discussed and this project should remain user and mapper-friendly. 🙂

[Moustachio]

By all means, work on things at your own pace! I understand that avoid bloating CRL with tons of customization options would detract from the overall intent of it as a lightweight testing tool. With that being said, however, I would like to advocate for the fact that CRL will be more accessible to users who have color blindness or other vision impairments if there was some choice as to the appearance of the MAX color.

[Julia Nechaevskaya]

Agreed, seems fair enough. I still can make blinking slower than common counter blinking, without requirement for micro-switch, like this:

 

2x slower

Spoiler

 

4x slower

Spoiler

 

 

Which one is preferred then?

 

As about colorblind, well, personally I don't have one. However, I have something probably similar, not sure what is it and how it is called. Window in my bedroom is facing east, and in summer time when the sky is bright enough in the morning, if I'll look at the sky for about one minute and then look at the cellphone, I'll see green color as yellow. Notably WhatsApp icon is visible as orange, but I know for sure it is actually green. But it all passes in a couple of minutes and never happens  later during day or evening time, so I simply don't have a scenario to reproduce it. Same was happening with your profile picture this morning. 🙂 Really no idea what the heck is this, either eyes driver needs some extra time to be loaded, or age takes its toll.

[taufan99]

Late reply but while I'm fine either way, I prefer 2x more. Although, I believe you might want to make users able to toggle between both.

[Julia Nechaevskaya]

I've decided to make an option for it. Should satisfy everyone's needs, and whole this project is, let's just say, about visplanes overflow catching. 🙂

Spoiler

 

Does it looks / feels okay this way? This should be last change before 1.6 release, really don't want to leave things in development hell and in pre-release condition.

[taufan99]

Looks okay to me. Although, I think the error message could last longer after having been initially displayed.

[Julia Nechaevskaya]

It is intentional by design. To be more clear: this message is dependent on rendered frame, i.e. it is appearing only while overflow is happening. I was thinking to make it longer, but it might be possibly confusing to see it when there is no overflow. Also, there are two other "alarms" for such cases: blinking counters and floor/ceiling textures.

 

More proper example with MAXOPENINGS overflow:

Spoiler

 

[Julia Nechaevskaya]

CRL 1.6 is out! I apologize, it took way too much longer than it should. Feeling too exhausted of source port programming, but all suggested request are up and done.

 

Download:

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

Changelog:

Spoiler

 

• MAX will be colored yellow once reaches 128 or higher values. Additionally, added blinking styles to "Widgets and Automap" menu (thanks @Moustachio).
• Added BUDDHA in-game mode, cheat code BUDDHA and hot-key bind.
• Added FREEZE and NOTARGET cheat codes.
• IDDQD cheat code will resurrect dead player.
• [Windows OS] Port not properly open WAD files by "Open with...".
• Updated SDL2 library to version 2.28.3.

Compiled using GCC 13.2.0 under MSYS environment.

 

[taufan99]

Thanks a lot for the update! I don't have to restart map playthrough anymore every time I die. Just type IDDQD and presto!

[Julia Nechaevskaya]

Small functional idea, shamelessly inspired by recent work of @Alaux - a "MDK" cheat. But we probably need a slightly different implementation, i.e. amount of dealt damage must not "push" monster in any direction, but just "kill" it, technically set it's health to zero. AFAIK, there is no got boomed problem in vanilla mechanics, as well as matters no in which sector tag monster is killed (E*M8 and MAP07 scenarios), but still, if monster should be dead for testing purposes, then it should be killed and dropped right where it is placed now.

 

Also, typing MDK making player slightly moving backwards because of D buttons, so it definitely deserves a dedicated key bind. IDMKD trick will work, though.

 

Small example:

Spoiler

 

 

So... Could it be useful somehow? 🤔

[Arsinikk]

So I've recently had a problem with a midi crashing Vanilla, but it playing completely fine in Chocolate Doom and CRL. I finally figured out what it was, as it was a format 0 midi instead of format 1. Vanilla only supports format 0 if it's MUS and not MIDI. Would it be possible for CRL to throw an error message on detecting a format 0 midi?