Porting GZDoom Builder to Linux [split]

Please do not mimic the behavior of the posts shown here.

Moderator: GZDoom Developers

Porting GZDoom Builder to Linux [split]

Postby gdm413229 » Sat Jun 15, 2019 2:43 am

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.
gdm413229
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Sat Jun 15, 2019 2:46 am

Sorry to be blunt here, but please keep your advice to yourself, it's not really useful.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Wed Jun 19, 2019 12:03 pm

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
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Mon Jun 24, 2019 6:34 pm

To remove DirectX's grasp, all you have to do is get the SlimDX source code, creating a new branch and substituting EVERY 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.
gdm413229
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby Talon1024 » Mon Jun 24, 2019 8:05 pm

gdm413229 wrote: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.
gdm413229 wrote:To remove DirectX's grasp, all you have to do is get the SlimDX source code, creating a new branch and substituting EVERY 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.
gdm413229 wrote: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.
Talon1024
 
 
 
Joined: 28 Jun 2016
Github ID: Talon1024
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Tue Jun 25, 2019 4:11 am

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
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Wed Jun 26, 2019 3:30 pm

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)
gdm413229
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby wildweasel » Wed Jun 26, 2019 5:32 pm

gdm413229 wrote: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?
User avatar
wildweasel
change o' pace.
Moderator Team Lead
 
Joined: 16 Jul 2003

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Wed Jun 26, 2019 5:48 pm

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.)
gdm413229
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby wildweasel » Wed Jun 26, 2019 6:45 pm

gdm413229 wrote: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.
User avatar
wildweasel
change o' pace.
Moderator Team Lead
 
Joined: 16 Jul 2003

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Thu Jun 27, 2019 12:54 am

gdm413229 wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Thu Jun 27, 2019 4:12 am

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.
gdm413229
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby Rachael » Thu Jun 27, 2019 4:23 am

gdm413229 wrote: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?
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Thu Jun 27, 2019 5:39 am

Judging from previous posts, I'd assume the former.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Tue Jul 23, 2019 3:24 pm

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!)
gdm413229
 
Joined: 04 Oct 2011
Github ID: gdm413229
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Next

Return to Hall of Unpleasantness

Who is online

Users browsing this forum: No registered users and 1 guest