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 SanyaWaffles » Sun Sep 22, 2019 11:47 pm

If this takes off, and I can get some form of my art program to run in Wine, I can actually consider Linux a viable option after all these years!

I understand dpjudas' concerns over using third party libraries. It seems some of GZDB's problems are rooted in unstable third party dependencies. As far as I can tell, some functions not being thread safe has rendered GZDB a tad unstable. I still can't run GZDB using directories with my current project, and I can't seem to pinpoint what triggers it even with a debug build. but others have had similar issues.

I know this is specifically about Linux, but I'm hoping for the good of the community in general these fixes are integrated back into Windows somehow. I have a feeling it might make the program even more stable there. Right now it's hit or miss.
User avatar
SanyaWaffles
Wouldn't be an epic gamer if I didn't commit a few war crimes.
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Mon Sep 23, 2019 12:24 am

I'm not sure that the stability issues are caused by 3rd party. I think it is more likely that it could be a side effect of questionable usage of worker threads without proper synchronization primitives guarding shared data.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby SanyaWaffles » Mon Sep 23, 2019 1:15 am

Even if that may be, I hope those issues can still be worked out.
User avatar
SanyaWaffles
Wouldn't be an epic gamer if I didn't commit a few war crimes.
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Tue Sep 24, 2019 1:56 pm

I personally find this paranoia about third party code a bit annoying. I can understand why someone wants to avoid black box code that can become a critical liability later (for me wxWidgets is such a library) but in most cases it should be easy to find out whether something is made by reliable developers or not.

I'm far more suspicious of all those high level languages that cannot be compiled to native code. They, too, can become a liability if the runtime runs into development problems. That's why I stay with natively compiled languages whenever possible.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Tue Sep 24, 2019 4:28 pm

I don't know if you can call it paranoia when OpenTK indeed did violate sound library principles by using reflection, to circumvent that classes and functions in mono are marked as internal. When that shit hits the fan the 3rd party developer will most likely shrug, mono will shrug and then YOU are one having a wonderful day explaining your customers that the product you sold can no longer work. That's the kind of liability you get from using other people's code without knowing how they actually do what they do.

OpenTK also seemed to use AGL and Carbon (for Mac) - those frameworks that Apple deprecated over a decade ago and completely dropped for 64 bit. So yeah, I feel I have a pretty good reason to distrust stuff found on the net until it has proven to me that it indeed is an exception where its worth linking to.

At work I'm using docker for some cloud azure management. Whenever I google the documentation I get a link to github, which uses a evolved/different API than what I got when I nuget installed it less than a month ago. Par for the course of what other developers produce.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Tue Sep 24, 2019 5:31 pm

dpJudas wrote:I don't know if you can call it paranoia when OpenTK indeed did violate sound library principles by using reflection, to circumvent that classes and functions in mono are marked as internal. When that shit hits the fan the 3rd party developer will most likely shrug, mono will shrug and then YOU are one having a wonderful day explaining your customers that the product you sold can no longer work. That's the kind of liability you get from using other people's code without knowing how they actually do what they do.

OpenTK also seemed to use AGL and Carbon (for Mac) - those frameworks that Apple deprecated over a decade ago and completely dropped for 64 bit. So yeah, I feel I have a pretty good reason to distrust stuff found on the net until it has proven to me that it indeed is an exception where its worth linking to.


Well, that sounds perfectly like code to stay away from. But I still wouldn't generalize from such things. Using deprecated APIs or hacks is always a bad sign.

Also:

without knowing how they actually do what they do.


That's what I called "black box code".

I think we have the same opinion here about these things - but I still wouldn't take this as justification to stay away from third party code in general.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Tue Sep 24, 2019 5:56 pm

What annoys me is that I always have to defend my decision not to use some 3rd party library, usually multiple times (like in this thread). Every single time it boils down to other people always assume code they didn't write themselves was made by gods until I prove otherwise. And every time I do so, people say this library is the exception. Funny how I keep stumbling into those exceptions.

I'm all for using libraries when they provide significant savings in productivity. I never said all third party code is bad, but I do insist a large portion is to the degree that you are taking a risk every time you rely on one. Most people complaining about my choices never went further in evaluation than the marketing page of whatever library they found. Of course if you did your homework and looked at both the API and implementation before adding it, then I have no complaints.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby Rachael » Tue Sep 24, 2019 8:31 pm

