ZDoom

by **markanini** » Sat Feb 15, 2020 8:26 pm

This bug has been present since the DOS original. Amazing to see it fixed!

by **Graf Zahl** » Sat Feb 15, 2020 2:51 pm

The cluelessly running around zombie should be fixed now.

by **Graf Zahl** » Sat Feb 15, 2020 5:59 am

Don't worry. Finding the cause of that bug was worth it. Now I can investigate how to avoid it.

by **Manuel-K** » Sat Feb 15, 2020 5:55 am

That seems reasonable and I can confirm it on my end. It seems that I've been too fast during my previous tests.

I'm sorry for causing unnecessary confusion.

by **Graf Zahl** » Sat Feb 15, 2020 5:20 am

I think I know what's going on. If you whack the zombie before it fully rises from the grave it never switches to its attacking AI - it stays in its rising-from-the-grave AI, and in that state cannot find any targets. That can be reproduced 100% even without savegames. Of course, if you save after knocking it down it will stay in that phase and aimlessly run around.

In other words: Totally unrelated to the savegame feature, it's a bug from the original game.

by **Manuel-K** » Fri Feb 14, 2020 1:43 pm

Graf Zahl wrote:How precisely do you manage to get it?

The bug?

Hit a zombie with the pitchfork, wait until it's starting to get up again and save when it's almost standing.

by **Graf Zahl** » Fri Feb 14, 2020 1:41 pm

How precisely do you manage to get it?

by **Manuel-K** » Fri Feb 14, 2020 1:26 pm

That's the output with the bug.

Edit: Shouldn't the printf inside the if of UnindexAIState after the assignment to state?

by **Graf Zahl** » Fri Feb 14, 2020 1:22 pm

I'd still like to see what the debug output says which I added this morning.

by **Manuel-K** » Fri Feb 14, 2020 1:03 pm

Graf Zahl wrote:(…) if it happens so frequently on Linux.

I have a 100% bug trigger rate on Windows 8.1. On Linux my rate is a lot lower.

–––

So all in all I've triggered the bug if the engine was compiled by gcc, by clang and by msvc. I'll call that a huge success.

by **Rachael** » Fri Feb 14, 2020 6:11 am

Manuel-K wrote:Does Rachael use gcc or clang?

Clang 6.0, as included in Ubuntu's 18.04 repositories.

Code: Select all

clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

I used it because at the time that I created the build tree, I was attempting to do the Linux port for Raze and Graf was already working on fixing the Mac OS version so it would compile, and I figured we'd get similar results by using similar compilers. (Mac uses Clang exclusively in Xcode, as far as I know)

I'll probably upgrade to Clang 9 at some point, but I have to remove something else from the system first.

by **Graf Zahl** » Fri Feb 14, 2020 5:51 am

_mental_ wrote:
Graf Zahl wrote:Makes me wonder why the compiler creates such different results compared to MSVC.
Thanks to bitfields, e.g. for MSVC sizeof(Blood::XSPRITE) is 80 bytes, for GCC it's 70.

The savegame code overall really needs to be redone. Even when writing binary data it cannot be done as blobs, it needs to write out all fields in a defined fashion so that such architectural differences do not affect the result. ZDoom never had such problems because even with its binary format, every single bit of data was written out separately in a machine independent form.
Of course this also means that bitfields are a no-go.

by **sinisterseed** » Fri Feb 14, 2020 5:48 am

Graf Zahl wrote:This still warrants investigation, if it happens so frequently on Linux. That's a clear sign that the code isn't doing what's to be expected. When it comes to pointer<->integer conversions one has to be careful - some compiler writers seem to treat such things as their playground for unsafe optimizations.

I'll hook up something here and let Manuel test it.

EDIT: done. It now prints some diagnostics when saving and loading. Let's hope this gives us a hint at what's happening here.

Never said it ain't worth investigating

, especially since on Linux it happens constantly. Was just saying that troubleshooting AI glitches can be a pain sometimes, insofar as some originate from vanilla and not necessarily because of a feature that isn't working properly yet.

by **_mental_** » Fri Feb 14, 2020 4:10 am

Graf Zahl wrote:Makes me wonder why the compiler creates such different results compared to MSVC.

Thanks to bitfields, e.g. for MSVC sizeof(Blood::XSPRITE) is 80 bytes, for GCC it's 70.

by **Graf Zahl** » Fri Feb 14, 2020 1:53 am

This still warrants investigation, if it happens so frequently on Linux. That's a clear sign that the code isn't doing what's to be expected. When it comes to pointer<->integer conversions one has to be careful - some compiler writers seem to treat such things as their playground for unsafe optimizations.

I'll hook up something here and let Manuel test it.

EDIT: done. It now prints some diagnostics when saving and loading. Let's hope this gives us a hint at what's happening here.

ZDoom

[0.4.2] [Blood] Enemy state is reset on savegame load

Post a reply

Expand view Topic review: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load

Re: [0.4.2] [Blood] Enemy state is reset on savegame load