[2.8pre-1212-g34c4041+] [linux] MD3 models crash video.

[hetdegon]

Since the move to sdl2 a few commits ago, trying to display models cause a video failure. Everything else seems to respond, such as bringing the console and typing "quit" (even if it's not visible), music doesn't stop and no actual segfault or crash is produced, but video stops updating entirely, flashing two frames in a continuous cycle.
Because of this, showing screenshots is not useful because it'd look like a normal frame, and unfortunately it produces no debug output. As long as models aren't displayed, everything else seems to run as usual.

My system is Linux, Ubuntu 64bit with nVidia drivers version 331, the build was self-compiled from git, updated today, although the problem has existed since sometime in January.

I attach this extremely simple pk3 with a model at start which does cause the problem 100% (ignore the content of the wad itself, it was a mere proof-of-concept for a friend, but it's the only thing I have that has a model right at the start without having to spawn it by other means). This pk3 and my main project (fairly model-intensive) work properly in an earlier revision (GZDoom 2.8pre-991-g58a3b86 built on Dec.24th) which is still my main build.

I suspect, because nobody else seems to have run into this problem, that it renders properly on Windows, but alas, I don't have a windows install to work with. I am sorry I can't provide any more useful data for debugging.

[Enjay]

Well, it must be a system or linux build issue because the map plays just fine for me and I can see the model. No crash, just normal play.

[hetdegon]

Ugh, as I suspected. I don't think it's a system issue given that everything has worked properly until that change, and the older build still works as expected, and I know sdl2+gl work properly in this system as well. I guess it's some sort of Linux-only issue. Let's see if someone else running on Linux can confirm it.

[Graf Zahl]

SDL2 had no impact whatsoever on any model related code.

[hetdegon]

I gather as much from the commits at github, but well, it was the most significant change in the engine and it did break linux building for about two commits. I know it's a tenuous link at best, but I am grasping at straws here, the silent failure really gives no hints about what it can be.
I guess I'll have to dust off BuGLe or something. Never liked that thing, but I guess I got no other options if I want to continue development.

EDIT:
This is the closest I got to capturing a screenshot displaying the issue. The whole thing flickers like crazy and I managed to capture it showing both things. this is using this command: ./gzdoom -noautoload -file /home/hetdegon/Games/Doom/GZDOOM/WORK/Resourcery/resourcery.pk3 -iwad /home/hetdegon/Games/Doom/IWAD/DOOM2.WAD -config a.cfg (or, in other words, an empty config with all defaults). The model is not present in what is visible. That makes me guess it happens before the model is even drawn once.

[Edward-san]

I can confirm there's something wrong when using that map. In my case, with my Intel Sandybridge mobile machine, I get the video darkened, except for a strip cutting the screen in half and in diagonal. I have no idea of what's going on, sadly.

[hetdegon]

I noticed the error when firing a certain gun in my bigger project, using md3 projectiles, although this map causes it instantly since the model is in the map. The only possible weirdness that I can think of is that I didn't add matching sprites for the models. I'll check if adding them does anything.

[Kappes Buur]

Well, it must be a system or linux build issue because the map plays just fine for me and I can see the model. No crash, just normal play.

I'm not sure if it helps or not in finding the problem, but as in Enjay's case, it works okay for me also with Windows 7.





The model displays in GZDoom Builder




and in-game



when using gzdoom-g2.1.pre-633-g34c4041.7z or gzdoom-bin-1-8-10.zip

[hetdegon]

Well of course it'd show in DB, it's not a problem with a model that is wrong and causes a crash (as said it worked with the older build), every mod with models will cause it, this was just the smallest thing I had using a model, for the sake of example.

[Graf Zahl]

Two months later and you still haven't either posted a crash log or system specs.

The problem is, this does not crash for anyone else so I have to suspect a broken driver or something like that and without that info I cannot even say anything definitive about that.

[hetdegon]

How was I supposed to give a crash log? because the game continues to run, it's only video that stops working. I said so in the first post, and I quote "Everything else seems to respond, such as bringing the console and typing "quit" (even if it's not visible), music doesn't stop and no actual segfault or crash is produced, but video stops updating entirely, flashing two frames in a continuous cycle."
As for system specs I did mention my video drivers in the starting post, my video card is a GeForce GT630 with 331 drivers, running a 64bit ubuntu 14.10, 4-core AMD64 cpu, 8gb of RAM, not much else to say that could influence the results.
I just didn't want to bump the thread because it seemed very dismissive of the issue, despite Edward confirming it happened to him as well.

Let me stress that absolutely nothing else fails in this machine, and gzdoom used to run fine until the very first commit after christmas, I think I am pretty confident about it not being just a broken system. As of latest git commits the error is still present (with a slight difference, as it now apparently gives time for dynlights linked to the actor using the model to be placed before failing, something it didn't do before.)

Again, the bug doesn't crash the game, it makes video output to stop working. If you fire a gun you can hear it, if you enter the main menu you can hear it, if you open the console it is workable even if blindly. But it just doesn't produce any more video output after that, nothing can be seen but two frames flashing rapidly even if the rest seems to work. There's no gzdoom crash to make a log of. Should I make a video of it?

[Rachael]

Do you have access to a copy of Windows?

If you do, try running GZDoom inside of at least two different virtual machines - one with a copy of Windows, one with a linux distro you are *not* using. (Since you're on Ubuntu, try Fedora)

Since you're using 64-bit Linux, if your processor supports virtualization extensions try the 64-bit versions of the appropriate guest operating systems (but just note that the 32-bit versions will run much faster but will not be as reliable for reproducing the problem as 64-bit guests will).

VirtualBox will be good for this because it will forward your OpenGL to the virtual machine if you enable 3D acceleration. Guest additions are required for this to work so make sure they are installed into the virtual machines as appropriate.

The reason why I am suggesting this is to answer two questions:
1) Does this happen with all versions of Linux?
2) Is this problem specific to any hardware? (This would be revealed with the Windows virtual machine)

I am expecting that if it happens in the Fedora machine and not Windows, then it would be a Linux-specific problem. If it happens in both machines, then it may be a hardware or GZDoom issue. If it happens in neither machine, then more testing will be required (such as possibly a third virtual machine with Ubuntu to see if it happens again and see if the problem can be reproduced inside virtual machines).

Also, when using the Windows version, if possible, cross-compile a copy of GZDoom with MinGW, and also use the Dev builds version (compiled with Visual C++), and see if you get the same results. That at least would answer the question of whether it's a compiler issue. Info on compiling with MinGW can be found here.

If you do not have access to Windows, you can create a Microsoft account and register for an evaluation version of Windows 8.1 Enterprise; it will be quite suitable for this test.

If you do all this and I don't happen to see it in a timely manner, please feel free to poke me.

[hetdegon]

I'll test it that way, then. Also, thanks for replying.
I got win7 32-bit for dual-boot and a XP virtual machine in Virtualbox with guest additions (I use it mostly for occasional usage of GZDoom Builder). I'll also try WINE while at it. I'll test both drdteam's builds and my own build with those 3.
Getting Fedora going shouldn't take much effort, although due to a storm my internet connection is down so I have to install through my phone, and will take about a full day to get it downloaded.
I should be able to report back on Monday with that and the various results, if that's alright.

[VoidMage]

1) Does this happen with all versions of Linux?

What is "a version of Linux" ?
...but if you mean "is it distro specific ?", with near certainty I can answer negatively, given that my distro is a meta one.

I can also confirm Edward-san's results - I've got an integrated intel too and see about the same thing.

Given differing distros, it's also unlikely to be a compiler issue.

[hetdegon]

Thanks VoidMage, more Linux users reporting helps so much.
For now I tested it with WINE and Win7, and it doesn't "video crash" there. Same hardware and drivers in the case of WINE, as WINE is a wrapper running under Linux and not an emulator. Same video driver version in native Win7 32b. I suspected it was a Linux-only issue though, so no surprises here.

(Unfortunately I cannot move development to Windows, all of my custom tools and automation live in Linux, so I barely only use Win for games, not to mention it's far more annoying to set up compilers and everything. Not a possibility. Using WINE with the Windows version under Linux is an option, but it makes I/O excruciatingly slow, so it can be used to play something, but it's unusable for developing.)