+1. At least Windows binary to try it under Wine if it doesn't compile for Linux yet.polyzium wrote:Can you please provide a binary so I can test this out?
Porting GZDoom Builder to Linux
- axredneck
- Posts: 354
- Joined: Mon Dec 11, 2017 2:09 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Russia
- Contact:
Re: Porting GZDoom Builder to Linux
-
- Posts: 12
- Joined: Wed Aug 14, 2019 3:14 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Moscow, Russia
- Contact:
Re: Porting GZDoom Builder to Linux
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.
"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
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
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.
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
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:
Game over, I guess. Unless someone can spot a public accessor to X11Display.display somewhere.
Edit: it doesn't look good:
Code: Select all
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
- Gustavo6046
- Posts: 136
- Joined: Sat May 13, 2017 3:11 pm
- Location: Brazil
- Contact:
Re: Porting GZDoom Builder to Linux
Isn't the X11 display handle basically that string set as an environment variable in any terminal environment within X? Like
?
Plus, that's Mono's API for X11. You shouldn't blame X11 if Mono's API for it sucks.
Code: Select all
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
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.
-
- Posts: 12
- Joined: Wed Aug 14, 2019 3:14 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Moscow, Russia
- Contact:
Re: Porting GZDoom Builder to Linux
Isn't it possible to use a separate X11 library like X11.Net?
Re: Porting GZDoom Builder to Linux
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
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Porting GZDoom Builder to Linux
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
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
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Porting GZDoom Builder to Linux
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.
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
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
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Porting GZDoom Builder to Linux
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.
But if you don't even try we'll never know.
-
- Posts: 12
- Joined: Wed Aug 14, 2019 3:14 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Moscow, Russia
- Contact:
Re: Porting GZDoom Builder to Linux
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!