Porting GZDoom Builder to Linux

[axredneck]

Joshua Ashton says that alpha channel works in GZDB with D9VK
https://github.com/Joshua-Ashton/d9vk/issues/307#issuecomment-524986278

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

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.

[phantombeta]

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]

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]

I believe this is what phantombeta is talking about.

[dpJudas]

Thanks. As predicted, a nasty hack: https://github.com/opentk/opentk/blob/0a5c346c525831f095e92f547ba76d678cc08ddf/src/OpenTK.GLControl/X11GLControl.cs#L57

It will do the trick though. I'll update my fork to do the same.

[boris]

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.

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]

I got my branch to build with mono:





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!

[Marisa Kirisame]

Nice. So how would one go about building this?

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

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]

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.

[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 DB and Paint.Net are the only things keeping me on Windows. Even SWP works OK in WINE.

[axredneck]

... Paint.Net...

Krita? Gimp? AzPainter?