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.

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

[Graf Zahl]

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!").

Don't start me. I've heard this advice, too, but the end is mostly that the initially written tests are worthless because they never cover the entire scenario. Things always turn out more complicated than expected.

For what it's worth, test driven development seems to be an inevitable consequence of using 'high-level' languages which have (d)evolved to the point where the code cannot be trusted implicitly anymore.

Tests are useful where large amounts of data need to generate a fixed and immutable output, but they are not the metric by which development should be measured.

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.

I did the same when converting the engine to floating point. The first thing I did was writing an entire support library of access functions to the common data structures, so I could then convert the fixed point code one small piece at a time - and most importantly TEST it one piece at a time. All those support functions were later removed again because their only purpose was to aid the transition.

The main reason Randi's first attempt at floatification many years earlier failed was that during the transition the engine had been in an uncompilable state for a long period of time and in the end all the small problems that accumulated presented an insurmountable obstacle.

[dpJudas]

Tests are useful where large amounts of data need to generate a fixed and immutable output, but they are not the metric by which development should be measured.

Totally agree, but good luck convincing people that already bought into the coolaid about that. My position has always been that if some part of my code keeps producing bugs, then there's something fundamental wrong with the design of that code - it isn't due to lack of testing. Only exception to that rule is exactly the situation you mention.

At my last job I encountered a codebase that passed all their tests, but its structural integrity had devolved to the state that you couldn't really make large modifications to it. My job was then to make a fundamental design change.. Thanks to those test suites the old code had managed to not collapse under its own weight, so now I was looking like the bad guy because I couldn't really add my changes to that mess. In that situation the tests only really made the situation worse as the developers maintaining it had been getting away with coding it into the ground by adjusting it until the tests passed.

The main reason Randi's first attempt at floatification many years earlier failed was that during the transition the engine had been in an uncompilable state for a long period of time and in the end all the small problems that accumulated presented an insurmountable obstacle.

This is really the best advice for Talon1024 IMHO. Make sure the code compiles and runs so that you can continuously make and test the transition.