Welcome to the ZDoom Forums!

by **Nevander** » Fri Aug 22, 2014 9:21 am

Graf Zahl wrote:Should be no problem. The precise time when an official build is made is mostly arbitrary. Are you saying that pre-496 has fixed the crash you experience? I guess I know then what was the cause.

As for your other issues:

- the old HQnX code is back in. I have to wonder myself why both are offered under the same name as the results are quite different.
- GLEW is gone, but I the replacement won't be any better as there is no more GL 2.x code for QEffects to use. It still crashes. I didn't do the replacement for any stability reasons, it was just that GLEW has some serious design flaws (adds a large DLL, does not work well with OpenGL core profile, always defines every single constant and function that was ever introduced to any extension - I now use a loader made with GLLoadGen that only adds 12kb of EXE file size and only defines the stuff I need - OpenGL 3.3 core plus two extensions plus glBegin/glEnd which I still need on older hardware.)

Basically I just wanted to find any build previous to the new HQnX code and to the new DLL extension but after whatever was done to fix the crash with DHTP (whatever it may have been). It just so happened that pre-496 is the perfect version for me (so far). If I run across any new problems, I'll most likely just begin a new thread over at DRDTeam and explain it there.

And good to hear about the changes. I love the old HQnX code, really defeats the purpose of high res sprites since it does it for you in-game and live (no offense to the creators of that sprite project that is going nowhere

). Also, nice to hear that the way the GL code is used is being optimized. The new way sounds much better than GLEW, just from what you've said here.

I'm sure at some point in the future there won't be a need to stay in the past and I'll update to the newest version when that time comes. May be soon since I only need or want the bloom stuff with my BD configuration. Standard Doom is always better with no enhancements apart from the really obvious stuff like arachno soundfont tracks, smoother animations (from Perkristian) or SmoothDoom (which is great by the way), higher quality vanilla sfx (also from Perkristian), and more. The only thing that was holding me from using the newest version for my standard GZDoom was the HQnX code, which is now reinstated.

Thanks again Graf.

MaxED wrote:If only we had QEffectGL features INSIDE of GZDoom, with ability to change their settings from acs...
Spoiler: That would be

That picture made me smile after reading the spoiler tag text. Brilliant. And I agree. It would be awesome to have them build into GZDoom as features instead of hacks.

by **MaxED** » Fri Aug 22, 2014 2:28 am

If only we had QEffectGL features INSIDE of GZDoom, with ability to change their settings from acs...

Spoiler: That would be

by **Graf Zahl** » Fri Aug 22, 2014 1:25 am

Should be no problem. The precise time when an official build is made is mostly arbitrary. Are you saying that pre-496 has fixed the crash you experience? I guess I know then what was the cause.

As for your other issues:

- the old HQnX code is back in. I have to wonder myself why both are offered under the same name as the results are quite different.
- GLEW is gone, but I the replacement won't be any better as there is no more GL 2.x code for QEffects to use. It still crashes. I didn't do the replacement for any stability reasons, it was just that GLEW has some serious design flaws (adds a large DLL, does not work well with OpenGL core profile, always defines every single constant and function that was ever introduced to any extension - I now use a loader made with GLLoadGen that only adds 12kb of EXE file size and only defines the stuff I need - OpenGL 3.3 core plus two extensions plus glBegin/glEnd which I still need on older hardware.)

by **Nevander** » Thu Aug 21, 2014 7:10 pm

I hate to double post this but I've hit another problem... it's more of my problem now than an *actual* problem with anything.

Apparently the version of GZDoom that fixes the DHTP crash (version 1.8.6) that this entire thread was about is also the version that introduced the new (and ugly IMO, no offense) texture resize methods that only affect some sprites and the font. Refer to the post a few back to see what I mean. So now I'm forced to choose between using a version that fixes the crash problem but also has some bad HQnX going on for my tastes. You might say well, just wait for it to be changed to the old way which you like better since I read from Graf it was going to be, or could be.

