Page 3 of 7

Re: Porting GZDoom Builder to Linux

PostPosted: Sat Aug 17, 2019 2:53 pm
by axredneck
polyzium wrote: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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sat Aug 17, 2019 4:17 pm
by 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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sat Aug 17, 2019 5:17 pm
by boris
BuilderNative is part of the solution and thus built with the rest of the code. Maybe something went wrong when compiling?

Re: Porting GZDoom Builder to Linux

PostPosted: Sat Aug 17, 2019 6:43 pm
by 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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sat Aug 17, 2019 9:18 pm
by 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 allExpand 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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 7:48 am
by Gustavo6046
Isn't the X11 display handle basically that string set as an environment variable in any terminal environment within X? Like

Code: Select allExpand view
DISPLAY=":0"

?

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

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 8:01 am
by 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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 8:06 am
by polyzium
Isn't it possible to use a separate X11 library like X11.Net?

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 8:19 am
by 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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 8:31 am
by Graf Zahl
You got to ask them if they are willing to add it, but don't forget explaining the actual use case.

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 8:44 am
by 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. :)

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 9:17 am
by 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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 9:32 am
by 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.

Re: Porting GZDoom Builder to Linux

PostPosted: Sun Aug 18, 2019 10:39 am
by 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. :twisted:
But if you don't even try we'll never know.

Re: Porting GZDoom Builder to Linux

PostPosted: Tue Aug 27, 2019 12:29 pm
by 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!