Porting GZDoom Builder to Linux

[axredneck]

Can you please provide a binary so I can test this out?

+1. At least Windows binary to try it under Wine if it doesn't compile for Linux yet.

[polyzium]

I got a friend of mine to compile dpJudas' fork for me. Both 32 and 64 bit builds ask for BuilderNative.dll that don't exist:
"Unable to load DLL 'BuilderNative.dll': Module not found. (Exception from HRESULT: 0x8007007E)"
I have no experience with .NET, so I have no idea how can I get that file.

[boris]

BuilderNative is part of the solution and thus built with the rest of the code. Maybe something went wrong when compiling?

[dpJudas]

BuilderNative is indeed part of the solution - your friend probably didn't have the C++ compiler part of Visual Studio installed.

Essentially I had a choice to make when porting to OpenGL: either use a 3rd party OpenGL C# bindings assembly, or create my own library and use P/Invoke. I opted for the second one as I think C# is a horrible language for managing limited resources and wanted to create a managed environment for its rendering where IDisposable objects are kept at an absolute minimum, or preferrably completely removed.

BuilderNative.dll/BuilderNative.so is a C++ library with C exports for P/Invoke so that it can be built safely with gcc/clang on Linux. Note that it will currently not build on Linux because the OpenGLContext.cpp and RawMouse.cpp files needs a different implementation there.

Someone needs to find out exactly what System.Windows.Forms.Control.Handle returns (some gtk object? qwidget? x11 window handle?). I have source code for initializing OpenGL on Linux, but I can't add it without knowing this piece of information.

About providing a Windows binary, I don't think it makes much sense at this point as the OpenGL port isn't 100% complete yet. No user can live with the offsetting bug it currently has in 2D mode.

[dpJudas]

Okay looking at the Mono Winforms code I can see Handle returns a X11 Window handle. So far so good, except X11 is such garbage that you cannot get the Display (connection) handle from the Window one, and the Display handle is required for OpenGL context creation. Without some way of obtaining such a Display handle a native Linux build of GZDB is going nowhere.

Edit: it doesn't look good:

Code: Select all • Expand view

Find all "class X11", Subfolders, Find Results 1, "C:\Development\mono\mcs\class\System.Windows.Forms", ""
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms\X11DesktopColors.cs(34):   internal class X11DesktopColors {
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms\X11Dnd.cs(43):   internal class X11Dnd {
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms\X11Keyboard.cs(52):   internal class X11Keyboard : IDisposable {
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms.X11Internal\X11Atoms.cs(29):   internal class X11Atoms {
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms.X11Internal\X11Display.cs(41):   internal class X11Display {
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms.X11Internal\X11Exception.cs(31):   internal class X11Exception : ApplicationException {
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms.X11Internal\X11Hwnd.cs(34):   internal class X11Hwnd : Hwnd
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms.X11Internal\X11RootHwnd.cs(30):   internal class X11RootHwnd : X11Hwnd
  C:\Development\mono\mcs\class\System.Windows.Forms\System.Windows.Forms.X11Internal\X11ThreadQueue.cs(34):   internal class X11ThreadQueue {
  Matching lines: 9    Matching files: 9    Total files searched: 2218


Game over, I guess. Unless someone can spot a public accessor to X11Display.display somewhere.

[Gustavo6046]

Isn't the X11 display handle basically that string set as an environment variable in any terminal environment within X? Like

Code: Select all • Expand view

DISPLAY=":0"

?

Plus, that's Mono's API for X11. You shouldn't blame X11 if Mono's API for it sucks.

[dpJudas]

Yes, strictly speaking it is mono’s fault, but it was also a terrible decision in xlib to require a pair of handles when one would have sufficed. In any case, I think it requires patching mono’s winforms assembly before OpenGL can be used.

[polyzium]

Isn't it possible to use a separate X11 library like X11.Net?

[dpJudas]

No, I need the Display* xlib object that mono’s winforms assembly used to create the window. Now in principle a fix in mono is very simple: create a IX11Window interface with a DisplayHandle and WindowHandle methods, then add it to the Control class. Question is if the mono project would apply it.

[Graf Zahl]

You got to ask them if they are willing to add it, but don't forget explaining the actual use case.

[dpJudas]

That's the thing - I just cba to do the red tape myself. I know developers well enough to know you have to fight for getting even the most simple things in.

[Graf Zahl]

I know. Which is why I can't be bothered to support any project that doesn't have a contribution-friendly setup, like Github's pull requests.
So many projects are still being hosted on shit servers with shit software (cough, SVN, cough...) that any hope of them getting properly maintained is futile. And external contributors have no chance in such environments.

[dpJudas]

Mono is on github, so I could probably just open a pull request. What I fear is that someone will reply "that's a bad idea because blah blah multiple backend drivers blah blah" where it basically boils down to them not wanting supporting anything except a picture perfect solution that only works for the most basic winforms projects.

[Graf Zahl]

That's why I said to lay out the use case, and allowing to create an OpenGL canvas sounds like a viable one, if they reject it anyway we can openly brand them as morons.
But if you don't even try we'll never know.

[polyzium]

Even if it is impossible to have a native Linux build, please provide us a Windows build when the OpenGL renderer is finished. The transparency bug is annoying as hell!