Porting GZDoom Builder to Linux

[Gustavo6046]

I'm still seeing quite some progress, though. Well done!

[ZZYZX]

So a bit related to the previous conversation in this thread, apparently SlimDX is gone from the web...
(or at least the runtime installer)

There is GitHub code though: https://github.com/SlimDX/

Which effectively results in no one being able to install GZDB as for some reason SlimDX runtime installer is not distributed anywhere, and without it, "assembly is not found" and the application silently closes.
This was actually a local issue for me, but it's still bad though.

[boris]

Kappes Buur has the runtimes available on his page: http://www3.telus.net/kappesbuur/BEGINN ... ditors.htm

[axredneck]

Which effectively results in no one being able to install GZDB

On Linux i didn't install SlimDX but GZDB works somehow under Wine.

[dpJudas]

From what I could tell on the SlimDX source code, the real dependency of SlimDX is the C++/CLI runtime it was built on. That would be Visual Studio 2010 C++ runtime or something like that. Ah yes, so good to depend on third party software isn't it?

Edit: GZDB could solve the overall problem by embedding the SlimDX source code into its own (sln files can have both C++ and C# projects in them). No point in forcing people to get it from an upstream that is dead. The only outer dependency SlimDX seems to have is DirectX, which is part of the platform SDK nowadays. Or they could merge in the OpenGL port and fix the outstanding issues.

[ZZYZX]

Will probably look at OGL version and try to merge.. after all almost everything is already done from what I understand

[dpJudas]

I'm sure you'll find someone to help you out if it isn't.

[ZZYZX]

Is there any list of unfinished things?

So far I found these:
1) (fixed) grid was misaligned
2) (fixed) rotated grid would hang up everything if zoomed out (not sure why, probably float precision issues, I just replaced the line-rect clip function entirely)
3) (somewhat fixed) non-x-y aligned lines have issues with being dotted
4) (fixed) line color for two-sided lines looks broken (like 200% darker than it should be)
5) (fixed) it's not possible to turn off linear filtering in 3D mode
6) (fixed) skybox offsets https://i.imgur.com/1ENkzN9.png
7) threaded texture loading occasionally causes unmanaged segfault in 3D mode

Is there anything known that I didn't mention here?

If anything, code is here for now: https://github.com/jewalky/GZDoom-Build ... imgl_merge

[dpJudas]

Is there any list of unfinished things?

The only known unfinished thing is dealing with the finalizers for the GPU objects (texture, vertex and index buffers). The rest is things I somehow managed to break when porting it.

6) skybox offsets https://i.imgur.com/1ENkzN9.png — apparently there are issues with viewport size (render target cannot be larger than GZDB window). Tried to look at glViewport, seems alright. Do you have any ideas by any chance?..

OpenGL shouldn't have a problem with a render target (frame buffer object) larger than the window. The size it renders to is clipped by the intersection between the viewport rect, the scissor rect (if enabled, can't remember if GZDB uses that), and all the textures/renderbuffers in the frame buffer object (FBO). If it puts the window depthstencil buffer into the FBO then that could be restricting it to the GZDB window size.

One other important thing to be aware of is that OpenGL has lower left as its origin in render targets, while Direct3D (and Vulkan) has upper left. I had to flip some things to account for this.

7) threaded texture occasionally loading causes unmanaged segfault in 3D mode

It issues OpenGL calls from a worker thread? If so, that could be solved by doing a SendMessage to the UI thread whenever it is ready to upload it.

[ZZYZX]

Ok, I found the issue. In fact it did not render to the framebuffer at all due to returning really random value from GetFramebuffer if depth was enabled
Thanks for explanation though, as it made me try to disable depth and suddenly find out that everything works as intended.

It issues OpenGL calls from a worker thread? If so, that could be solved by doing a SendMessage to the UI thread whenever it is ready to upload it.

Honestly I have no idea what it issues (haven't tested thoroughly) but I definitely had a crash after switching to 3D mode while still loading textures. I know OGL should not be threaded though, will look into that at some point...