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 Gustavo6046 » Sun Sep 01, 2019 1:17 pm

A bit off-topic, but thumbs up for GIMP. Also, what is SWP?

Anyway, I can't wait to see a working version of this! C♯ is sucky for Linux development; even though Microsoft did try to bring it to our land, their past choices were already too big of a shadow cast on their products, and it was already too late.
User avatar
Gustavo6046
 
Joined: 13 May 2017
Location: In an urban area in Brazil.
Discord: Gustavo6046#9009

Re: Porting GZDoom Builder to Linux

Postby Graf Zahl » Mon Sep 02, 2019 2:55 am

axredneck wrote:
MartinHowe wrote:... Paint.Net...

Krita? Gimp? AzPainter?


That's quite like saying when someone complains about Linux not having the Notepad++ editor to use vim.
Sometimes a specific tool hits the sweet spot between usability and feature support - and if that happens most so-called alternatives will fall flat.

I'm having the same problem on macOS: All the graphics software is either garbage or costs $$$ which my employer won't pay for my infrequent needs. So it's the Windows VM and Paint.NET.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Porting GZDoom Builder to Linux

Postby polyzium » Tue Sep 03, 2019 12:14 am

I use Pinta as a replacement for Paint.Net, GIMP is way too complicated for me
polyzium
 
Joined: 14 Aug 2019
Location: Moscow, Russia
Discord: polyzium#0481
Twitch ID: polyzium
Github ID: polyzium
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby axredneck » Tue Sep 03, 2019 11:37 am

Yes, if Gimp and Krita are too complex, then Pinta, KolourPaint, MTPaint, GrafX2 etc
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby MartinHowe » Tue Sep 03, 2019 11:41 am

@Graf Zahl +1 your comments about sweet spot, I was using a VM and GZDB/Paint.NET in Linux.

@polyzium - I did too and for the same reason, but when they stopped updating it and it kept crashing I was left with no alternative but the above.

As for GIMP, it's way too complicated for simple editing; fine if you do a lot of artwork, but you can't even save a file, you have to "export" it and then when closing it says the original file isn't saved! I haven' t found a good SIMPLE image editor for Linux yet.

@axredneck - thanks, I'll check the other two out, KolourPaint, MTPaint, GrafX2 too, since you Ninja'd me with them as I was typing this :p
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: Porting GZDoom Builder to Linux

Postby axredneck » Tue Sep 03, 2019 3:30 pm

Pinta, KolourPaint, MTPaint, GrafX2...

... LibreSprite, Aseprite, XPaint, Gnome Drawing...
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby Matt » Wed Sep 11, 2019 6:27 pm

Just the other week I gave up trying to get on IRC because I was overwhelmed with the options for clients. (SnakeCharmer then recommended HexChat and that finally broke me out of it.)

Seconding Kolourpaint for anything that doesn't require layers, vectors, alpha channels or custom brushes.
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Porting GZDoom Builder to Linux

Postby Blue Shadow » Wed Sep 11, 2019 7:47 pm

Can we stay on topic, please?
User avatar
Blue Shadow
 
 
 
Joined: 14 Nov 2010
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: Porting GZDoom Builder to Linux

Postby Talon1024 » Wed Sep 11, 2019 10:42 pm

Speaking of which, I managed to fix a crash that happened when trying to add a new sector. I've tried to fix the grid being vertically inverted, but I don't know if my solution is the best one.
Talon1024
 
 
 
Joined: 27 Jun 2016
Github ID: Talon1024
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Thu Sep 12, 2019 2:51 am

About the inverted things, they are caused by Direct3D using top-down frame buffers while OpenGL uses bottom-up. I am not sure what is the best way to address it other than flipping the transforms for when it happens.

For the null pointer crash, that code is way too convoluted for me to be able to judge if your fix there is correct or not. My solution would be to rewrite that entire function as it is clearly overcomplicating things that could have been solved much nicer by adding some helper functions or a helper class.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby ZZYZX » Fri Sep 20, 2019 10:08 am

Hopefully it's ok to ask questions to dpJ here as well ;) Saw the OGL port some time ago, had few questions but was waaaaay too lazy to search for dpJ outside of Discord...

1. Why native code, not OpenTK? (why shaders embedded in C++ preprocessor or whatever, and not Resources directory like D3D shaders?)
I once had an attempt at removing SlimDX, however started differently and pretty much stalled at replacing all vector math that was randomly using either SlimDX or own code... That's why I remember OpenTK ;)
2. What about custom configs in this commit? https://github.com/Talon1024/GZDoom-Bui ... d7f7cda75b
Doesn't look too compatible... I would do Replace("\\", "/") in the import handler instead.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Porting GZDoom Builder to Linux

Postby Rachael » Fri Sep 20, 2019 10:31 am

Why the insistence on using OpenTK? Generally, less third-party libraries, the better. I thought we learned that lesson with SlimDX.

Doing a native implementation gives you greater control of the final result, and if it crashes then chances are it might be something you can actually fix without worrying about downstreaming an update that removes or conflicts with the fix. As an example: GZDoom's backend hardware code is almost entirely native, sitting directly on top of the operating system's hardware abstraction layer (except on Linux, where it depends on SDL). If it didn't do this, it would not have been possible to implement Vulkan into the engine.

