Porting GZDoom Builder to Linux

Any utility that assists in the creation of mods, assets, etc, go here.

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Sat Jun 15, 2019 4:59 am

dpJudas wrote: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.

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

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Sat Jun 15, 2019 6:09 am

Graf Zahl wrote: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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby ZZYZX » Sat Jun 15, 2019 8:50 am

I'd just remove dependency on DirectX and then it will be super easy to run it under WINE+Mono.
No need to remove dependencies on WinForms... that part, WINE is supporting pretty well. DirectX is the problem.

Rewriting editor in GTK means it starts looking like shit/not working at all on Windows instead.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Porting GZDoom Builder to Linux

Postby TDRR » Sat Jun 15, 2019 8:31 pm

ZZYZX wrote:I'd just remove dependency on DirectX and then it will be super easy to run it under WINE+Mono.
No need to remove dependencies on WinForms... that part, WINE is supporting pretty well. DirectX is the problem.

Rewriting editor in GTK means it starts looking like shit/not working at all on Windows instead.


Which made me think, what if after DirectX is removed, a .deb package (Along with packages for other distros obviously) with the bare minimum WINE stuff needed to run GZDB, and that WINE doesn't set up env variables so it wouldn't break anything for anyone already with WINE while still letting GZDB run easily even on computers without WINE. Also with this it would be impossible to have a WINE update break GZDB because you can basically decide if the bundled WINE is updated or left like it is for now.
User avatar
TDRR
putting jelly on this hot dog
 
Joined: 11 Mar 2018
Location: Venezuela
Operating System: Windows Vista/7 64-bit
Graphics Processor: Intel (Modern GZDoom)

Re: Porting GZDoom Builder to Linux

Postby Talon1024 » Sat Jun 15, 2019 11:38 pm

@Graf and @dpJudas
The way I look at small pieces of code is: What is the overall goal of this particular function or piece of code? And then, I try to find different ways of implementing the same functionality, like I recently did with the FileLockChecker.

I haven't finished going through the OpenGL tutorials yet.

I'm thinking it may be possible to pull away small pieces of SlimDX at first, like the timer stuff. However, when it comes to rewriting the larger and more important pieces of code (renderer), I'm thinking of writing small standalone test apps using bits and pieces of GZDB code, along with my own code and test data to ensure things work as expected.

My biggest concern about rewriting the renderer is whether or not it's multi-threaded. WINE's OpenGL-based implementation of D3D9 is quite slow, and the massive performance boost from D9VK is certainly a testament to the differences between OpenGL and D3D9.

But that's to come much later. Right now, I think I'm more concerned about putting in a cross-platform alternative to ScintillaNET for Linux. I don't want to replace ScintillaNET on Windows, because that would just unnecessarily hamper the experience for Windows users.
ZZYZX wrote:I'd just remove dependency on DirectX and then it will be super easy to run it under WINE+Mono.
No need to remove dependencies on WinForms... that part, WINE is supporting pretty well. DirectX is the problem.

Rewriting editor in GTK means it starts looking like shit/not working at all on Windows instead.

Mono is completely separate from WINE, and it can use WinForms without WINE. I'm hoping to make GZDB runnable on Mono without WINE. On the other hand, I also haven't been able to compile any Mono GTK app that uses GtkSourceView, so I may have to go with boris' suggestion of using a plain WinForms text editing component rather than Scintilla.

On a tangent, ever since upgrading to (K)ubuntu 18.04, I haven't been able to install .NET Framework 4.6.1 using winetricks (I'm using wine 4.10 from the wine-devel package).
TDRR wrote:Which made me think, what if after DirectX is removed, a .deb package (Along with packages for other distros obviously) with the bare minimum WINE stuff needed to run GZDB, and that WINE doesn't set up env variables so it wouldn't break anything for anyone already with WINE while still letting GZDB run easily even on computers without WINE. Also with this it would be impossible to have a WINE update break GZDB because you can basically decide if the bundled WINE is updated or left like it is for now.

That's pretty much what Snaps and Flatpaks are.
Last edited by Talon1024 on Sun Jun 23, 2019 1:38 am, edited 1 time in total.
Talon1024
 
 
 
Joined: 27 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 » Wed Jun 19, 2019 1: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
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Mon Jun 24, 2019 7: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
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby Talon1024 » Mon Jun 24, 2019 9: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: 27 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 5: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
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Wed Jun 26, 2019 4: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
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: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: 15 Jul 2003

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Wed Jun 26, 2019 6: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
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby wildweasel » Wed Jun 26, 2019 7: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: 15 Jul 2003

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Thu Jun 27, 2019 1: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 Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby gdm413229 » Thu Jun 27, 2019 5: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
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: No registered users and 1 guest