Porting GZDoom Builder to Linux [split]

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

[gdm413229]

If a native Linux port of GZDB is in the works, you should pack data that's normally packed into the Windows executable (except the icon) into a .wad file, which is beneficial to achieving platform independence. Not sure how nice Vulkan plays with Mono. A Vulkan renderer could be a nice thing to have for a Linux fork of GZDB alongside the OpenGL 1/2/3 backends.

[gdm413229]

To remove DirectX's grasp, all you have to do is get the SlimDX source code, creating a new branch and substituting ＥＶＥＲＹ Direct3D 9 draw call for OpenGL 3.x/Vulkan equivalent calls. (e.g. OMSetBlendState gets morphed into glBlendFunc and SlimDX is open source)

ScintillaNET could be replaced with code that launches an external editor e.g. Vim or GNU nano, and will inject the script into the map to be saved once the external editor process disappears from the process table.

[Talon1024]

If a native Linux port of GZDB is in the works, you should pack data that's normally packed into the Windows executable (except the icon) into a .wad file, which is beneficial to achieving platform independence. Not sure how nice Vulkan plays with Mono. A Vulkan renderer could be a nice thing to have for a Linux fork of GZDB alongside the OpenGL 1/2/3 backends.

• I don't know if putting the resources into a separate WAD or PK3 will be necessary.
• C# doesn't get compiled to native code, but rather the Common Intermediate Language, just like how Java code is compiled to Java bytecode.
• As for Vulkan, there's this, but I'm not studying Vulkan right now.
• The next version of .NET will be fully cross-platform.

To remove DirectX's grasp, all you have to do is get the SlimDX source code, creating a new branch and substituting ＥＶＥＲＹ Direct3D 9 draw call for OpenGL 3.x/Vulkan equivalent calls. (e.g. OMSetBlendState gets morphed into glBlendFunc and SlimDX is open source)

It isn't that easy. If it were, I think WINE's OpenGL-based implementation of Direct3D9 would perform much better.

ScintillaNET could be replaced with code that launches an external editor e.g. Vim or GNU nano, and will inject the script into the map to be saved once the external editor process disappears from the process table.

I thought about this myself, since "git commit" does the exact same thing, but I don't know if that's necessary a good solution. What if the user quits GZDB before quitting the external editor? Or the other way around? And if you want to use a GUI editor like Kate as your editor for git, then you have to make it wait using the "-b" flag with Kate. So I'm really torn on this issue.

Another thing I thought of was to build a very simple web server into GZDB that listens on localhost:3000 or something, serve a web page with CodeMirror on it, and have the user edit that. But that sounds like a ridiculous amount of work.

[gdm413229]

Not sure if static models could be done using display lists. One of the big downsides to display lists is you can't change the geometry without regenerating the entire display list. (for static models, use display lists and for animated models, use vertex arrays or VBOs.)

[gdm413229]

When running GZDB's first .NET 5.x version, the font that's otherwise selected as MS Sans Serif will be chosen as "fixed" in Linux, just so GZDB's future Linux installation process acts more conservatively on the bandwidth usage. Don't forget to give the Linux users their own set of icons, preferably based on KDE's Breeze or GNOME's Adwaita icon sets. (to minimize icon-set clash with other Linux GUI applications)

[wildweasel]

When running GZDB's first .NET 5.x version, the font that's otherwise selected as MS Sans Serif will be chosen as "fixed" in Linux, just so GZDB's future Linux installation process acts more conservatively on the bandwidth usage. Don't forget to give the Linux users their own set of icons, preferably based on KDE's Breeze or GNOME's Adwaita icon sets. (to minimize icon-set clash with other Linux GUI applications)

Don't you think it should be functional first before we start worrying about whether it looks good?

[gdm413229]

The font differences are to ensure that the application doesn't crash with a "font not found" error when picking a font for the editor's 2D view. (that font is used to show additional sector properties, linedef lengths among other things.)

[wildweasel]

The font differences are to ensure that the application doesn't crash with a "font not found" error when picking a font for the editor's 2D view. (that font is used to show additional sector properties, linedef lengths among other things.)

This is what I mean by functional. Do you really think the dev is going to somehow skip over making something like that work? I frankly see a lot of suggesting, and not a lot of substance that'd really, truly help the project.

[Graf Zahl]

Not sure if static models could be done using display lists. One of the big downsides to display lists is you can't change the geometry without regenerating the entire display list. (for static models, use display lists and for animated models, use vertex arrays or VBOs.)

Don't!
Use!
Displaylists!!!

They are a totally useless feature that once promised to deliver magic speed-up but never worked right - and do not even exist in real 3D APIs.

[gdm413229]

The entire map's 2D and 3D representations could be in the form of VBOs and/or vertex arrays, not display lists. Regenerating display lists are laborious (and they are a performance sink!) when you have a big and/or detailed map on the architect's table.

[Rachael]

The entire map's 2D and 3D representations could be in the form of VBOs and/or vertex arrays, not display lists. Regenerating display lists are laborious (and they are a performance sink!) when you have a big and/or detailed map on the architect's table.

Are you going to just sit here like 200,000 other idiot armchair devs we've seen, and pretend to know what you're talking about, or are you going to actually help out and code some of this?

[Graf Zahl]

Judging from previous posts, I'd assume the former.

[gdm413229]

A quick note about those little texture/flat/sprite previews is they might be software rendered if rewritten for Linux and OpenGL, just like Eureka's texture/flat/sprite previews.

We've got the cross-platform branch to create. You can use DXVK with GZDB-BF for the meantime ... until the cross-platform branch becomes the new master branch. You can do the Windows-independent edition in a separate branch to ensure the master branch's usability and don't forget the vital pull request once the special branch is ready for application. One of my strongest pet peeves (even stronger than the total monster count of nuts3.wad at nightmare difficulty!) is not being able to run GZDB natively in Linux. I am currently laying down the foundations to the new branch, complete with an empty Makefile and a README containing the mission's objectives for the new branch.

If the GZDB UI has to be rewritten, I advise you to use Qt5 as it allows you to integrate the editor with KDE. A variant of Featherpad would be a decent substitution for ScintillaNET.

One of the goals of the new branch is to make an edition of GZDB for architectures not supported by Windows, including the ppc64le architecture. (you can't get Windows 10 for POWER9!)