LZDoom 3.87b 11/08 released

Game Engines go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.

Re: LZDoom 3.85 02/29 released

Postby drfrag » Fri Jun 05, 2020 2:17 am

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: LZDoom 3.85 02/29 released

Postby Kamil » Fri Jun 05, 2020 3:29 am

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%
Kamil
 
Joined: 21 Sep 2019
Discord: @Kamil#8122
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia with Vulkan support

Re: LZDoom 3.85 02/29 released

Postby drfrag » Fri Jun 05, 2020 3:47 am

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: LZDoom 3.85 02/29 released

Postby Kamil » Fri Jun 05, 2020 3:50 am

I am using Windows 7 Ultimate. I will try with GZDoom
Results in GZDoom.
OpenGL
RAM - 1 446 704 kb
Physical memory - 51%
Kamil
 
Joined: 21 Sep 2019
Discord: @Kamil#8122
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia with Vulkan support

Re: LZDoom 3.85 02/29 released

Postby drfrag » Fri Jun 05, 2020 5:49 am

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: LZDoom 3.85 02/29 released

Postby Kamil » Fri Jun 05, 2020 7:57 am

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
 
Joined: 21 Sep 2019
Discord: @Kamil#8122
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia with Vulkan support

Re: LZDoom 3.85 02/29 released

Postby Kamil » Fri Jun 05, 2020 9:32 am

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%
Kamil
 
Joined: 21 Sep 2019
Discord: @Kamil#8122
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia with Vulkan support

Re: LZDoom 3.85 02/29 released

Postby drfrag » Fri Jun 05, 2020 1:02 pm

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: LZDoom 3.85 02/29 released

Postby Warden » Fri Jun 12, 2020 12:12 am

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

Re: LZDoom 3.85 02/29 released

Postby drfrag » Fri Jun 12, 2020 9:51 am

Yeah it's fixed for the next release coming out in a few days.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: LZDoom 3.85 02/29 released

Postby Warden » Fri Jun 12, 2020 2:09 pm

Cheers :)
Warden
 
Joined: 24 May 2020

Re: LZDoom 3.86 06/20 released

Postby drfrag » Sat Jun 20, 2020 11:36 am

I've released 3.86.
viewtopic.php?f=1&t=69073
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: LZDoom 3.86 06/20 released

Postby Graf Zahl » Sat Jun 20, 2020 11:56 am

So this is finally the end of the line for both XP and OpenGL 2.x? What will your next version be based on?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: LZDoom 3.86 06/20 released

Postby drfrag » Sun Jun 21, 2020 3:42 am

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?
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: LZDoom 3.86 06/20 released

Postby Rachael » Sun Jun 21, 2020 5:06 am

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

PreviousNext

Return to Game Engines

Who is online

Users browsing this forum: No registered users and 0 guests