There's a problem there too. Seeing as how any fix to this would be made in a version 2.x release, that means that any version such as this will be using the new loader library "glew32.dll" which conflicts with and breaks the OpenGL bloom or QEffects hack for GZDoom and other applications. Then you might say well just ditch the bloom, it's kinda ugly or overdoes it anyway. While I agree to an extent, with it on and tweaked just right looks pretty badass. This is why I wanted to find a version that fixes the DHTP crash so that I can enjoy the entire original Doom experience with new and amazing effects such as the bloom, high res textures, Brutal Doom, high quality redone music, the visor mod for BD, and more.

However now this is troubled by the fact that any version older than 1.8.6 will crash in Final Doom and any version higher than it (that I know of) will not work with the bloom hack and has the different resizing methods. Bummer. But there's some good news! I found the dev build mentioned that started the HQnX thing with the different code, so I tried the one directly previous; gzdoom-G1.9pre-496-gf96f4cb.7z.

So my final question of this thread is: would there be anything wrong with using this dev build as replacement for a stable release? Are there any major bugs in that build?

Thanks again though for all your help guys.

by **Nevander** » Wed Aug 20, 2014 10:32 pm

Graf Zahl wrote:Here's some comments:

Yes, it's a known issue. The HQnX assembly code that only worked under Windows had been replaced by a C-version, but apparently it's of lesser quality. I'll have to dig out the old code again so that under Windows it can be reactivated.

I haven't experienced those. Are you using any form of hires textures, either auto-scaled or loaded when experiencing this? And if so, what kind of hires textures?
I wouldn't be surprised if this was caused by the C-based HQnX code which is quite a bit slower than the hand-optimized assembly of the old version

Probably the same, but Brutal Doom loads a lot more resources.

No, and this can't be changed back. That hack depends on how OpenGL rendering is set up - it fails with any kind of loader library - and GZDoom now uses GLEW for that. I also believe that the hack library is restricted to OpenGL 2.0. GZDoom 2.0.x, however, requires at least GL 3.3, it is also fully shader based (no fixed function rendering at all!) and on modern hardware supporting GL 4.4 features, it will run in an OpenGL core profile (the only non-core code in the entire engine is the fallback rendering for older cards, that's a 6-line function.)

It was post 1.8.6, but I already had planned to reinstate the old code due to these problems, but for the betas it was more urgent to get them in a working state.

Good to know, though, that it won't crash anymore, so it looks that problem already got addressed since the 1.8.2 release.

Thanks for all this information. Very useful and informative, as well as interesting.

I will most likely try versions between 1.8.2 and 1.8.6 to find a version that works for me, that plays well for my setup, doesn't crash with DHTP, and that still allows the bloom hack. The bloom hack is one my main points of interest for my Brutal Doom configuration, along with the DHTP and plenty of other mods. My plan really ideally was to create a "backup plan" in the event the new Doom flops. Really hope it doesn't but I have my doubts as I'm sure many other hardcore Doomers have.

To be honest I don't actually use the DHTP with standard GZDoom. Instead I use trilinear texture filtering and HQ4X, which sometimes actually looks better to my eye. However in Brutal Doom, I just simply must use DHTP. Adds that extra layer of epicness to it.

I suppose with this, we can consider this thread "done" or rather nothing more to add. Thanks again Graf! Keep up the great work with GZDoom.

by **Graf Zahl** » Wed Aug 20, 2014 3:51 am

Nevander wrote:
Graf Zahl wrote:Ok, but I can't do much with 1.8.2 crash logs anymore. Can you re-run the test with the 2.0.02 beta I just released a few hours ago? For that one I still have all debug info.
Sure, will do. I'm an AMD user as well so I will let you know if I run into any problems here also.

UPDATE: I tested everything that I would think would make any kind of difference and I have good news and bad news. The good news is, zero crashes with anything I tested. The DHTP did not crash any levels in TNT or Plutonia. I IDCLEV'd my way through each IWAD and nothing happened. The bad news is, there seems to be some new issues that I've noticed. I'll just list them here. Note I don't know what version could have made these change between 1.8.2 and 2.0.02.

Here's some comments:

The HQ#X rescaling methods seem to work and look much differently now, worse in my opinion (check the pic below inside spoiler tags).

