Porting GZDoom Builder to Linux

Any utility that assists in the creation of mods, assets, etc, go here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: Porting GZDoom Builder to Linux

Postby Gustavo6046 » Mon Oct 21, 2019 10:15 am

I'm still seeing quite some progress, though. Well done!
User avatar
Gustavo6046
 
Joined: 13 May 2017
Location: In an urban area in Brazil.
Discord: Gustavo6046#9009

Re: Porting GZDoom Builder to Linux

Postby ZZYZX » Fri Dec 13, 2019 8:38 pm

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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Porting GZDoom Builder to Linux

Postby boris » Sat Dec 14, 2019 3:24 am

Kappes Buur has the runtimes available on his page: http://www3.telus.net/kappesbuur/BEGINN ... ditors.htm
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: Porting GZDoom Builder to Linux

Postby axredneck » Sat Dec 14, 2019 7:41 am

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.
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Sat Dec 14, 2019 7:51 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby ZZYZX » Sat Dec 14, 2019 3:22 pm

Will probably look at OGL version and try to merge.. after all almost everything is already done from what I understand ;)
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Sat Dec 14, 2019 3:34 pm

I'm sure you'll find someone to help you out if it isn't. ;)
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby ZZYZX » Sat Dec 14, 2019 7:54 pm

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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Sun Dec 15, 2019 3:24 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby ZZYZX » Sun Dec 15, 2019 10:49 am

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...
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Previous

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: No registered users and 2 guests