dpJudas

I didn't read about how good Apex Legends works on such a monitor. I personally played it on one. Unless you can show me a screenshot of Apex Legends on a ultra widescreen where the HUD isn't placed all out to the sides I still think my argument holds for why it isn't ideal. As for software development, what I'm seeing on your screenshot is exactly what I don't like about it. Most of the monitor is going unused and its generally difficult to make much use of it. In any case, I'm happy you're enjoying your new monitor - I just wanted to add a bit of context to readers of the thread considering buy a new monitor that there are pros and cons to the form factor. :)

I think ultra widescreen monitors is one of those things that people either love or hate. Most games don't take them into account, so the HUD is spread out to the sides to such an extreme you can't really use it properly anymore. When I was playing Apex Legends on mine I would have to change the resolution of the entire monitor to get it letter boxed (16:9 in the game), otherwise I couldn't see the health of my squad members properly, which is a crucial component in decision making on what to do next in that game. On the other hand if you're more into relaxed single player gaming and graphical fidelity, then there's certainly more of an immersion effect if you use ultra widescreen. For desktop usage the story is the same. For some usages like video editing the extra space becomes very handy. For software development I find that it is very difficult to really take advantage of the form factor. For software development a 32" 16:9 retina monitor is so much nicer to use.

Ah yes the "lovely" curved monitor effect. I actually notice that even in normal applications. The good news is that at least for me I stopped noticing it after a while, but the funny thing is then I started seeing straight lines on normal monitors as curved instead (my brain had started to compensate). It is one of the reasons I sold my ultrawide monitor and don't intend on buying one again. There's no setting to compensate for this I'm afraid - the closest you can get is the Lens Distortion Effect post process filter. It bends things so maybe it will help on the effect (or make it worse?).

The vulkan swap chain is absolute horror that barely works and Nvidia's implementation is rather buggy. You can try force it to use the DXGI swap chain for GZDoom in the Nvidia control panel - maybe that will fix it.

The first two maps are DM01 and DM02 in Nash's Disdain game. I'm not sure if they are publicly available or not. If they are, there's a demo of Disdain on Steam that might have them. The screenshots bit further down the page are from various Doom maps where their mappers have experimented with how they could look like using light maps or ray traced dynamic light shadows.

And you should drop it if it doesn't support what you want to do. I think it is important to remember in this context though that supporting these things aren't free. Someone has to code and maintain that support. The funny thing about Graf is that he's always been flamed for how GZDoom plays Doom maps, but he is actually the guy that implements all this compatibility. You'd never see me do it, for example, because that's just not why I'm coding on Doom source ports.

Who are these mythical newer developers you speak of and why haven't they clicked the fork button yet? Surely if the Doom community is so upset of how GZDoom is run they'd flock to the port right away! What's stopping them?

There is no issue tracker. The crash bug in 0.9 has been fixed a long time ago. We haven't made a new public release since due to incompatibilities between the master branch and zdray, which would confuse modders checking out the lightmaps feature. It is a bit annoying but it is what it is.