Plus, there's this zombie of a thread, which serves as only the most recent of many, MANY examples of library discussion on platforms like Linux and its flaws. Generally - it's a mess that's best avoided.

I believe all this stuff is separated out into a logical file structure, anyhow - that way you only really have to worry about the higher level code anyway, and if someone needs to do something with the native code, there will be people who can still deal with that, too.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Porting GZDoom Builder to Linux

Postby dpJudas » Fri Sep 20, 2019 11:51 am

ZZYZX wrote:1. Why native code, not OpenTK?

I picked native code over OpenTK because:

1) The project already had several native dependencies, including building a full C library. Streamlining that into a single native DLL seemed reasonable (yes, it isn't streamlined right now, but that other C library could be moved into BuilderNative easily). It would also give me an easy way to reimplement anything DevIL was doing, if needed (turns out Talon1024 found a way to just link directly with DevIL on Linux though).

2) 3rd party assemblies in .net are generally unstable. Hell, even Microsoft C# stuff is a moving target. SlimDX went missing in action, what's not to say same could happen to OpenTK? I generally gravitate towards solutions that can be maintained within a project rather than have outer dependencies. In short: I trust my own abilities over 3rd party developers and only use them when there's enough extra work involved that I can't do it myself. I've been burned too many times.

3) I do not like C# very much. Especially when resources are involved that language is like stepping back to early C and C++ before RAII and shared/uniqueptr. IDisposable and finalizers are an abomination. I wanted a solution that was "idiot proof" and with a managed outer interface, so that the consumers of RenderDevice did not have to worry too much about actual GPU resources and could stay in the la la land of garbage collection.

While you could create a backend directly in C# using OpenTK it would just invite the next developer to get creative about accessing OpenGL directly. My personal opinion here is that C++ is better at handling OpenGL resources, but of course a pure C# developer would disagree with me here. It is a design choice where either way would technically work. I see the C++ version having the bonus feature that a rookie C# developer won't be able to fire off custom OpenGL.

That said, if someone wanted to rewrite it with OpenTK they can do that relatively easy - because unlike the old SlimDX version there's now a few simple basic outer interface to drawing 3D that can encapsulate several backends, if needed.

ZZYZX wrote:I once had an attempt at removing SlimDX, however started differently and pretty much stalled at replacing all vector math that was randomly using either SlimDX or own code... That's why I remember OpenTK ;)

My strategy was to first find the exact dependency to SlimDX at the class and function level. From there I evaluated each class and picked a solution. For the math classes the easiest step was to replicate them, although in the long run one would want to get rid of them completely. There's no real reason why there's several classes doing the same job. If you look at the commit log of my branch you can see it consists of many iterations where I slowly morph code closer and closer towards something better. This method is very powerful if done right and essentially allows me to refactor a large program while almost introducing no bugs.

ZZYZX wrote:Why shaders embedded in C++ preprocessor or whatever, and not Resources directory like D3D shaders?

This is one example what I do in intermediate steps when porting from one design to another. I needed some shader code fast and the easiest way was to inline it directly in the C++ code. At the time I didn't want to outright delete the original D3D resources as I still wanted them for reference. Defining the uniforms and shader source code from C# (coming from resources) would be a natural next step, but I didn't get around to code that.

ZZYZX wrote:2. What about custom configs in this commit? https://github.com/Talon1024/GZDoom-Bui ... d7f7cda75b
Doesn't look too compatible... I would do Replace("\\", "/") in the import handler instead.

You have a much better understanding of what GZDB does in general than I do. I opted for the first solution I could spot here, not even sure yet at the time if it would work or what the implications would be. I wouldn't be surprised if there are a few more of those kinds of issues lurking, including case sensitivity issues with files.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Porting GZDoom Builder to Linux

Postby ZZYZX » Fri Sep 20, 2019 1:44 pm

aha. On OpenTK — fair point, makes sense. Didn't think of it that way, as my own projects are generally short-lived.
Even though this probably won't affect my habit to use things that are already there and working (like e.g. Unity for various experiments, and either way I generally google "library to do XXX" before doing it myself) but it reminded me of some other code situation elsewhere.

Configs — it's not as much about knowledge of GZDB, more like knowledge of people who actually do write their custom configs for various reasons. Plus some people copy configs from older versions for the same various reasons...

Either way that's not really serious nitpicking about a PoC project ;) The generalized renderer rewrite seems to be very helpful there.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Porting GZDoom Builder to Linux

Postby polyzium » Sun Sep 22, 2019 3:07 pm

I personally don't really care how things are done - if it works, then so be it, if there's a faster solution then use that instead.

So far the port seems to be more or less stable, no sector creation crashes, but these issues are still present:
- 2D mode displays offsets/UVs incorrectly (I think)
- In Visual mode menu keybinds are still active when using ESDF keys to move
- No mouse in Visual mode (still)
- For some reason refuses to load PK3 mods as resources, therefore Things from mods are being displayed as Unknown (tested with QCDE)
I'm not an experienced mapper so I can't test out all of the things, but if the aforementioned gets fixed then I can use the port.
polyzium
 
Joined: 14 Aug 2019
Location: Moscow, Russia
Discord: polyzium#0481
Twitch ID: polyzium
Github ID: polyzium
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: jingolingo and 0 guests