By this logic, why go to Vulkan then?
At this point, Vulkan support is nothing more than a vague possibility after SDL2 support will land in. There are important reasons to support it though: macOS is dropping OpenGL, so with Vulkan in place it would be possible to have one API covering all OSes (with macOS going via MoltenVK - again, just a possibility, because having macOS-only Metal backend would be quite a problem to implement).
Are you yourself going to write the new Vulkan code for this? Or just proposing?
I hope to, but if anyone else would like to do it faster, then I'll be happy to help. SDL2 support is a prerequisite for that, though. And krcroft's replacement for SDL_sound is a prerequisite for SDL2.
(1) You can do a static (compile time) assert without using the C++11 static assert.
Really? How? Anyway, C++11 includes some STL constructs, that make it easier to use static asserts: type_traits
(2) is_std_layout is only required if the object you are checking violates StandardLayoutType. Is there any risk that object you are checking will violate this?
Yes, of course. Right now, that piece of code depends on structure offsets being 0 for specific fields. As soon as standard layout rule will be broken (and it might be broken by mistake, e.g. by someone adding a private field to the end of that structure), that assumption is broken. Without static assert, a programmer can make a mistake and it would easily pass any review, because that interaction is really, really not obvious. With static assert, a programming mistake will result in a failed compilation, so programmers time won't be wasted, reviewer time won't be wasted, user time won't be wasted.
Was it a bug? Are there re-creatable steps to manifest this behaviour at runtime? ...or is it that a static analyser picked it up?
I can go into details, but it would take some time - short version: after a change (moving fields around), that was supposed to keep runtime behaviour exactly the same while preventing triggering C++ Undefined Behaviour, runtime behaviour of code *changed*. I was writing static asserts to verify if the code is ok (it's easier to write a static assert than read the code, keep C++ standard open on the second monitor and verify several pages of specification manually). By writing those asserts and trying to understand what the code actually does (as opposed to just avoiding a warning), I discovered that runtime asserts would need to be written as well - I added those, and they blew the moment I started DOSBox. This way a bug was *prevented* before it even reached any user. No time was wasted on posting threads or investigations or reverting patches, etc.
I've had to clean up the mess too many times because of indiscriminate hipster use of XXX lib just because YYY uses it (…)
I understand… But at this point in time, C++11 replaced older standards, most C++ programmers embraced it (and for good reasons - it is a SERIOUS improvement to the language). It's not new, it is ~9 years old at this point. New MSVC does not even support limiting your project to using pre-C++11 code any more! Using the old standard is a hipster move.
(I myself found out about dosbox as I had an SGI 320 and Win2K and that hardware wouldn't even run DOS).
And me, and users of my projects can't use upstream DOSBox RIGHT NOW on Linux, because of pervasive input issues. It's not a theoretical problem affecting the old system only.
On an open source project it means divergence! and that is exactly what I thought dosbox-staging wasn't?
I really, really try to keep divergence as low as possible - that's why I keep sending patches upstream… But there are no contributing rules for DOSBox, everything happens at maintainers discretion, and… out of ~60 patches or so, only ~4 were acknowledged and merged in (or re-implemented). DOSBox SVN is so far behind, that it's starting to be harder for me to keep verifying and sending patches.
| ← Ceci n'est pas une pipe