Yes, it's a known issue. The HQnX assembly code that only worked under Windows had been replaced by a C-version, but apparently it's of lesser quality. I'll have to dig out the old code again so that under Windows it can be reactivated.

[*]I'm getting very small lag spikes whilst playing that I did not before. This is without any custom files loaded. I noticed this on MAP02-Well of Souls in Plutonia.

I haven't experienced those. Are you using any form of hires textures, either auto-scaled or loaded when experiencing this? And if so, what kind of hires textures?
I wouldn't be surprised if this was caused by the C-based HQnX code which is quite a bit slower than the hand-optimized assembly of the old version

[*]Brutal Doom seems to lag even more than it did before for whatever reason. This is with the DHTP loaded as well. On 1.8.2 it lagged for me a lot less with the same exact settings.

Probably the same, but Brutal Doom loads a lot more resources.

[*]The OpenGL bloom hack no longer works or loads. I've attached the log file from it with the error(s) I got.

No, and this can't be changed back. That hack depends on how OpenGL rendering is set up - it fails with any kind of loader library - and GZDoom now uses GLEW for that. I also believe that the hack library is restricted to OpenGL 2.0. GZDoom 2.0.x, however, requires at least GL 3.3, it is also fully shader based (no fixed function rendering at all!) and on modern hardware supporting GL 4.4 features, it will run in an OpenGL core profile (the only non-core code in the entire engine is the fallback rendering for older cards, that's a 6-line function.)

Spoiler:
The HQ#X methods now produce a choppy outline as if they are going along the pixels of the original sprite instead of creating a smooth edge like my old version does. This is kind of a big problem for me because I love the way the HQ4X handles sprite edges. Could you possibly recall which GZDoom version after 1.8.2 made this change?

[/quote]

It was post 1.8.6, but I already had planned to reinstate the old code due to these problems, but for the betas it was more urgent to get them in a working state.

Good to know, though, that it won't crash anymore, so it looks that problem already got addressed since the 1.8.2 release.

by **Nevander** » Tue Aug 19, 2014 5:09 pm

Graf Zahl wrote:Ok, but I can't do much with 1.8.2 crash logs anymore. Can you re-run the test with the 2.0.02 beta I just released a few hours ago? For that one I still have all debug info.

Sure, will do. I'm an AMD user as well so I will let you know if I run into any problems here also.

UPDATE: I tested everything that I would think would make any kind of difference and I have good news and bad news. The good news is, zero crashes with anything I tested. The DHTP did not crash any levels in TNT or Plutonia. I IDCLEV'd my way through each IWAD and nothing happened. The bad news is, there seems to be some new issues that I've noticed. I'll just list them here. Note I don't know what version could have made these change between 1.8.2 and 2.0.02.

The HQ#X rescaling methods seem to work and look much differently now, worse in my opinion (check the pic below inside spoiler tags).
I'm getting very small lag spikes whilst playing that I did not before. This is without any custom files loaded. I noticed this on MAP02-Well of Souls in Plutonia.
Brutal Doom seems to lag even more than it did before for whatever reason. This is with the DHTP loaded as well. On 1.8.2 it lagged for me a lot less with the same exact settings.
The OpenGL bloom hack no longer works or loads. I've attached the log file from it with the error(s) I got.

Spoiler:
The HQ#X methods now produce a choppy outline as if they are going along the pixels of the original sprite instead of creating a smooth edge like my old version does. This is kind of a big problem for me because I love the way the HQ4X handles sprite edges. Could you possibly recall which GZDoom version after 1.8.2 made this change?

And here is my log from the OpenGL bloom hack. I think I recall reading that the hack no longer worked but I didn't read it thoroughly.

QeffectsGLlog.txt: (2.43 KiB) Downloaded 34 times

And also here are screenshots of what the DHTP still does on Plutonia MAP02. I assume the other problems still happen as well.

Spoiler:
Problem 1 (three frames)
Frame 1: http://imgur.com/KXMfYpo
Frame 2: http://imgur.com/gjM1Ozw
Frame 3: http://imgur.com/oqCGr9W
Extra: http://imgur.com/NGAbWvN

