Porting GZDoom Builder to Linux

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

[Graf Zahl]

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

I use Pinta as a replacement for Paint.Net, GIMP is way too complicated for me

[axredneck]

Yes, if Gimp and Krita are too complex, then Pinta, KolourPaint, MTPaint, GrafX2 etc

[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

[axredneck]

Pinta, KolourPaint, MTPaint, GrafX2...

... LibreSprite, Aseprite, XPaint, Gnome Drawing...

[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]

Can we stay on topic, please?

[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]

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.

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

[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]

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.

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.

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.

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.

[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]

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.