Page 2 of 3
Posted: Wed Oct 12, 2016 8:51
However it does not seem to have solved our problem - which I am starting to suspect has to do with pointers more than anything - also the Direct3D backend not being the only (if at all) problem was also proven by when I implemented the live switcher on the Direct3D code, switching it instead to DirectDraw and OpenGL still crashed it.
When the crashing started there were actually two big changes in the setup code.
The first was the D3D addition, the second one the startup window. This is actually the game window, only resized, so it may also be the culprit for the crashing.
Posted: Wed Oct 12, 2016 9:02
Also, is this done or not? Hardware rendered 2D for OpenGL really needs to be in ZDoom so that the palette issues with the HUD on non-Windows platforms can finally be resolved.
And what OpenGL version does this use? Only 3.x core or is it compatible with 2.x as well?
Posted: Wed Oct 12, 2016 10:02
Graf Zahl wrote:Also, is this done or not? Hardware rendered 2D for OpenGL really needs to be in ZDoom so that the palette issues with the HUD on non-Windows platforms can finally be resolved.
It is virtually done. My plan is to hook it up to the Mac/Linux part of GZDoom as well before submitting my gl_swframebuffer branch to GZDoom. As for getting it into ZDoom, this requires something in ZDoom that can boot OpenGL and setup the bindings it requires.
Graf Zahl wrote:And what OpenGL version does this use? Only 3.x core or is it compatible with 2.x as well?
I've targeted 3.0 core, but it could go lower as long as framebuffers, shaders and non-power-of-two textures are available. I don't really have the hardware to test such things.
Posted: Wed Oct 12, 2016 11:00
Well, it doesn't really matter. The shaders on those old cards are pretty weak, I still can remember that my old Geforce 6800 has to fold when doing a simple fullscreen invulnerability effect - with assembly shaders! The frame rate tanked to less than half of what it was without shaders. These were my first tests with shaders and caused me to hold off on them until I upgraded my computer a few years later.
I guess the same will be true for other GL2 hardware as well. It's just that Randi went to great lengths to make the D3D code work even with hardware so weak that it has completely disappeared from the market by now. I believe the oldest he targeted was Geforce 5xxx and equivalent Radeons. Of course that was 8 years ago, so today GL3 should be fine, especially since there is a fallback path (i.e true software rendering.) At some point these people have to realize that with their outdated hardware they are getting nowhere anymore. (Well, it's just too bad that most ports still see this as the baseline to develop for...
On the other hand, if you do not use any more modern features, providing GLSL 2 versions of the shaders should be sufficient, right? Today we can assume framebuffers and NPOT textures on any hardware that supports GLSL.
For the OpenGL init code, since that's already present in GZDoom and mostly separated in its own files so it should be doable with relatively low effort.
Posted: Wed Oct 12, 2016 11:53
Ah, didn't know the 6800 was that poor at shaders. Back then I only really used some shaders for some basic 2D sprite rendering.
I coded the OpenGL version by "emulating" the Direct3D 9 API used with OpenGL calls. The HWTexture class is my version of IDirect3DTexture9 and so on. Only when it became too tricky to emulate did I change what the code was actually doing, which mostly amounted to frame buffer management and switching to using a vertex shader. The shaders are virtually identical to Randi's - in fact, I "coded" them by just search replacing float4 with vec4 and so on.
I'm pretty sure they could be made to work with even GLSL 1.0 if in/out is replaced with varying and texture with texture2D.
About the init code, the biggest problem here is that I'm using Win32GLFrameBuffer as my base class for the DFrameBuffer. I can change the code to not do that, but my interests in the Linux and Mac targets aren't big enough to then change ZDoom's SDLFB and CocoaFrameBuffer classes to inherit from it and do all the testing required. Someone with interest in those platforms would have to do that.
Posted: Wed Oct 12, 2016 17:09
So I played with the new crash handler, and got this message:
Code: Select all
Execution could not continue.
Fatal drawer error: DrawColumnHorizRGBACommand
Good work on the crash handler.
However, seeing that inspired me to try switching to 1-column drawers. Sure enough - problem solved. (Or so it seems...?)
Posted: Wed Oct 12, 2016 20:10
Ah, that message is kind of interesting as it is one of the few C++ commands executing. You can improve the input it writes by adding more to DrawColumnHorizRGBACommand's DebugInfo function, or set a breakpoint in DrawerCommandQueue::ReportFatalError where you can use the debugger to inspect the command, and if r_multithreaded is off you can see the call stack too.
For the map I've been testing, I've gotten errors in DrawColumnRt4AddClamp and DrawWallMasked4. Mine are really weird because they crash in assembly instructions like this one:
vpunpckhwd xmm4,xmm10,xmmword ptr [0FFFFFFFFFFFCC5B8h]
From my limited understanding of assembly, that line is reading data from a static memory address. As the drawers doesn't use any global variables at all this seems to indicate a possible problem with the code generation in LLVM. When I disabled the optimization passes the error went away in DrawColumnRt4AddClamp but resurfaced in DrawWallMasked4 instead. So far I've only seen it with the 4 column drawers, so maybe there's some connection there. You managing to stop a crash completely by avoiding the rt4 family of drawers just strengthens this possibility.
Posted: Wed Oct 12, 2016 20:15
Honestly I don't even know why we're using 4-column drawers anymore at this point. For the palette renderer - sure - it might offer some benefit to ye olde Pentium 3's that nobody even has anymore (except for maybe one or two people).
But Truecolor mode already draws in 4-column sets, by basis of each pixel being 4 bytes long. It offers no performance improvement whatsoever.
Posted: Wed Oct 12, 2016 20:18
The truecolor mode draws 16 bytes in one go using SSE registers. The performance improvement is 4x over the one column versions. With the latest CPUs it could even theoretically do 32 (AVX-256) or 64 bytes (AVX-512) as a single load and store.
Posted: Wed Oct 12, 2016 20:25
Ah, that makes sense to keep them, then.
Well - got another crash, even in 1-column mode, with one map that is extremely bad for crashing both ZDoom and the true-color renderer.
On Str12 in Stronghold, it took a while, but eventually got this error to pop up:
Code: Select all
Execution could not continue.
Fatal drawer error: DrawColumnLLVMCommand
dest_y = 0, count = 3042, flags = 1
Posted: Wed Oct 12, 2016 20:31
3042 pixels tall column? What resolution are you running at?
Posted: Wed Oct 12, 2016 20:35
1440x900 in a window. My guess is it's related to this
, considering the map uses very large transparent sprites.
Posted: Wed Oct 12, 2016 20:39
Didn't Randi fix that one? Although I suppose there's always the chance of being more cases like that one.
Posted: Wed Oct 12, 2016 20:43
Yes, she did, but I am starting to get a bit of a theory that she only fixed them when the entire sprite is offscreen, not thousands of columns tall - but that's without really knowing what she actually did.
Posted: Thu Oct 13, 2016 7:58
* Regarding the 4:1col issue -
Testing with various maps - I am noticing absolutely no difference between invoking the 1col and 4col drawers. The framerate stays the same. This is both using E1M1, and the known trouble spot in Frozen Time.
Frozen Time nets me a whopping 8 fps in that particular spot, using both drawer types. E1M1 gives me about 372 fps.
Still doesn't make a case for abolishing the 4col drawers completely, but I figured that data would be useful to have.