Porting GZDoom Builder to Linux

[ZZYZX]

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.

[TDRR]

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.

[Talon1024]

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

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

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.

[Talon1024]

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 all

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.

[Rachael]

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.

[SanyaWaffles]

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.

[dpJudas]

Where did you read that SlimDX is being discontinued?

[SanyaWaffles]

The website is down and hasn't been updated since 2012. The writing is kind of on the wall.

[dpJudas]

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]

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



The ported version can be found in the slimgl branch at my repository: https://github.com/dpjudas/GZDoom-Build ... ree/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.

[Graf Zahl]

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.

[dpJudas]

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.

[axredneck]

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.

[dpJudas]

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.

[polyzium]

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