Crash with transfer heights

[drfrag]

I was a bit worried and decided to test transfer heights in my branch with wckywtr.zip. It's advisable to noclip outside of the first room.
https://www.doomworld.com/idgames/docs/editing/wckywtr

There's a crash in the latest SVN with vid_renderer mode 4 when approaching the last pool. Works well in software.
Also i've tested 3.3.2 and software is broken but no crash, GL is fine (works as expected i mean).
My build is fine in software but artifacts in hardware (no crash) may be i missed something.
Edit: mine is fixed, another bad merge and this one was very obvious. I tried to do too much stuff too quickly.
The crash must be due to some later refactoring.

[Graf Zahl]

There's a crash in the latest SVN

Did you really test such an old version?

If not, please give proper descriptions what you actually tested!

[drfrag]

Sorry, i meant latest DRD team devbuid of course: GZDoom-g3.4pre-402-g142368d95-x32.7z.

[_mental_]

The given build doesn't crash for me. The current head is also fine even in Debug.
Post a crash report please.

[drfrag]

Sorry i've done more testing and this is a hardware specific thing, happens on a GL 3.3 card (ATI HD4550) but not on GL 2 hardware. I can't get a crash report since i get a graphics driver has stopped responding message and the game hangs with a white window. All i can say is the old official version and my build don't crash so i think it's a consequence of the refactoring (i ported the transfer heights optimizations). Happens when approaching most of the pools with deep water.

[Rachael]

Are you sure it's not a graphics card driver crash? I tried -glversion 3.3 and it works fine.

Post a crash report please.

We're not going to get anywhere on this issue without one of these.

[drfrag]

Which card? May be it's an ati specific thing then, it's strange that only happens with the recent devbuild. The graphic driver certainly crashes but why? Could be a driver bug only exposed now or nvidia being more tolerant to certain things i dunno.

[Rachael]

Post a crash report please.

We're not going to get anywhere on this issue without one of these.

I hate being a broken record. I'm in a mind to close this report without one.

Even a stack trace would be better than the info you've given us so far, if you're paranoid about your memory dumps. A screenshot of your debugger. Anything.

[drfrag]

I can't get a crash report since i get a graphics driver has stopped responding message and the game hangs with a white window.

I've tried debugging with VS and i get no information, the driver crashes and the game just hangs. I'm no expert, can a bug in a game cause the video driver to crash? No idea but if you're 100% sure it's a driver bug then feel free to close this.

BTW VS CE said it was a 30 day trial and i had to sign in with a MS account, not nice. Also it keeps desperately trying to debug the target ALL_BUILD and i have to debug zdoom with the right mouse button every time. What's more linker errors don't count as errors and i need to check output for them, as i said earlier i don't like this stuff.

[Graf Zahl]

It's really irrelevant what causes it. Normally an app should not be able to hang a driver. But regardless, with the information at hand there's nothing that could be done here.

[quoteBTW VS CE said it was a 30 day trial[/quote]

Yes, that's the price you have to pay for using it for free. It's still better than Apple where you have to pay some $$$ to be able to do "real" unrestricted development.
And why can't you debug ALL_BUILD? That's explicitly been set up as a debug target that automatically handles all dependencies. That's probably the errors you get.

[drfrag]

I get an error message saying 'Unable to start program <path here>\ALL_BUILD'. Successfully debugs the zdoom target but the game hangs and cannot continue.
The linker errors in my branch were genuine but did not show up in errors also very few information there.

[Graf Zahl]

In that case all I can say is that you did something wrong. I have no problems compiling ALL_BUILD without errors and run it. And all I did was start CMake and generate a project.

[drfrag]

I did the same, i compile ALL_BUILD but it won't run (VS 2017). Generic configuration there, Target Name is $(ProjectName) for ALL_BUILD.

[Graf Zahl]

Ok. I cannot verify right now but a few weeks ago I removed some hackish setup script that was doing really bad stuff. It may be that this also performed some setup to make ALL_BUILD usable.

[_mental_]

With removal of those magic CMake scripts ALL_BUILD lost an ability to run main executable directly.
To solve this everything you need to do is to set path to executable as debugging command for ALL_BUILD.
Anyway, it's much better than to lose custom settings regularly. This should be done only once per configuration.