Comments (9)
Wayland has backward compatibility with X11 - we have no reason to worry about 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 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.
from tempest.
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.
from tempest.
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.
from tempest.
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.
from tempest.
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.
from tempest.
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.
from tempest.
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.
from tempest.
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.
from tempest.
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
from tempest.
Related Issues (20)
- Push constants issue
- automatic PipelineBarriers investigation HOT 3
- Single time submit command buffers
- Add DX12 support for mingw
- DX12 test cashes on appveyor
- Uniform data/buffers HOT 1
- GPU driven rendering HOT 10
- DX12: gl_BaseInstance is always zero HOT 1
- Missing support for DDS RGB formats HOT 10
- Bindless support HOT 2
- [Linux] Unable to decode üöä HOT 3
- Mesh shader emulation over draw-indirect HOT 10
- Robust support for push_constant's and SPIRV_Cross_VertexInfo in DX12
- Add `setWindowTitle` function
- Bake default font to engine
- Porting to FreeBSD: openal-soft 1.22 does not build on FreeBSD HOT 1
- Mouse wheel on X11 is not working. HOT 2
- -dx12 seems to be broken HOT 6
- Rework(remove) Tempest::Pixmap::Format
- MSL: implement msl_options.buffer_size_buffer_index
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tempest.