The Vulkan backend in VKDoom is a newer version of the backend present in GZDoom. GZDoom will probably merge its changes back into GZDoom 5.0 when that is released. At that point which port you prefer will come down to preferences (they don't use the same defaults, i.e. the infamous filtering defaults to nearest in VKD) and what will be added to VKDoom next. There are also things in VKDoom that have been [No]'ed for GZDoom. And there will probably be things in GZDoom at some point that won't be added in VKDoom. Like with many open source things, cross merging is a possibility and which you want to use can often come down to... wait for it... your personal deal breakers. :P

I've generally always made sure my changes (both in GZDoom and VKDoom) works with fallback paths and so on. This even includes ZDRay that can ray trace without RT cores. I've generally supported any version of Windows that is still officially supported by Microsoft as well. There are no prior examples of me releasing anything only working on the latest most expensive rigs. What is important to understand here though is that a lot of users show up with a machine that doesn't even come with a real GPU (i.e. Intel UHD), have 4 GB of memory and maybe even runs Windows 7. Then they get really vocal about why we won't go the extra mile for supporting such a setup. When I added multithreaded rendering to the software renderer they were unhappy a Pentium 4 now ran slower, even though it made it run 4 times faster on a more current CPU. The message with VKDoom is basically that if you don't have gaming gear that works for typical games on Steam then your computer isn't the target audience for the port.

Oh absolutely! If I acquire a 5090 and it has something I find very fun to code in, then I will do so. Because that's fun and that's my hobby! Current hardware requirements for VKDoom are far more modest though. It will run on any Vulkan 1.0 that supports bindless textures (almost all VK 1.0 cards do). Such a card just won't be able to realtime update light maps or do ray traced dynamic lights. I find the hardware requirements for VKDoom to be quite reasonable. All we ask is that you have a card that is also usable for play modern games. It isn't the port for those that have a 10 year old computer or find it fun to run Doom on a Raspberry Pi.

The vulkan backend doesn't really have anything that prevents 32-bit (unlike JIT, which requires supporting an insane amount of legacy 32-bit calling conventions). The VulkanDrv project for UT99 also uses ZVulkan and works perfectly fine as a 32-bit DLL for UT. That said, I'm not personally going to verify or even fix any 32-bit issues with the Vulkan backend because I simply don't care. It isn't my hobby or job to provide support for anything unless I choose to, and I don't want to deal with old hardware and OSes and that is why you never seen any 32 bit executable or anything of that sort from me. If someone provided a PR on the other hand I'm not against merging it, assuming it was done properly. Even then, I'd not begin testing 32-bit and if it breaks again then it breaks.

The BUILD code in GZDoom is licensed as GPL nowadays. Rachael contacted Ken Silverman and persuaded him into licensing the parts in GZDoom as GPL (note: this still doesn't mean his other public voxel code - just what is in GZDoom). In any case, this implementation seem a lot better than the build version. Very nice work! Would be nice to get in GZD's software renderer as well.

As someone certainly guilty of calling the community slurs when I rage, I think it is only fair that if they can slur at me that I can then also slur back. :) I think a lot of the things listed (except the deliberate sabotage of 32-bit builds) are really just about source ports not meant for your type of hardware. Every source port author is ultimately only doing this as a hobby and therefore it should be fun for them to do. For me, targeting the raspberry pi is the opposite of fun. I know this thread is personal deal breakers, but your way of wording it makes it sound like you think its the source ports authors fault/responsibility to support your use case. It really isn't. Back on topic: My personal deal breaker for a source port is when it expects me to edit config files in order to set it up. This is in particular important when it comes to making it work on my monitors. Ultra widescreen, 4K or even 8K - all that kind of stuff. This doesn't mean a source port must support a higher resolution, but if I can't get it properly letterboxed and upscaled to my monitor without stretching then I can't really use it.

That sure is weird. Here's a couple of things you can try: 1) If you have a different monitor, try plug it in and see if it makes any difference. It could be a hardware compatibility problem. 2) Force gsync/freesync on or gsync/freesync off. Shouldn't matter but if it is a hardware compatibility problem between the graphics card and the monitor then it could make all the difference. 3) In task manager, try sort the processes by CPU time (you have to first make the column visible) and see if something is consistently burning CPU time. 4) Some software adds hooks into graphics APIs like OpenGL and Vulkan so they can put their own overlays and other stuff on top. If one of those plugins are misbehaving they could cause such stutters. So if you have any recording software or other stuff you suspect could be doing such a thing, try uninstall them and see if it changes anything.

Try go to "Settings -> System -> Power & battery" in Windows and change the power mode from Balanced to Best Performance. In some situations you can experience stutter from games if the load is not high enough for the CPU in the Balanced mode. Doom only ticks 35 times per second, so if the tick itself is heavy, but the rendering is not, then it can end up in a nasty cycle where it keeps changing the CPU clock speed up and down between frames where the playsim ticks and those where it does not.

