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

[VoidMage]

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.

Given that, it's most likely not drivers, as nvidia and intel both have a variation of this problem.
It's unlikely to be mesa either, as unless you're using nouveau or it's a muxless laptop (and you are actually set in power save mode, so using intel too), nvidia's libGL is in use.

(though for arguments sake it's gcc 4.9.2 here with whatever patches my distro is applying)

Here's a thought: could it be that a portion of GZDoom code is using wrong size of long somewhere ?

[Rachael]

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.

Yeah, that's fine. Thanks for the reports about running it under WINE. It's obviously not a hardware issue.

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.

You can answer derisively if you want, but 1) I am not a "Linux geek" and 2) the message clearly got across anyway, you clearly understood what I meant, so I am not worried about it. If your only goal is to argue over little semantics, then this is not the place where you want to spend your time - and please, grow the hell up.

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.

It is such an issue if one compiler understands it and another one doesn't. The reason why I wanted a MinGW test is because MinGW uses GCC, similar to Linux's build system. If there's something that's giving Linux's GCC grief, the error would be present in MinGW too. It means that the code will have to be looked at again so that it properly compiles under all compilers.

Here's a thought: could it be that a portion of GZDoom code is using wrong size of long somewhere ?

It could be that - or any number of other simple little omissions or errors.

[hetdegon]

My version of GCC is 4.9.1-16ubuntu6. The computer in question is my desktop dev machine, so no laptop or noveau drivers or power-saving features of any kind are getting in the way.
I presume the dev builds are compiled with Visual C, so a GCC hiccup/inconsistency could be a possible culprit. It's worth a check. That'd explain why it works normally on WINE in the same OS.

Since this Fedora install is still 20% done (sorry about that, my home connection is still down), I am going to try to make a separate clone of the repo, then cross-compile with MinGW and see if it explodes. I am kinda getting my hopes up, I hope we can pinpoint the culprit.

Edward-san, if you are following the topic, could you tell us what distro you are using? Just for the sake of gathering more info to discard possibilities.

[Rachael]

My version of GCC is 4.9.1-16ubuntu6. The computer in question is my desktop dev machine, so no laptop or noveau drivers or power-saving features of any kind are getting in the way.
I presume the dev builds are compiled with Visual C, so a GCC hiccup/inconsistency could be a possible culprit. It's worth a check. That'd explain why it works normally on WINE in the same OS.

Since this Fedora install is still 20% done (sorry about that, my home connection is still down), I am going to try to make a separate clone of the repo, then cross-compile with MinGW and see if it explodes. I am kinda getting my hopes up, I hope we can pinpoint the culprit.

Edward-san, if you are following the topic, could you tell us what distro you are using? Just for the sake of gathering more info to discard possibilities.

Yeah, I am thinking it's GCC, as well.

I hope installing Fedora didn't incur you a huge cost on your data plan, that was not what I was asking.

And for political correctness's sake (and so as not to agitate VoidMage any further) I will say it's not at "fault" per se just that it does things "differently." Still, those differences have made it harder for all of the ZDoom developers keeping both ZDoom and GZDoom compatible with Linux and Mac.

You are correct - they are compiled with Visual C++. Most warnings it gives are suppressed on compiling because they're a bit spammy, and it often takes more time to show the messages than it does to just skip past them and go right to the final product, which usually works fine in the end.

[Graf Zahl]

I doubt it's a 64 bit portability issue with 'long' since I have been avoiding that data type like the plague. There's nothing worse than a type whose size is not guaranteed.

[VoidMage]

To clarify: I don't consider myself "a Linux geek", it's just that "Does this happen with *all* versions of Linux?" can't be given any reasonable answer.
Even if you'd restrict it to "well known distros that meet GZDoom build reqs (so at minimum OpenGL 3.0 and available FMOD)", that's still too many combinations to reasonably test.

Oh, and just for the kicks I've built GZDoom with clang - no noticeable change (well, except for some minor wrt. compiler warnings).

[Rachael]

To clarify: I don't consider myself "a Linux geek", it's just that "Does this happen with *all* versions of Linux?" can't be given any reasonable answer.
Even if you'd restrict it to "well known distros that meet GZDoom build reqs (so at minimum OpenGL 3.0 and available FMOD)", that's still too many combinations to reasonably test.

I think trying one or two different compiler combinations can at least give some reasonable answer if there was a recent GZDoom change that GCC or its header files do not like. As far as I know, it has worked just fine up until this problem came up, whatever was changed.

This is also why I suggested trying Fedora - it is architecturally different in terms of base system layout and it also sources its packages differently than Debian or Ubuntu. If the problem can be reproduced there, and in MinGW as well, then there's just something that was done recently that GCC just doesn't like.

The point is to narrow the testing to a few key points, because if we tried every single distro with every single processor and architecture and every single different kernel, we'd be tracking it down for years, and such redundancy is really not necessary.

If that is the case, then the second thing we have to try to find is "when" it broke - and that means going through GZDoom's git to try and find a version that worked fine. Hopefully it's not a recent GCC change that's causing this because that would be even more painful to pin down.

[hetdegon]

Oh I can answer that. The very last version that worked properly was "GZDoom 2.8pre-991-g58a3b86 - 2014-12-21 13:49:23 +0100 - SDL version", then it moved to SDL2, linux building broke for two commits, and then this happened as soon as it built again.

[Rachael]

Oh I can answer that. The very last version that worked properly was "GZDoom 2.8pre-991-g58a3b86 - 2014-12-21 13:49:23 +0100 - SDL version", then it moved to SDL2, linux building broke for two commits, and then this happened as soon as it built again.

Then it looks like I am gonna be building a Linux setup soon. I think that pretty much answers the Fedora question, too.

[Edward-san]

Linux guys, I need you to check this:

reset the gzdoom git repository to commit c39e962fd59c08b98ccf55a3054c6d4eb1d54daa , which merged the zdoom SDL2 changes, then apply this patch I attached (it's the unification of the commits I did to fix gzdoom SDL2) . Build this gzdoom and test it with the example wad. Is it still broken? I can't see the model anymore, but the map runs fine ... I wonder if I accidentally disabled the models.

BTW: I'm on Ubuntu 14.04 x64, running on a laptop with intel i3 + hd 3000 mobile.

[hetdegon]

Alas, proceeded to checkout and reset from a fresh clone, applied the patch, compiles fine with it, but still causes the same error.
Without the patch it's one of those two commits I mentioned where it wouldn't build, I recognize the error from then.

[Edward-san]

This was an attempt to understand the issue. It seems I need to check the gzdoom code without merging the SDL2 branch (ie, manually merge zdoom changes into gzdoom without SDL2 changes). I'll tell you which code changes must be done to test it again.

[Graf Zahl]

Can you retest with the next devbuild? I'm not sure if that is at play here but there was definitely a problem with model vertex buffers and screen resolution changes.

[hetdegon]

It works again!
Tested it with the test map up there, my own large project and a few other mods using models. All work as they should again! (and it seems a bit faster than before? might be my memory playing tricks on me, but my project's model-based effects seems to run smoother now)

Thank you looking back at it! this means a full year of work in that project didn't go to waste after all. I can finally resume it in the engine I wanted for it. Sincerely, thank you so much.

[Edward-san]

Wow ... I can confirm it started working again! Thank you so much!