Porting GZDoom Builder to Linux

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
User avatar
Gustavo6046
Posts: 136
Joined: Sat May 13, 2017 3:11 pm
Location: Brazil
Contact:

Re: Porting GZDoom Builder to Linux

Post by Gustavo6046 »

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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Porting GZDoom Builder to Linux

Post by Graf Zahl »

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.
polyzium
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

Post by polyzium »

I use Pinta as a replacement for Paint.Net, GIMP is way too complicated for me
User avatar
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

Post by axredneck »

Yes, if Gimp and Krita are too complex, then Pinta, KolourPaint, MTPaint, GrafX2 etc
User avatar
MartinHowe
Posts: 2022
Joined: Mon Aug 11, 2003 1:50 pm
Location: Waveney, United Kingdom
Contact:

Re: Porting GZDoom Builder to Linux

Post by MartinHowe »

@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
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

Post by axredneck »

Pinta, KolourPaint, MTPaint, GrafX2...
... LibreSprite, Aseprite, XPaint, Gnome Drawing...
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: Porting GZDoom Builder to Linux

Post by Matt »

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.
Blue Shadow
Posts: 4949
Joined: Sun Nov 14, 2010 12:59 am

Re: Porting GZDoom Builder to Linux

Post by Blue Shadow »

Can we stay on topic, please?
Talon1024
 
 
Posts: 374
Joined: Mon Jun 27, 2016 7:26 pm
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support
Contact:

Re: Porting GZDoom Builder to Linux

Post by Talon1024 »

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.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

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.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: Porting GZDoom Builder to Linux

Post by ZZYZX »

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
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Porting GZDoom Builder to Linux

Post by Rachael »

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.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: Porting GZDoom Builder to Linux

Post by dpJudas »

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.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: Porting GZDoom Builder to Linux

Post by ZZYZX »

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.
polyzium
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

Post by polyzium »

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.
Locked

Return to “Abandoned/Dead Projects”