But it didn't do exactly what they needed. Even in the 1990's a user that recorded demos with Doom 2 1.666 lost all his demos when he upgraded to 1.9. The "solution" back then was to make a second folder with the old version of the game and load that up if you wanted to see the demo. Even with modern source ports he still can't view those demos outside dosbox as far as I know. The only saving grace of the 90's was the fact that getting a new patch required so much of an effort that most of us didn't even bother. Hacks always break in the edge cases, or when code gets refactored, which this is just another example of. By your definition if the customer doesn't complain and you complete the task quickly, then something isn't a hack. That doesn't seem like a very good definition of the term either.

I agree with you on that, but to me that's also the nature of hacks: they get you the feature fast (demo playback), but is built on assumptions that aren't universally true. In any case, my first post was to illustrate it isn't as black and white. There are some serious cons to the input recording strategy, whether we call it a hack or not.

The hack is the assumption that playsim code never change behavior and even if it does you'll be able to easily tell that you broke it. For multiplayer that's (usually) not a problem since you can just require all players use the same patch version. You can't do that for demos as they are persisted on disk. If you don't find that to be a hack I guess we'll just have to disagree on that as you say.

A million flies can't be wrong. Saying a lot of people is doing something isn't really a strong argument for quality/correctness. But I'll humor you: GZDoom doesn't actually do anything wrong. Its demo compatibility is exactly the same as Carmack and Romero provided: this patch only. What you're seeing in this thread are the users being unhappy that such a design fucks their demos over. None of the games of the 1990's that I know of that did demos this way maintained perpetual backwards compatibility in the manner that modern Doom source ports do. I think this fits the definition of hack perfectly fine. A shortcut that is a pain to maintain in the long run that didn't really address the problem in a solid manner.

Of course it is a hack. It forced the original Id Software developers to lose their intro sequence for the game every time they released a patch for the game. The players also lost all their recorded demos when they did that. That's not good software design, even if a lot of games did it at the time. Multiplayer is a completely different deal, since here you can require all clients to be on the same version. Incidentally, that's also why GZDoom still supports it.

I don't think you can describe these modes in a way that makes the uninitiated player understand what the difference is without a huge paragraph in the options menu. That's not the goal either though. This is about making new players see a default that more closely matches the original looks of Doom rather than old poorer approximations.

Thanks to _mental_, the Vulkan backend actually does support Metal via a thin translation layer known as MoltenVK. This is all built-in, so the user doesn't really have to do anything. Why it crashes on his M1 Mac I have no idea though.

The first issue here can essentially be drilled down to the classic "I don't want the features I don't need" bloat complaint that any larger product receives. I have added features to GZDoom that I wish I could remove again, but every time I have mentioned maybe we should do that, there's practically always someone that really likes the feature. That's why the bloat doesn't get removed - each feature is liked by someone. Your list of bloat features is different from the next guy's list. The second issue is simply not what ZDoom and its family of source ports ever tried to do. Boom sort of emerged as a standard in Doom modding only really because half the ports following this standard emerged from Boom itself. Restricting yourself to that standard has its pros and cons, as most modders will probably agree. There's plenty of excellent boom compatible source ports out there, so the solution here is pretty simple: switch to a source port that fits your needs, if these are indeed your primary needs. It isn't really GZDoom's fault if some mods chose differently and actually wanted GZDoom's features. Then there's the optimization issue. This is a matter of perspective. Modders generally like their mods to look the way they did when they created it, so any optimization for GZDoom comes with the huge caveat that it shouldn't break existing mods. I could design a "BSP-less" version of GZDoom in like 10 minutes, but it would also render half the GZDoom mods wrongly. Most GZDoom users would rather have lower performance with backwards compatibility, than speed. That is why GZDoom doesn't just fix its speed. It is actually quite fast for something that uses the rendering strategy that it has. Any further improvement requires a ton of work that so far has been too much for it to happen. Don't take our word for it though - it is an open source project that welcomes pull requests improving the performance, if it is such a simple thing to do.

You can improve the performance of a pk3 by extracting it and zipping it again. Except this time you tell the zip tool to store all entries as uncompressed. That way the .pk3 becomes a simple container for the files and you no longer pay for the deflate of the data when it load things. You will get a much larger pk3 this way of course, so it is a trade off between file size and performance.