Crash with transfer heights

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Crash with transfer heights

Re: Crash with transfer heights

by Graf Zahl » Tue May 15, 2018 5:51 am

_mental_ wrote: Anyway, it's much better than to lose custom settings regularly.

Absolutely that. I'd rather take a minor inconvenience that needs to be dealt with only once rather than constantly losing information.

Re: Crash with transfer heights

by _mental_ » Tue May 15, 2018 5:39 am

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.

Re: Crash with transfer heights

by Graf Zahl » Tue May 15, 2018 5:29 am

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.

Re: Crash with transfer heights

by drfrag » Tue May 15, 2018 5:26 am

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.

Re: Crash with transfer heights

by Graf Zahl » Tue May 15, 2018 5:17 am

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.

Re: Crash with transfer heights

by drfrag » Tue May 15, 2018 5:08 am

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.

Re: Crash with transfer heights

by Graf Zahl » Tue May 15, 2018 4:54 am

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.

Re: Crash with transfer heights

by drfrag » Tue May 15, 2018 4:20 am

drfrag wrote: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.

Re: Crash with transfer heights

by Rachael » Tue May 15, 2018 2:44 am

Rachael wrote:
_mental_ wrote: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.

Re: Crash with transfer heights

by drfrag » Tue May 15, 2018 2:39 am

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.

Re: Crash with transfer heights

by Rachael » Tue May 15, 2018 2:24 am

Are you sure it's not a graphics card driver crash? I tried -glversion 3.3 and it works fine.
_mental_ wrote:Post a crash report please.
We're not going to get anywhere on this issue without one of these.

Re: Crash with transfer heights

by drfrag » Tue May 15, 2018 1:54 am

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.

Re: Crash with transfer heights

by _mental_ » Tue May 15, 2018 1:01 am

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

Re: Crash with transfer heights

by drfrag » Mon May 14, 2018 12:49 pm

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

Re: Crash with transfer heights

by Graf Zahl » Mon May 14, 2018 12:41 pm

drfrag wrote: 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!

Top