Move to any previous level by using IDCLEV

[JNechaevsky]

This simple trick allows to warp to any previous level by using IDCLEV cheat code. Technically, it's just restarts whole demo if "demowarp" map is below or equals current map. Unfortunately, there is no other way to do this more faster way, since demo is just a record of player inputs, there are no indicators or markers like "here's user exiting the level" or "there's loaded next one".

I've also moved demogotonextlvl to Crispy-> structure: there two special operators now, no need to hide them in depth of g_game.c. Could be useful for future.

It is working fine, except... While testing I have noticed one strange bug with PSPR weapon: https://www.youtube.com/watch?v=w_qTIR6LpKs. Happens on 00:15, for some reason pistol appears right before wipe effect, in very odd position.

[JNechaevsky]

Some investigations regarding pistol appearing:

• It does not related to weapon attack alignment.
• It's not related to initial weapon of level entered as well.
• It happens in uncapped framerate, and the more fps is (especially if vsync is disabled), the higher chance of appearing.
• It's slightly different and less notable in Inter-Doom, and still random - instead of pistol, PSPR weapon is "hidden" for few tics, otherwise I have noted it, since was testing IDCLEV a lot.

Perhaps, it's not that critical, but I really don't want to leave it as is. Not sure where to dig next, though. 🤔
Pistol is a starting weapon in any possible demo, and if it's a visual glitch, then we have properly end/finish current frame before performing crispy->demogotoidclev. Having an early return in R_DrawPSprite while crispy->demogotoidclev could help, but it doesn't seems to be the right way to go.

[JNechaevsky]

Still no luck. I don't understand where the pistol comes from, it can't be playstate desync, but what is it then? Drawing first frame of demo while screen is keeping last one? Dead end.

On top of that, I have tried to double-check by brute-force approach, i.e. by disabling screen wipe in the code and holding "Restart Level" button. And looks likes there is memory leak, have a look at growing amount of memory consumed by crispy-doom.exe. Somewhere near ~550 MB it's silently crashes: https://youtu.be/9n_3xBYqYSg

Oddly, I don't have this leak in ID, despite most of the code is identical. This probably a different topic for investigation already.

How should we proceed then? Technically, this PR is working and ready for review, but turns out, there are two underlying problems beneath it.

[fabiangreffrath]

Strange, I cannot reproduce this. Not the pistol sprite before the wipe and also not the memory leaking. 🤷

[JNechaevsky]

Please try to enable uncapped framerate and disable vsync to get as much fps as possible (~1350 fps in my case). Pistol is not appearing in original capped framerate, and appears extremely rare in uncapped/vsync (165 fps in my case).

[JNechaevsky]

We made deeper investigation with @rfomin yesterday. What is clear now:

• Memory leak, caused by disabling screen wipe was my fault, I did it wrong way by setting wipe = false while next line of code is calling Z_Malloc with PU_STATIC, which is never gets cleared after.
• Pistol sprite seems to be render related issue, i.e. next frame is drawing while previous one is not cleared. Crispy's post_rendering_hook is handling such frame-desyncing issues in various code parts, but here it is not that obvious what to do. Probably worths another investigation and same approach as you did in Woof.

So, in terms of this PR everything seems to be done. My initial idea of keeping original Crispy if (map > gamemap) code led to unnecessary code bloating, but now it's as simple as possible. Cool, he? 🙂