LZDoom 3.88b 02/26 released

[drfrag]

But have you used the OpenGL renderer? And is that the devbuild i linked? Which tool? With the task manager i get a much higher memory usage and with only one decimal. Press Ctrl+Alt+Del to launch the task manager and play for a few minutes in a window to let some monsters die, i can't test it myself becouse i don't have enough ram. Please test with the devbuild i linked and the OpenGL renderer. If there are no ram problems this could be a serious engine bug but it's unlikely.
Edit: now i think you're seeing ram usage at the start of the level and i want to know if it keeps leaking memory after playing for a while. You said before it crashed after some time. The old LZDoom stabilizes around 900 MB the new version and GZDoom crash running out of ram unless the devbuild i linked fixes the issue which is unlikely, if it still crashes or ram usage is very high must be a mod bug.

[Kamil]

I am using OpenGL.
Yes. I am using task manager. Now the results are as follows: LZDoom - RAM: 1 373 100 kb. Physical memory - 44%

[drfrag]

Thanks. I thought you were on windows 10, for me it uses more ram. So now it doesn't crash? If you could compare with GZDoom it would be even better.

[Kamil]

I am using Windows 7 Ultimate. I will try with GZDoom
Results in GZDoom.
OpenGL
RAM - 1 446 704 kb
Physical memory - 51%

[drfrag]

Seems it makes no difference and the crash happens randomly after a while, looks like there's a memory leak in the garbage collector.
Here memory consumption rises up to 2 GB several times and then goes down to 700 MB, and once to as low as 200 MB. That's okay but when i tried to quit and usage was still relatively low it skyrocketed and freezed the machine for 15 minutes. It was so badly frozen that the task manager didn't even update (it showed around 1.4 GB as last value). I clicked on the window several times and luckily the dialogue to terminate the process appeared and i managed to kill it but only after the screen went black and the desktop came back again. To me looks like a critical bug but i could be wrong of course. And since when does this happen?
Edit: one thing i've noticed is that ram usage keeps increasing even when the game is paused.

[Kamil]

It appeared not so long ago. When I used GZDoom (before version 4.3.3). I did not notice problems with RAM. However, when I installed 4.3.3, problems with RAM started. And some versions of dev build LZDoom had problems with RAM.

[Kamil]

I got an error in LZDoom again. Here are the results now
OpenGL
RAM - 3 492 240 kb
Physical memory - 73%
Could not malloc 1368 bytes


However, I checked dev build LZDoom on June 4th (lzdoom-x64-3.85-115-gaf1028179.7z) and did not notice any problems. I looked at the task manager. Results. OPENGL
RAM - 571 060 KB
Physical memory - 42%

[drfrag]

It's a badly broken mod, it's a mix of decorate and parts of other ZScript mods and declares ZScript version 4.1.3 but uses a lot of deprecated functions and a few of the latest and greatest ones. It's extremely slow too well below 1 fps here. It doesn't run on anything lower than 4.3.1 and LZDoom just happens to use less ram and it doesn't crash.
The occasional huge increase in ram usage on exit or in the middle of the game is suspicious but i don't think this is an engine bug. The extra ram usage in GZDoom must be due to some different new things or how things work now, the VM is the same.

[Warden]

The "Spawn Item Drops on the Floor" compatibility flag appears to be broken in LZDoom 3.85, can anyone else confirm this?

[drfrag]

Yeah it's fixed for the next release coming out in a few days.

[Warden]

Cheers

[drfrag]

I've released 3.86.
viewtopic.php?f=1&t=69073

[Graf Zahl]

So this is finally the end of the line for both XP and OpenGL 2.x? What will your next version be based on?

[drfrag]

Sure and for the classic ZDoom backends and video code. I forked GZDoom around august last year and then i merged all my stuff and i've been merging with GZDoom master. I expected it to be easier to maintain but it hasn't been too complicated either. Maintaining the old branch was becoming hard and risky and compatibility was decreasing. And it wasn't worth. My idea is to keep supporting 32 bit but i don't care much about the number of users, i think there are still people on 32 bit here, but more about the performance. I'll make some testing on the old Rachael's laptop clone (Pentium M). Blzut3 wants to keep it and i'd like to know what randi thinks, ZDoom always had low system requirements. Do you plan to remove something else?

[Rachael]

I think the number of people who will lose out due to GPU issues is far greater than the numbers who will lose out due to not having 64-bit support. It's been around for well over 15 years, so there will be a far greater number of people who will have no problem with modern GZDoom if it's configured properly for their system.

If you want the port to remain relevant, sure keep 32-bit, but I'd put a much bigger focus on the SoftPoly renderer. Originally I had in mind that if OpenGL initialization failed, that GZDoom would set a few defaults (but not the actual CVars) to compensate for the loss of speed with SoftPoly. For instance - possibly set vid_rendermode to 1 (software renderer) and possibly set vid_scalemode to 1 (which in modern GZDoom means 'go to the lowest available scaling'). The reason I have never done this though is because I had never gotten around to coding a failure routine for OpenGL. For the new LZDoom this would probably be perfect as just the default - not even requiring said check.

Your port - but this is just my mental rambling about it... take it for what you will.