Porting GZDoom Builder to Linux

Any utility that assists in the creation of mods, assets, etc, go here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

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
iDeas from the deep (pit of hacks)
 
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 Talon1024 » Fri Jun 28, 2019 11:17 pm

Don't worry, I'm not planning on using display lists. Vertex buffer objects, vertex array objects, and element buffer objects are the way to go for modern OpenGL rendering.

What I plan to do first is to remove or replace the various Windows API calls that are called via DllImports.

I recently tried to replace General.LockWindowUpdate with something like this:
Code: Select allExpand view
public override void Refresh()
{
  if(lockupdatecount == 0)
  {
    base.Refresh();
  }
}

// This locks the window for updating
internal void LockUpdate()
{
lockupdatecount++;
// if(lockupdatecount == 1) General.LockWindowUpdate(this.Handle);
}

// This unlocks for updating
internal void UnlockUpdate()
{
lockupdatecount--;
if(lockupdatecount == 0) Refresh(); //General.LockWindowUpdate(IntPtr.Zero);
if(lockupdatecount < 0) lockupdatecount = 0;
}


I don't know if this will work properly or not, and I don't know why the call to LockWindowUpdate was added in the first place.
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 Rachael » Tue Aug 06, 2019 1:29 pm

I've split off a lot of the fuckery. Since the guy is now banned, and will be on probation when he comes back, I think it's safe to unlock this topic.

I really don't want to see this project die because of his over-enthusiasm and desire to take charge, where he has absolutely no experience and absolutely no idea how to attract competent developers to help him.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby SanyaWaffles » Tue Aug 06, 2019 9:46 pm

I'm glad that this was done rather than let the project thread rot to nastiness. I do wanna see this done. The only thing keeping me from switching to Linux is GZDB-BF isn't Linux compatible just yet, and my art program of choice isn't Linux compatible at all.

That said I'd like to test this when the time comes. I'm glad a serious effort is being made to port one of the cornerstones of editing to Linux... and I hope those changes can be ported back to Windows. SlimDX being discontinued does not bode well for GZDB-BF

I wish you luck Talon.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Tue Aug 06, 2019 10:09 pm

Where did you read that SlimDX is being discontinued?
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby SanyaWaffles » Wed Aug 07, 2019 12:06 am

The website is down and hasn't been updated since 2012. The writing is kind of on the wall.
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Wed Aug 07, 2019 12:46 am

Hmm yes that's a problem. Although WinForms also hasn't been updated since 2002 or thereabout, so that just puts it in the same state as the rest of the foundation. ;)
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Fri Aug 16, 2019 12:54 am

I ported GZDB over to OpenGL. It still has some issues here and there, but its pretty far along now. :D



The ported version can be found in the slimgl branch at my repository: https://github.com/dpjudas/GZDoom-Builder-Bugfix/tree/slimgl

Note that this branch still requires Windows, but that's mostly because the OpenGLContext.cpp and RawMouse.cpp files needs to ported over. And then there's the DevIL and scintilla dependencies. Those could probably be disabled to get a Linux build going. It only uses DevIL to load some obscure silly image formats like PCX and DDS.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Fri Aug 16, 2019 1:11 am

Nobody uses PCX and DDS. PCX support was only added for old model packs and DDS was one of those things that looked good on paper but provided no advantage whatsoever. I do not know of one single project that uses these image formats for textures and I consider supporting them in an editor more or less unnecessary.

But good to see a version of this editor that got rid of the SlimDX dependency. For some reason I always had problems with GZDB, and my suspicion is that this library was at fault. I'll check this out when I'm back home.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Fri Aug 16, 2019 1:42 am

Completely agree on the formats. If someone does truly want them supported again then they could submit a proper C# format loader instead of pulling in a 3rd party dependency like DevIL just for that. I understand supporting those formats in a historical context, but none of them offer anything today that standardized formats like PNG doesn't do better.

Note that if you give this branch a spin, the performance is intentionally poor compared to the SlimDX version. It applies every OpenGL state prior to draw calls, but I don't want to optimize this until it is able to render everything correctly. Due to the coding style in GZDB the easiest way for me was to essentially emulate Direct3D 9 and then slowly from there I've been figuring out exactly which subset was used and adjust it into something less over complicated.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby axredneck » Fri Aug 16, 2019 7:07 am

Isn't DDS good for HD textures? It allows to leave them compressed in video memory.
Meanwhile there is KTX in the wild to replace DDS.
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Fri Aug 16, 2019 7:36 am

Strictly speaking, yes, DDS can store all the texture mipmap levels and in the compressed texture formats. However, it comes at a price that the file is very poorly compressed and very tricky to edit.

It is a reasonable output format for baking tools, which is why Microsoft used it in the first place. But once you have a texture baking tool, why output to a restricted format when you could make your own? Microsoft designed this format for assets for their Direct3D examples and IMO it works poorly outside that.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby polyzium » Sat Aug 17, 2019 10:44 am

I'm very interested in a cross-platform GZDB port like this. I'm on Linux and I don't think I can build from source.
Can you please provide a binary so I can test this out? I'm very tired of this very disorienting lack of transparency when running GZDB via WineD3D/D9VK (yes, I tested it with D9VK with the Vulkan child window patch applied, it still lacks transparency).
polyzium
 
Joined: 14 Aug 2019
Location: Moscow, Russia
Discord: polyzium#0481
Twitch ID: polyzium
Github ID: polyzium
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