Porting GZDoom Builder to Linux

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
User avatar
Gustavo6046
Posts: 136
Joined: Sat May 13, 2017 3:11 pm
Discord: Gustavo6046#9009
Twitch ID: gustavo6046
Github ID: Gustavo6046
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Location: Brazil

Re: Porting GZDoom Builder to Linux

Post by Gustavo6046 »

I'm still seeing quite some progress, though. Well done!
User avatar
ZZYZX
 
 
Posts: 1379
Joined: Sun Oct 14, 2012 1:43 am
Discord: ZZYZX#1394
Github ID: jewalky
Location: Ukraine

Re: Porting GZDoom Builder to Linux

Post by 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
Posts: 697
Joined: Tue Jul 15, 2003 3:37 pm

Re: Porting GZDoom Builder to Linux

Post by boris »

Kappes Buur has the runtimes available on his page: http://www3.telus.net/kappesbuur/BEGINN ... ditors.htm
User avatar
axredneck
Posts: 285
Joined: Mon Dec 11, 2017 2:09 pm
Github ID: axredneck
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support
Location: Russia

Re: Porting GZDoom Builder to Linux

Post by axredneck »

ZZYZX wrote: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
 
 
Posts: 2860
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by 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.
User avatar
ZZYZX
 
 
Posts: 1379
Joined: Sun Oct 14, 2012 1:43 am
Discord: ZZYZX#1394
Github ID: jewalky
Location: Ukraine

Re: Porting GZDoom Builder to Linux

Post by ZZYZX »

Will probably look at OGL version and try to merge.. after all almost everything is already done from what I understand ;)
dpJudas
 
 
Posts: 2860
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

I'm sure you'll find someone to help you out if it isn't. ;)
User avatar
ZZYZX
 
 
Posts: 1379
Joined: Sun Oct 14, 2012 1:43 am
Discord: ZZYZX#1394
Github ID: jewalky
Location: Ukraine

Re: Porting GZDoom Builder to Linux

Post by 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
Last edited by ZZYZX on Sun Dec 15, 2019 2:47 pm, edited 3 times in total.
dpJudas
 
 
Posts: 2860
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

ZZYZX wrote: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.
User avatar
ZZYZX
 
 
Posts: 1379
Joined: Sun Oct 14, 2012 1:43 am
Discord: ZZYZX#1394
Github ID: jewalky
Location: Ukraine

Re: Porting GZDoom Builder to Linux

Post by 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 :roll:
Thanks for explanation though, as it made me try to disable depth and suddenly find out that everything works as intended.

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.

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...

Return to “Abandoned/Dead Projects”