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

[Nevander]

So I recently started putting together an epic compilation of stuff for use with Brutal Doom. We're talking my own mix of Doom tracks, the Visor hud, the OpenGL bloom hack, and even more awesome stuff. However, when there's something awesome, there also has to be something bad. I've had this problem before, and I think I posted a reply on a random thread about it and it went nowhere, so I'm going to try again here. Searched for several strings and didn't find a relevant thread.

Basically, the high resolution texture pack (also known as Doom Hi-res Texture Pack or DHTP found at http://dhtp.freelanzer.com/?page_id=17) crashes certain Final Doom maps. The maps in particular are MAP08 - Realm of Plutonia and MAP09 - Stronghold and MAP11 - Storage Facility of TNT: Evilution.

Before I go any further, yes I am using GZDoom but this crash is across both ports since they share the same baseline. I am also using the latest version of everything. The most recent texture pack release and the most recent stable public build of GZDoom.

The crashes happen as soon as the level loads. Opening the console, typing "idclev 09" in TNT for example, and then boom comes the crash. The crash details do not point to much, and only really tells me a bunch of generic crap like this:
"Code: C0000005 (Access Violation - tried to read address 00000000)"

Apparently according to Freelanzer:

The texture brown1 is the texture that crashes plutonia when using zdoom, and gzdoom.
I will look more into why it’s crashing it. And in the near future there will be an updated release containing the fix.
*note this problem does not affect doomsday

But this was back on 2013/02/06 and it's now 2014/08/09 and there have been updates to the texture pack, but it still crashes Plutonia and TNT on those maps in both G/ZDoom. Upon removing the PNG image named "brown1," it still crashes regardless.

This thread claims to have fixed it, but the "fix" mentioned by Nash is not applicable since all the textures in this pack are already PNGs, and the thread is ancient also: http://forum.drdteam.org/viewtopic.php?t=2246&p=19808

However, through my own experimentation, I have found a way to "avoid" the problem in GZDoom at least and still use the texture pack, but the results may not be desirable since you will get massive amounts of stuttering lag caused by texture loading.

I have found that (in GZDoom) having the "Precache GL Textures" option in the Display Options > Open GL Options > Texture Options set to YES was causing the crash problem on each of those maps. Some texture(s) loading before the map is able to begin is crashing those maps for whatever reason or something. Not entirely sure really.

I have not experimented with ZDoom yet.

Sadly it seems the only real fix is to just not use the DHTP with G/ZDoom and do without it.

Also, MAP02 and MAP08 in Plutonia have this weird texture flickering issue happening as well. It's not game-breaking like the above problem but it breaks the immersion of demon slaughtering. You can see it happening on the green/gray wall on MAP02 and the side of the lowering water in MAP08. I'm sure there's more places in TNT/Plutonia.

So I have to ask now... what is up with this texture pack and Final Doom? Why does Doom/Doom II work flawlessly but Final Doom doesn't? Anyone fancy a guess? I'm pretty stumped.

[Hellser]

All of these maps loaded up just fine for me with GZDoom. It seems to be an issue with your setup. Don't know why you'll want to load these texture with ZDoom anyways. Poor software renderer. Also, the flickering texture issue is an issue with the texture pack. Not (G)ZDoom.

Have you tried this without using any of the mods like Brutal Fart Doom and what not? It could be an issue with them and not the texture pack.

Also.. have you downloaded the latest GZDoom like a good boy?

4. Only post bugs and crashes for the most recent version of ZDoom (i.e. not Skulltag, ZDoomGL, GZDoom or anything else). You may also want to check with a recent unofficial SVN build to see if this bug has already been fixed.

I also would like to remind you, that your definition of "Stable Public Build" means "a build that was released 6+ months ago and is already overrun'd with vegetation and bugs." - So verify that you are indeed using the very latest from the link I just gave above. Also as given by your 2.7.1 tag - which means you aren't using the latest.

Plutonia - Map08
Evilution - Map09
Evilution - Map11

Oh, and yes. This runs fine on ZDoom. So again, it must be something buggy with your setup.

[Graf Zahl]

This report is also lacking the most crucial of information, namely a copy of the startup log or the crash log.

This can be anything, even something trivial like using an outdated graphics card lacking the RAM to store the textures. But I have no idea...

[Nevander]

All of these maps loaded up just fine for me with GZDoom. It seems to be an issue with your setup. Don't know why you'll want to load these texture with ZDoom anyways. Poor software renderer. Also, the flickering texture issue is an issue with the texture pack. Not (G)ZDoom.

Have you tried this without using any of the mods like Brutal Fart Doom and what not? It could be an issue with them and not the texture pack.

Also.. have you downloaded the latest GZDoom like a good boy?

4. Only post bugs and crashes for the most recent version of ZDoom (i.e. not Skulltag, ZDoomGL, GZDoom or anything else). You may also want to check with a recent unofficial SVN build to see if this bug has already been fixed.

I also would like to remind you, that your definition of "Stable Public Build" means "a build that was released 6+ months ago and is already overrun'd with vegetation and bugs." - So verify that you are indeed using the very latest from the link I just gave above. Also as given by your 2.7.1 tag - which means you aren't using the latest.

Plutonia - Map08
Evilution - Map09
Evilution - Map11

Oh, and yes. This runs fine on ZDoom. So again, it must be something buggy with your setup.

I don't use them with ZDoom, but I don't have an account at drdteam so I posted here since I know ZDoom and GZDoom share a lot of things. My version of GZDoom is 1.8.2.0 from here. I am positive it is the texture pack causing the problem, because with ANY other custom file I even have, it loads just fine.

The latest version... I assume the latest public official version is the one that I posted because on the page you linked me to, I see this:

These are unofficial Git builds. Remember these builds are beta-quality software - use at your own risk!

I do see 1.9 as late as October of last year in that list of the link you gave, so why hasn't the page I got GZDoom been updated since then? Have every single one of the 1.9 builds been beta builds? I'm honestly confused here.

So in simpler terms, which of the 7z files in that list is the one I should be using for the latest correct and stable version? Thanks.

This report is also lacking the most crucial of information, namely a copy of the startup log or the crash log.

This can be anything, even something trivial like using an outdated graphics card lacking the RAM to store the textures. But I have no idea...

With this particular problem, I didn't think this would be necessary because I know what was crashing the program, just not the fine details of it. Plus the crash stuff GZDoom gave me was less than helpful. I have an AMD Radeon R9 270X with 2GB of VRAM so I doubt that is the problem.

[Blue Shadow]

The latest official release of GZDoom is 1.8.6, which you can get from here.

why hasn't the page I got GZDoom been updated since then?

The reason for that, is because Graf lost access to his site. So, he can't update the page.

With this particular problem, I didn't think this would be necessary because I know what was crashing the program, just not the fine details of it. Plus the crash stuff GZDoom gave me was less than helpful. I have an AMD Radeon R9 270X with 2GB of VRAM so I doubt that is the problem.

No offense, here, but I think it's best to let the developers decide if a crash report or a console log are helpful or not.

[Graf Zahl]

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.

[NeuralStunner]

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

[Nevander]

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.

[Graf Zahl]

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.

[Nevander]

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.

[NeuralStunner]

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!

[Nevander]

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 35 times

Brutal Doom separate configuration:

CrashReport+StartupLog_bd.zip

(24.22 KiB) Downloaded 30 times

[Graf Zahl]

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.

[Nevander]

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.

1. The HQ#X rescaling methods seem to work and look much differently now, worse in my opinion (check the pic below inside spoiler tags).
2. 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.
3. 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.
4. The OpenGL bloom hack no longer works or loads. I've attached the log file from it with the error(s) I got.

---

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.

---

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

[Graf Zahl]

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

---

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.