Linux support (and SDL2)

[swick]

So linux has at least two video backends that should be supported: x11 and wayland. You generally only know at runtime which one to use which means that the Vulkan instance extensions required to the WSI can be different depending on the Window type (x11/wayland). The code has to be restructured in a way that the vulkan instance creating already has access to the window.

The other point here is that you really should use SDL2 to replace the various SystemApi implementations.

Relevant APIs: https://wiki.libsdl.org/CategoryInit https://wiki.libsdl.org/CategoryVideo https://wiki.libsdl.org/CategoryEvents https://wiki.libsdl.org/CategoryVulkan

[Try]

Wayland has backward compatibility with X11 - we have no reason to worry about it.

https://wiki.libsdl.org/CategoryVulkan

They basically have to traslient vulkan support. And no mentions of support for DrectX12, Metal. Keep in mind - engine designed to have multi-render support, so DrectX12 is coming.

The code has to be restructured in a way that the vulkan instance creating already has access to the window.

Won't do - it's a direct shoot to foot. I've made this mistake with previous version of engine: it's hurt multi-window support, unit testing(you don't want to create a window at all for tests).

Overall, I don't like the idea exchange simple 400-500 line event-loop in favor of huge thirdparty library.

[swick]

Wayland has backward compatibility with X11 - we have no reason to worry about it.

XWayland is not mandatory and has huge drawbacks even if it's there. You cannot rely on it.

They basically have to traslient vulkan support. And no mentions of support for DrectX12, Metal. Keep in mind - engine designed to have multi-render support, so DrectX12 is coming.

The Vulkan API in SDL is a convenience API. You don't have to use it, you can simply get the underlying system handle from SDL and write the swapchain stuff yourself. In the same way you can still use DX12 and Metal with it (although why the hell would you want to support Metal when it maps nicely to Vulkan with MoltenVK).

Won't do - it's a direct shoot to foot. I've made this mistake with previous version of engine: it's hurt multi-window support, unit testing(you don't want to create a window at all for tests).

This is bullshit. Your window handling already is broken on linux in a number of ways already, doesn't support fbdev, drm, android, wayland and the few proprietary systems that exist.

SDL does have a dummy backend so it integrates nicely with CI and unit testing and it does support multiple windows just fine.

Overall, I don't like the idea exchange simple 400-500 line event-loop in favor of huge thirdparty library.

It's not huge and you don't have to maintain it and most importantly: it actually works.

[Try]

You cannot rely on it.

Hard to believe, that wayland has no backward compatibility(are you 100% sure?). Anyway, wayland-support problem, not as big as SDL support problem.

Your window handling already is broken on linux in a number of ways already

What exactly is broken? fbdev, drm, android, wayland? fbdev - software buffer in SM5-tier engine? really? drm, android - non related to topic wayland - XWayland

SDL does have a dummy backend

You are not following the conversation:

• swick: The code has to be restructured in a way that the vulkan instance creating already has access to the window.
• Try: direct shoot to foot
• swick: SDL does have a dummy backend

How dummy backend can justify this API-design change?

It's not huge and you don't have to maintain it and most importantly: it actually works.

It's never 100% true, back in SDL1 days i had to rewrite huge part of code, to have android release. And then drop it, to integrate ADS-view. If you want to develop bleeding edge software, then invertible you will face tons of corner cases.

[swick]

Hard to believe, that wayland has no backward compatibility(are you 100% sure?).

You can have backwards compatibility with Xwayland but not every compositor does support it.

What exactly is broken?

Well for one it doesn't work on my machine. Have fun figuring out why.

drm, android - non related to topic

So you don't ever plan on supporting android but at the same time the reason why you don't want to usu SDL2 is because you had problems with SDL1 and Android.

Try: direct shoot to foot

And why is that? How about you start arguing with actual technical arguments and not with phrases and the assumption that you know how to support a range of platforms better than an industry standard with payed developers and backing of the biggest gaming company ever.

swick: SDL does have a dummy backend

You said that it has to support unit testing. SDL can do that just fine.

If you want to develop bleeding edge software, then invertible you will face tons of corner cases.

And there is escape hatches in SDL that allow you to do it like I already explained. Not only that, SDL is open source so if you ever actually need anything from it you can just add it and have everyone use that amazing feature that SDL is apparently missing instead of having it in this repo that nobody else is using right now.

[Try]

You can have backwards compatibility with Xwayland but not every compositor does support it.

Not a problem then. Worst case apt-get install xwayland.

Have fun figuring out why.

line 124?

So you don't ever plan on supporting android

Why you think so? In fact SM3 version of engine support android for years, and it just works. DRM has nothing to do with game engine - this is drive-level feature; Android is not related, because this is linux topic.

And why is that?

Already provide more then enough arguments. I don't know how to explain to you that ask window access form vk/dx/egl/metal/-instance creation is bad design, because it's too obvious. Since we have smalltalk about testing, here 2 cases for you:

// simple pseudo-code, can run without windows system, require only gpu
createApiInstance()
auto image=drawSuff();
validate(image);

and you proposal:

auto fakewindow = createWindow();
createApiInstance(fakewindow) // hope for the best?
auto image=drawSuff();
validate(image);

... open source so if you ever actually need anything from it you can just add it and have everyone ...

That practically mean: instead of just implementing feature, I'll have to figure out how their code works, find proper way to merge it with their features? Toon of work for nothing?

It seem you and I have a strong opinions, when it comes to SDL. OpenGothic is open source project, if you really sure, that SDL is better for games, then native api - just fork it.

[swick]

Not a problem then. Worst case apt-get install xwayland.

That's not how it works. The compositor has to implement a window manager for xwayland.

 line 124?

Don't know, don't care. I'm not going to debug X11 code ever.

So you don't ever plan on supporting android

Why you think so?

Because you said android is not on topic. There is linux devices with only DRM, only FBDEV, only surfaceflinger, only wayland, only X. And you claim linux support is "only a few hundred lines of code" yet you can't even write correct code for one of those backends.

Already provide more then enough arguments.

No you didn't. All you said is "shoot to foot". It's not an argument.

Already provide more then enough arguments. I don't know how to explain to you that ask window access form vk/dx/egl/metal/-instance creation is bad design, because it's too obvious.

It really isn't that obvious because which backend to use is not only a compile time but also a run time issue and that makes the selection of required Vulkan extensions a run time issue.

If you really are so opposed to the idea of passing a window there we actually can just create a fake window temporarily and that will work (consistently because while the extensions are a run time decision they are deterministic).

That practically mean: instead of just implementing feature, I'll have to figure out how their code works, find proper way to merge it with their features? Toon of work for nothing?

I only said it's possible but you'll never have to do it because, as I tried to explain to your before, choose not to use SDL. Escape hatches.

It seem you and I have a strong opinions, when it comes to SDL.

You have a strong and honestly retarded opinion. You're rolling your own things that don't work. The build system was crap. Your utf16 code was broken. Your X11 backend is broken.

Yet you're somehow convinced that what you're building yourself is better than the thing a group of professionals build, has years of testing and millions of users.

OpenGothic is open source project, if you really sure, that SDL is better for games, then native api - just fork it.

Not interested in working on something that doesn't get upstreamed. Honestly, I probably won't be working on anything OpenGothic if you'll stick to your position.

[Try]

Don't know, don't care. I'm not going to debug X11 code ever.

Well, if can't even describe what is not working - fine...

There is linux devices with only DRM, only FBDEV, only surfaceflinger, only wayland, only X

Really? Name at least one distro with "only surfaceflinger". Or Vulkan-capable FBDEV distro/drm.

It really ... selection of required Vulkan extensions a run time issue.

And, why you ever need a window for that? Basically, you propose to exchange a normal api design to hacks with fake windows. Are you opengl3-fan? :)

group of professionals build, has years of testing and millions of users

If there is some portable library to write window-loop, written by professionals - let me know.

The build system was crap

Yes, it was. I'm not a bs engineer, and I'm really appreciate your help with it. But it doesn't mean that I'll will blindly accept such weak proposal as hey, urgently, replace everything with SDL2! And SDL2 is not acceptable, because I care about quality of the engine.

[swick]

And SDL2 is not acceptable, because I care about quality of the engine.

That must be a joke. SDL2 is in much better shape than all of your windowing and input handling.

hey, urgently, replace everything with SDL2

Never told you to do anything and certainly didn't tell you to replace everything with SDL2.

If there is some portable library to write window-loop, written by professionals - let me know.

SDL2.

And, why you ever need a window for that? Basically, you propose to exchange a normal api design to hacks with fake windows.

Look, if you don't want to create a fake window you can even do all the extension setup and swapchain stuff yourself and only get window handles out of SDL2.

You don't even want to consider using SDL2 for some weird reason and as long as that's the case I'm done here.

[Try]

You don't even want to consider using SDL2 for some weird reason and as long as that's the case I'm done here.

OK, then we can close the ticket