Porting GZDoom Builder to Linux

[Talon1024]

Over the past week, I've been trying to learn OpenGL, and do research on porting GZDoom Builder to Mono on GNU/Linux. Obviously, there are hurdles to overcome in porting GZDB to Linux, so this is a quick overview of the issues I've found that need sorting out before GZDB can be used on Linux.

EDIT: WIP GZDoom Builder fork here.

SlimDX
The big elephant in the room. As far as I know, it's used for GZDoom Builder's 2D and 3D rendering, as well as input handling. Obviously, that's going to have to be removed and replaced with an OpenGL renderer. OpenTK looks to be just the thing to do it with. I've been studying OpenGL in hopes of writing an OpenGL renderer for GZDB.

DevIL
There are a bunch of DllImports that reference devil.dll in FileImageLoader. Thankfully, Mono has this handy DllMap feature (part of app.config) which lets you use other equivalent libraries instead of the Windows DLL file. DevIL is available for Linux, so it shouldn't be hard to use DllMaps to make Mono use libIL.so.1 instead of devil.dll. There's also this discussion about dllmaps in .NET Core.

ScintillaNET
This one is used for the SCRIPTS and DIALOGUE editor. Unfortunately, it isn't supported on Mono.

As an alternative, I thought of re-writing the GZDB source code editor using GTK to take advantage of the C# binding for GtkSourceView, but then I'm afraid the whole program would have to be rewritten as a GTK app. I also thought of opening an external text editor such as gedit or Kate, like what happens when you run 'git commit' on Linux, but I don't know if that will work well. I also found an answer on StackOverflow suggesting Mono.TextEditor, but I don't know if it's available outside of MonoDevelop. Another person got a Scintilla component running on Mono using the Eto library, but that may also require rewriting the entire GZDoom Builder UI for another library.

The Visplane Explorer Plugin
Like with DevIL, the Visplane Explorer app is available natively on GNU/Linux. The difference is that the user may have to compile the native code for the VPO plugin themselves.

[Rachael]

This is a pretty ambitious project, but I really hope you are successful. Running it in a VM is pretty icky, and Wine is reportedly not very performant here.

[leodoom85]

@Talon1024
Good luck with that project and, hope that at last....Linux users enjoy the wonders of the editor in a proper way, because there still are many of them waiting to create maps with some great potential.

[boris]

Whatever you do, try to keep everything compatible so that eventually the same codebase can be used to either compile for Windows or Linux. I don't think there's any reason why the windows version shouldn't use OpenGL, too.

SlimDX
The big elephant in the room. As far as I know, it's used for GZDoom Builder's 2D and 3D rendering, as well as input handling. Obviously, that's going to have to be removed and replaced with an OpenGL renderer. OpenTK looks to be just the thing to do it with. I've been studying OpenGL in hopes of writing an OpenGL renderer for GZDB.

At a cursory glance OpenTK looks like a solid choice. It supports the OpenGL as a control, which is pretty much necessary.

ScintillaNET
This one is used for the SCRIPTS and DIALOGUE editor. Unfortunately, it isn't supported on Mono.

As an alternative, I thought of re-writing the GZDB source code editor using GTK, but then the whole program would have to be rewritten as a GTK app. I also thought of opening an external text editor such as gedit or Kate, like what happens when you run 'git commit' on Linux, but I don't know if that will work well. I also found an answer on StackOverflow suggesting Mono.TextEditor, but I don't know if it's available outside of MonoDevelop. Another person got a Scintilla component running on Mono using the Eto library, but that may also require rewriting the entire GZDoom Builder UI for another library.

To be honest I don't think that's a critical point. If bad comes to worse having a simple text input control instead of a fancy one with syntax highlighting/completion and code folding is still better than not having GZDB-BF running on Linux at all. If there's no good cross-platform solution it might make sense to refactor the code to put the text editing stuff in it's own DLL/so, so that the Scintilla one can be used for Windows, and whatever else for Linux.

The Visplane Explorer Plugin
Like with DevIL, the Visplane Explorer app is available natively on GNU/Linux. The difference is that the user may have to compile the native code for the VPO plugin themselves.

That'd be the least of my concerns, really. The VPO plugin has the DLL embedded and copies it to a temp directory multiple times (because apparently it needs one for each thread). Not sure how/if that'll work with Linux, though. Still, I guess you could still simply distribute both 32 bit and 64 bit versions.

[Talon1024]

To be honest I don't think that's a critical point. If bad comes to worse having a simple text input control instead of a fancy one with syntax highlighting/completion and code folding is still better than not having GZDB-BF running on Linux at all. If there's no good cross-platform solution it might make sense to refactor the code to put the text editing stuff in it's own DLL/so, so that the Scintilla one can be used for Windows, and whatever else for Linux.

If this is possible, I'd be very interested in how to do that in a manner such that the same source files can be compiled for Windows, Linux, and macOS, because AFAIK C# isn't like Python where you can just import whatever you need, whenever you need it conditionally. .NET Core also lumps Linux and macOS into one blanket "Unix" platform.

On the other hand, there's another issue I forgot to bring up, and that is FileLockChecker.cs, which checks to see whether the map file is being locked by another process. There's a tool for Linux called lslocks which shows which files are currently being locked by which processes.
EDIT: After taking a closer look at lslocks, it really just opens /proc/locks and presents the info within in a more readable manner.

