Porting GZDoom Builder to Linux
- Gustavo6046
- Posts: 137
- Joined: Sat May 13, 2017 3:11 pm
- Location: Brazil
- Contact:
Re: Porting GZDoom Builder to Linux
I'm still seeing quite some progress, though. Well done!
Re: Porting GZDoom Builder to Linux
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.
(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.
Re: Porting GZDoom Builder to Linux
Kappes Buur has the runtimes available on his page: http://www3.telus.net/kappesbuur/BEGINN ... ditors.htm
- axredneck
- Posts: 354
- Joined: Mon Dec 11, 2017 2:09 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Russia
- Contact:
Re: Porting GZDoom Builder to Linux
On Linux i didn't install SlimDX but GZDB works somehow under Wine.ZZYZX wrote:Which effectively results in no one being able to install GZDB
Re: Porting GZDoom Builder to Linux
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.
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.
Re: Porting GZDoom Builder to Linux
Will probably look at OGL version and try to merge.. after all almost everything is already done from what I understand
Re: Porting GZDoom Builder to Linux
I'm sure you'll find someone to help you out if it isn't.
Re: Porting GZDoom Builder to Linux
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
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
Last edited by ZZYZX on Sun Dec 15, 2019 2:47 pm, edited 3 times in total.
Re: Porting GZDoom Builder to Linux
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.ZZYZX wrote:Is there any list of unfinished things?
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.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?..
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.
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.7) threaded texture occasionally loading causes unmanaged segfault in 3D mode
Re: Porting GZDoom Builder to Linux
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.
Thanks for explanation though, as it made me try to disable depth and suddenly find out that everything works as intended.
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...dpJudas wrote: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.