Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited

Everything posted by dpJudas

  1. dpJudas

    Source Ports personal deal breakers

    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.
  2. dpJudas

    Source Ports personal deal breakers

    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.
  3. dpJudas

    Source Ports personal deal breakers

    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?
  4. dpJudas

    Source Ports personal deal breakers

    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.
  5. dpJudas

    Source Ports personal deal breakers

    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
  6. dpJudas

    Source Ports personal deal breakers

    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.
  7. dpJudas

    Source Ports personal deal breakers

    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.
  8. dpJudas

    Source Ports personal deal breakers

    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.
  9. dpJudas

    Voxel rendering for S/W ports

    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.
  10. dpJudas

    Source Ports personal deal breakers

    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.
  11. dpJudas

    Stuttering in all DOOM source ports tested

    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.
  12. dpJudas

    Stutters on new hardware - DSDA DOOM and others

    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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. dpJudas

    So, GZDoom has replaced its sector light options...

    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.
  19. 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.
  20. 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.
  21. dpJudas

    Heretic HD PBR mod help

    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.
  22. You don't need a G-Sync monitor to get adaptive vsync. Any freesync monitor will do. DisplayPort standardized on freesync some years ago, which forced Nvidia to support that as well. The g-sync logo and chip only provide some marginal benefits now (supposedly, better image quality). Most of the monitors with a gsync module come with a fan, which actually makes me try to avoid them.
  23. When you run the nvidia installer there is a setting where you can request a clean install. That will reset everything back to baseline. I have experienced a situation where the information displayed in the nvidia control panel was out of sync with what the driver was actually doing. It could be what you are experiencing here as well. Generally speaking, you should be very careful using the nvidia control panel overrides. A lot of them are built on assumptions about the game engines that may not always be true. If you can find the setting inside a game it is always better to enable it from there.
  24. It is possible that what you are experiencing wasn't actually anything you changed in Raze. In fact, it is fairly likely it isn't since you say it also affected GZDoom. Although they do share code the config files are not shared. How did you enable antialiasing? From the settings inside Raze? Your dxdiag shows you have a 3070 - you should be able to enable every single heavy feature in Raze/GZDoom and have a perfectly smooth experience with that card. What about other games? Are they still running perfectly fine? Are the GPU and CPU temperatures okay when you run Raze/GZDoom? Did you try reboot? Windows 11 got this "amazing" feature that it doesn't shut down your computer when you select shut down. Only reboot from the start menu actually restarts the OS now.
  25. That's exactly why I objected to this description of the GZDoom project. Graf is the author of a lot of big important stuff, but trust me, if you removed all the other contributors from that list you'd get a quite gimped version of what GZDoom has become today.