by **Graf Zahl** » Tue Aug 19, 2014 4:11 pm

Ok, but I can't do much with 1.8.2 crash logs anymore. Can you re-run the test with the 2.0.02 beta I just released a few hours ago? For that one I still have all debug info.

by **Nevander** » Tue Aug 19, 2014 4:04 pm

Okay before I update my GZDoom, I decided to go ahead and run some tests with two different configurations to try and help you guys (although my problem was most likely solved somewhere after 1.8.2 considering the above) so I have attached two files. One has the zipped reports of GZDoom with some custom files (and of course the DHTP) and then the other is the zipped reports of my standalone Brutal Doom configuration that I have set aside separate from standard GZDoom since I enjoy playing it in its own way.

Strangely enough, Plutonia decided to crash on me in the very first map (Congo) instead of later in MAP08 where it usually would. Anyways, hope this interest you guys who have been following this useless thread. Let me know if you spot any red flags that instantly throw up the "yep, just update GZDoom" line.

Thanks.

Standard GZDoom logs with some custom files:

CrashReport+StartupLog_gz.zip: (25.37 KiB) Downloaded 36 times

Brutal Doom separate configuration:

CrashReport+StartupLog_bd.zip: (24.22 KiB) Downloaded 30 times

by **NeuralStunner** » Mon Aug 18, 2014 8:56 pm

The beta warning is a standard disclaimer, but its wording tends to scare people off.

Dev buillds are typically just as good as officials. Sometimes better!

by **Nevander** » Mon Aug 18, 2014 7:06 pm

Graf Zahl wrote:Please re-check this with a recent development build, and if it still crashes, post the crash log and your startup log. You get that with starting 'GZDoom +logfile log.txt'.

Regarding compatibility, the KDiZD issue was an isolated occurence, so no need to worry. However, if you insist on using an old version, no bugfix is ever going to help you.

Alright will do. Thanks lots for the assistance.

I'll post back if I get more crashes with DHTP or anything for that matter, but I'm most likely going to make an account at DRDTeam so I'll be posting over there now if I get a GZDoom specific crash/bug.

I'll also be checking this board often to see new released (actual) versions. I've had bad experiences with beta test stuff. One of the things that's got me nervous about the new Doom beta.

by **Graf Zahl** » Mon Aug 18, 2014 5:29 pm

Please re-check this with a recent development build, and if it still crashes, post the crash log and your startup log. You get that with starting 'GZDoom +logfile log.txt'.

Regarding compatibility, the KDiZD issue was an isolated occurence, so no need to worry. However, if you insist on using an old version, no bugfix is ever going to help you.

by **Nevander** » Mon Aug 18, 2014 5:03 pm

I'm guessing since this being put into closed bugs and feedback given that it isn't crashing for others means it would be pointless to upload my logs, or could they still be of use to see what exactly is causing my particular crashes? Otherwise I will go ahead and upgrade my GZDoom files to 1.8.6 instead of my current 1.8.2. One question remains though, I've had trouble in the past with certain PK3s/WADs not working in later versions, namely Knee-Deep in ZDoom didn't work in an older version of GZDoom I had, so I had to find an updated version (v12) of KDiZD to be able to play it in 1.8.2. The question is could this happen with 1.8.6? I'd hate to change versions and find out half my WADs and PK3s don't work anymore with nobody to fix them.

by **NeuralStunner** » Mon Aug 18, 2014 10:12 am

The "crash stuff" isn't meant to be useful to end-users. It's for developers to trace problems with. (And yes, you're supposed to upload the whole "report" zip file. I keep seeing people that pull out the crash log by itself, which is useless without the rest.)

by **Graf Zahl** » Mon Aug 18, 2014 1:28 am

Nevander wrote: just not the fine details of it. Plus the crash stuff GZDoom gave me was less than helpful.

But it's the fine details and the 'less than helpful' stuff that would give me some idea what happens, since it doesn't crash for me.

Welcome to the ZDoom Forums!

[2.7.1] Crash: DHTP crashes certain levels of Final Doom

Post a reply

Expand view Topic review: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom

Re: [2.7.1] Crash: DHTP crashes certain levels of Final Doom