[boris]

There's no C-style #ifdef if that's what you mean. But there's nothing stopping you from putting all OS specific stuff in one project for each OS and only compile the appropriate one, right?

[Talon1024]

I don't know how one would specify certain projects within a solution to be only compiled if the target OS is Windows, Linux, or whatnot. However, I did at least find this, which lets you use C-style #if/#elif/#endif preprocessor directives to conditionally compile code for Windows or Linux.

[dpJudas]

SlimDX
The big elephant in the room. As far as I know, it's used for GZDoom Builder's 2D and 3D rendering, as well as input handling. Obviously, that's going to have to be removed and replaced with an OpenGL renderer. OpenTK looks to be just the thing to do it with. I've been studying OpenGL in hopes of writing an OpenGL renderer for GZDB.

I did a little research and figured out which parts of SlimDX is actually used by GZDB. The result is this SlimDX.cs file. It will allow you to remove the SlimDX reference and still get the project to compile.

GZDB seems to be quite closely bound to SlimDX. My strategy for migrating it to OpenGL would be to keep most of the interface in the Device, Mesh and Effect classes. The VertexBuffer, IndexBuffer and Surface classes should map fairly well to OpenGL buffer objects. All the initialization, mouse and COM dispose code I would ditch.

[Talon1024]

So, I did a bit of a mockup for a FileLockChecker that works on both Linux and Windows, using the preprocessor directives as per the aforementioned blog post.

I did a little research and figured out which parts of SlimDX is actually used by GZDB. The result is this SlimDX.cs file. It will allow you to remove the SlimDX reference and still get the project to compile.

GZDB seems to be quite closely bound to SlimDX. My strategy for migrating it to OpenGL would be to keep most of the interface in the Device, Mesh and Effect classes. The VertexBuffer, IndexBuffer and Surface classes should map fairly well to OpenGL buffer objects. All the initialization, mouse and COM dispose code I would ditch.

Thank you very much! I'm sure that will be very helpful as a base when it comes to porting GZDB to Linux. I've uploaded your code here, so it won't be lost.

[gdm413229]

One sure-fire method of pushing the big elephant out the room is to literally reuse code from GZDoom, especially the OpenGL backend and software renderer code. The 2D view code could be derived from GZDoom's automap code. The earliest versions of GZDB's Linux port is software renderer only, before the OpenGL backend is ready for application.

[dpJudas]

The tricky part here isn't rendering things with OpenGL, but finding a realistic strategy for changing the existing codebase to do so. Without a solution that effectively asks for a rewrite. The SlimDX.cs file I created serves the purpose of giving you a project that compiles, and with slightly more work on the file it could be made to boot the entire program too (with no rendering). To defeat an elephant this size you need to break it into smaller elephants, then defeat those one at a time.

[Graf Zahl]

To defeat an elephant this size you need to break it into smaller elephants, then defeat those one at a time.

And to make one thing clear: This is something I've seen too many programmers fail at.

I had such a thing at work over the last roughly two years. I inherited a code base for which the term "clusterfuck" would have been a compliment. It consisted of 10 major source files, each with 5000-8000 lines, no separation by logic - all huge, deeply convoluted classes that tried to do too many things and had poor interfaces to interoperate. Everything depended on anything.

The only way to sanitize this was to break out smaller pieces into separate classes and redo those, one after another. Trying to solve the whole thing in one go would simply have been impossible. In this case I even had to do some intermediate refactorings where I took out code, cleaned it up but fully knowing that I'd throw it away later because it went all the wrong way of doing stuff, but couldn't get rid of it due to all the cross dependencies.

Something similar would apply here. This code isn't a mess but needs to be made working on a completely different system So breaking out one problem section after another and trying to reimplement it without affecting the rest of the code too much is clearly the way to go.

[gdm413229]

One useful thing in a potential Linux port of GZDB is a 64-bit friendly version of Visplane Explorer (as a plugin) and the software renderers from GZDoom. (Carmack renderer in this case could be a separate preview window and SoftPoly is used for software-rendered visual mode) The 2D view could be based on a C# translation and modification of GZDoom's automap code. The original Visplane Explorer application has major issues when compiled as a 64-bit binary.

[Graf Zahl]

Sorry to be blunt here, but please keep your advice to yourself, it's not really useful.

[dpJudas]

And to make one thing clear: This is something I've seen too many programmers fail at.

Well, it is one of the hardest things to master. The basic idea behind it is of course simple enough, but there's so many things that can go wrong. Also countless books out there selling magical solutions that they claim will fix it all - i.e. test driven development ("if you write the test first then you understand the problem space completely!").

In this case I even had to do some intermediate refactorings where I took out code, cleaned it up but fully knowing that I'd throw it away later because it went all the wrong way of doing stuff, but couldn't get rid of it due to all the cross dependencies.

That's one of the tricks a lot of developers don't seem to know how to do. Building temporary support code is often all worth the time doing so, even if you throw it away in the end. When I did the JIT the first task was to figure out how to only compile a subset of the functions. The code that analyzed and decided if a function can be JIT'ed is now gone because it can compile it all, but it was critical in the early stages of that project.