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

[Nevander]

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.

[Nevander]

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.

[Graf Zahl]

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.)

[MaxED]

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

---

[Nevander]

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.

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

---

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.