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

Post by axredneck »

Joshua Ashton says that alpha channel works in GZDB with D9VK
https://github.com/Joshua-Ashton/d9vk/i ... -524986278
Talon1024
 
 
Posts: 374
Joined: Mon Jun 27, 2016 7:26 pm
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support
Contact:

Re: Porting GZDoom Builder to Linux

Post by Talon1024 »

I think it's time for everyone involved to catch up with progress so far:

I have been working on removing ScintillaNET and Windows API calls from GZDBBF in my fork.

In terms of taking care of ScintillaNET, I have so far added #if/#else/#endif directives to ScriptEditorPreviewControl for conditional compilation on Windows and Linux, so that Windows can take advantage of ScintillaNET and Linux/Mac can use a plain jane TextBox control as suggested by boris a while back.

One big problem I've been having is that I can't open the Preferences dialog in the Visual Studio 2019 Community Winforms designer. I would like to re-do the tab for the script editor configuration on Linux so that it works better with the TextBox control on Linux/Mac.

As for Windows API calls, I don't know what SendMessage does, and I don't know if there's an easy way to replace it for Linux and MacOS.

In the past, I also re-wrote the file lock checking code so that it would work on Linux. I'm not sure about MacOS, but Linux exposes records of locked files using the /proc/locks file.

dpJudas has made some amazing progress on his OpenGL port of GZDBBF. I don't know whether he's finished with the OpenGL port or not, but it's definitely a step in the right direction. It uses a custom native library for OpenGL support. I did suggest using OpenTK in the past, however.

gdm has also been working on an OpenGL version of GZDBBF. In the "still new what did you do" thread, he posted about how he has been converting HLSL shaders to GLSL. I took a quick look at his fork, and it looks like he is using OpenGL.NET, which I don't think is very well maintained.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

Talon1024 wrote:I did suggest using OpenTK in the past, however.
I don't see how OpenTK bindings help you as it won't let you host the (OpenGL) control as a child of the winforms controls. If the plan is to no longer depend on winforms you're almost at the point the point of rewriting the entire application.

About porting the shaders to OpenGL, since my fork already renders the entire app with OpenGL the shaders are already converted.
User avatar
phantombeta
Posts: 2084
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

Re: Porting GZDoom Builder to Linux

Post by phantombeta »

dpJudas wrote:
Talon1024 wrote:I did suggest using OpenTK in the past, however.
I don't see how OpenTK bindings help you as it won't let you host the (OpenGL) control as a child of the winforms controls. If the plan is to no longer depend on winforms you're almost at the point the point of rewriting the entire application.
OpenTK is supposed to come with an OpenGL WinForms control, I believe. Wouldn't it work here?
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

phantombeta wrote:OpenTK is supposed to come with an OpenGL WinForms control, I believe. Wouldn't it work here?
Got any link for that or is it simply hearsay?

Let me put this a different way. There seems to be some misconception here that a 3rd party OpenGL assembly in itself is enough. Unless they can integrate with the Linux implementation of winforms they can't be used (without rewriting GZDB). IF you can find one that can, which I don't think you can, then I can simply look at how it did the integration and copy it. I'm doubting it because it would mean I missed something big when looking at the source code of mono's winforms - or they are doing some major hack to make it work.
Talon1024
 
 
Posts: 374
Joined: Mon Jun 27, 2016 7:26 pm
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support
Contact:

Re: Porting GZDoom Builder to Linux

Post by Talon1024 »

I believe this is what phantombeta is talking about.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

Thanks. As predicted, a nasty hack: https://github.com/opentk/opentk/blob/0 ... rol.cs#L57

It will do the trick though. I'll update my fork to do the same.
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: Porting GZDoom Builder to Linux

Post by boris »

Talon1024 wrote:One big problem I've been having is that I can't open the Preferences dialog in the Visual Studio 2019 Community Winforms designer. I would like to re-do the tab for the script editor configuration on Linux so that it works better with the TextBox control on Linux/Mac.
Not sure if it applies to VS 2019, but older versions couldn't edit forms when you've set your project to x64. If that's the case for you just set to x86 and recompile, then you should be able to edit forms.
Talon1024 wrote:In the past, I also re-wrote the file lock checking code so that it would work on Linux. I'm not sure about MacOS, but Linux exposes records of locked files using the /proc/locks file.
All the file locking if because of resource files, right? Wouldn't it be possible to load all files into memory at startup and then load the resources from there, leaving the file on disk alone? That way you could ditch the locking completely. Of course that would increase the memory consumption, and there'd have to be a way to handle when writing the resources back to disk.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

I got my branch to build with mono: :D





There are some outstanding issues, such as no raw mouse implementation (can't pan around in 3d mode). I also disabled devil and scripting in a somewhat nasty way. However, assuming someone ports over those parts you'd more or less having a functioning Linux version of GZDB. :)

Building C# was also a complete nightmare that forced me to use the msbuild tool from mono. Project management in C# is also a sad joke, so I duplicated all the project files to set the right defines and post build rules for a successful build. I'm sure some Microsoft masochist can get the .vcproj XML abomination to do it with one set of project files, but I'm not signing up for that!
User avatar
Marisa the Magician
Posts: 3886
Joined: Fri Feb 08, 2008 9:15 am
Preferred Pronouns: She/Her
Operating System Version (Optional): (btw I use) Arch
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia
Contact:

Re: Porting GZDoom Builder to Linux

Post by Marisa the Magician »

Nice. So how would one go about building this?
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

apt-get install libmesa-gl0 or smt like that (can't remember the name of the package that has GLX - not in linux right now to check)
apt-get install mono-complete (might not be enough, not sure. if it doesn't give you msbuild then you may have to grab packages directly from the mono project)
apt-get install libx11-dev
apt-get install g++
make

That's pretty much it, I think.
polyzium
Posts: 12
Joined: Wed Aug 14, 2019 3:14 pm
Graphics Processor: nVidia with Vulkan support
Location: Moscow, Russia
Contact:

Re: Porting GZDoom Builder to Linux

Post by polyzium »

Just tested it, seems to open maps fine, except textures are screwed in 2D mode. Also whenever I draw something and create a sector out of it, the program crashes, so it's unusable for doing map work. Plus it doesn't seem to accept mod resources (tried Quake Champions: Doom Edition v2.5), the things are shown as unknown. I think the temporary solution would be to build the OpenGL fork for Windows and run it under Wine until Linux specific stuff gets fixed.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

It is by no means meant as something ready for end users at this point. Rather, something for the others that are interested in a Linux port of GZDB can use as a base for further work.
User avatar
MartinHowe
Posts: 2022
Joined: Mon Aug 11, 2003 1:50 pm
Location: Waveney, United Kingdom
Contact:

Re: Porting GZDoom Builder to Linux

Post by MartinHowe »

I just want to say a big THANKS to you all - getting any form of DB on Linux is one of the Holy Grails of Doom :D DB and Paint.Net are the only things keeping me on Windows. Even SWP works OK in WINE.
User avatar
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

Post by axredneck »

MartinHowe wrote:... Paint.Net...
Krita? Gimp? AzPainter?
Locked

Return to “Abandoned/Dead Projects”