I really don't have a "paranoia" about third-party libraries entirely - just ones that I haven't heard about.

The bigger and more popular ones usually have bigger teams of coders on them, and more people willing to fix issues - they become more flexible and in the long run the code becomes stronger and more stable as a result. If we cut out third-party libraries completely, we'd probably have to shitcan things like OpenGL, which itself is a library unto itself, despite how deep it has to go into the OS to do its job.

When a library has proven itself to be well and good, then I have no issue with it. After all, I know GZDoom would not be where it is today, were it not for OpenAL, FluidSynth, Timidity, ZLib, DUMB, AsmJit, GME, libADL and libOPN, just to name a few - that's not even counting the biggest ones, Vulkan and OpenGL themselves. But there's a caveat to it: Some of these libraries have proven to have issues of their own, and sometimes have even had to have direct updates from their respective developers themselves. Now - let me say with no uncertainty that I am quite grateful that the developers have done that, and everyone is better for it since they did - but just imagine if they weren't there, or if they completely ignored us - and how we would get plagued with issues later on.

As dpJudas said - adopting a third-party dependency is always a risk. It might save you time - or it might cause you far more frustration and grief in the long run than if you had just done it yourself, which is especially true for smaller tasks.

And I can tell you even from just scripting things, that in general, I prefer to write my own code, than depend on someone else's, and get intertwined by whatever licensing scheme they come up with.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby SanyaWaffles » Wed Sep 25, 2019 3:24 pm

You also run the risk of suddenly the third party development libraries ceasing development, like SlimDX did with GZDB. I dunno where the code is even hosted. If it was on Google Code it might as well be as good as lost.

It's not that I'm against the idea of third party libraries, given they are well maintained. It's when something suddenly stop being developed and no forks exist that a problem occurs.

Then again that's always a risk with anything.
User avatar
SanyaWaffles
Wouldn't be an epic gamer if I didn't commit a few war crimes.
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Sun Sep 29, 2019 7:29 am

Just wanted to mention that I renamed my repository. It is now called GZDoomBuilderGL. Aside from that there's no real differences, except I merged the upstream changes, Talon1024's work and updated the readme file to make it more clear how it differs from upstream.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby Gustavo6046 » Fri Oct 18, 2019 5:38 pm

Is there a reason there is no Issues tab in that repository? I hate reporting bugs on forums. Not implying I found any.
User avatar
Gustavo6046
 
Joined: 13 May 2017
Location: In an urban area in Brazil.
Discord: Gustavo6046#9009

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Fri Oct 18, 2019 11:28 pm

There is no issues tab as I wouldn't be using it anyway. The thing about bug trackers is that they make it feel like work. Unpaid work, that is.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby Gustavo6046 » Sat Oct 19, 2019 7:44 pm

In a way it is work, but it's a tribute. It's a hobby.

Bug trackers are very handful and tracking them via forums is a very difficult task, unless you make a subforum and make each report its own thread. Fuck bug reporting megathreads.
User avatar
Gustavo6046
 
Joined: 13 May 2017
Location: In an urban area in Brazil.
Discord: Gustavo6046#9009

Re: Porting GZDoom Builder to Linux

Postby Rachael » Sat Oct 19, 2019 7:55 pm

Gustavo6046 wrote:In a way it is work, but it's a tribute. It's a hobby.

Bug trackers are very handful and tracking them via forums is a very difficult task, unless you make a subforum and make each report its own thread. Fuck bug reporting megathreads.

You can't force someone to like a tracker, especially when he sees what he hates in one, and all you're doing is making it worse by trying to push it on him.

That being said, Github supports pull requests. If you don't like forum threads, that's the best alternative.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Sat Oct 19, 2019 8:49 pm

The issue here isn't whether an issue tracker is useful or not. It is that I am not willing to fix reported bugs - if I enabled the issue tracker it would just fool people into thinking it was worth their time posting to it rather than sending it to /dev/null.

My hobby is to code various random things. I put them on github in hope it is of interest to someone else and to share it with other developers. There is no warranty on anything I put up there. If it doesn't work, send me a pull request with the fix.
dpJudas
 
 
 
Joined: 28 May 2016

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: No registered users and 1 guest