by Rachael » Mon Jul 17, 2017 5:30 am
Graf - I respect you a lot - you are a great programmer, and you are the real reason ZDoom has survived as it has to this day.
But features cannot always depend on one person's hardware. You have two developers that are already capable of running Vulkan on their systems, and if you ask nicely I'll even give you remote access to my own (I have to be away from the computer a lot the next two weeks as it is, anyway).
One of the motivations behind adding those PP shaders is because GZDoom was stagnating as it was. It's a feature we wanted - it's a feature we discussed quite a lot before adding it - and finally, we decided to put it in. As for Vulkan support - we didn't think anything was even going to happen, on that, because it was so little discussed and nothing happened on it even when it was. It would require a significant rewrite of many core parts of the renderer in order to even support it. As it was, the PP shaders feature has been out and discussed for quite a lot - you hardly, if ever, gave any feedback on it until now, when a major project starts to make use of it. And NOW it becomes an issue?
Supporting what will essentially be an additional renderer, at this point, is a pretty shaky prospect by itself. I have no doubt that if anyone can pull that off, you can - but even still, that's a LOT of different code that in the end will all be doing much the same thing: presenting some sort of 2.5D map on the screen. Counting all the code paths and compatibility, we have what is essentially 5 (maybe 6?) different renderers already. But hey, what's one more, eh?
Another thing that I think does not get a lot of consideration is besides the obvious performance advantages (which probably won't improve common major CPU chokes like 20000 2-sided linedefs in a single scene), what are the real benefits to moving to Vulkan? What does it support that OpenGL does not, and will that be critical in the future?
A lot of the "issue" here is - it takes a very long time sometimes for features to be reviewed and accepted into GZDoom, if they are at all. QZDoom is a fork that enjoys some degree of independence from that situation, that in the end we've decided we'd rather not deal with. We didn't want to force you to take our features - nor did we want to make you feel like you had to take them - if you don't want it, don't take it, simple as that. It will continue to exist in QZDoom, one way or another, though. This is NOT to say you *have* to be more active in reviewing code in GZDoom - it's only to say that it's a reason why we moved forward with it in QZDoom, so you don't have to.