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

dpJudas

Members
  • Content count

    346
  • Joined

  • Last visited

7 Followers

About dpJudas

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. dpJudas

    unpopular retro opinions

    The reason your post annoys me is simply that you take a monitor from a different era and uses it as example of why scanlines were certainly a thing in the 320x200 era of gaming. Don't forget which post from Maes you originally replied to. Now I'm sure you will reply that you didn't say anything about which era you were commenting about, or find the most expensive office monitor around from 1995 to show you could theoretically experience it. :)
  2. dpJudas

    unpopular retro opinions

    I'm not denying that there aren't scanlines with such a monitor in 320x200. Rather, I'm just saying that if you put an emulator on that shows scanlines like that then it isn't remotely looking like how most people would have seen the game on a CRT from the mid 90's.
  3. dpJudas

    unpopular retro opinions

    Yes, but by the time most people had 21" Trinitron 1600x1200 capable monitors they were way past the 320x200 era. At least I was playing Direct3D games like Unreal Tournament at 800x600 or higher on such monitors.
  4. Hey nobody is saying you have to buy Nvidia or a RTX card. I didn't buy mine for the RTX cores. But now that I have them I might as well have some fun with them. :)
  5. Snarky overreaction indeed. Toying with your hardware and testing what you can do with the RTX cores is entertaining! Stop being so negative and join the fun!
  6. I do actually have cards with RTX support (ZDRay has support for using it), but that's not really why it isn't there. GZDoom is used by a large modding community - you need to implement a version that gracefully falls back for those with older cards. That, and the large feature set of GZDoom mods makes it a much more challenging task. Incidentally that is also what killed the PBR textures in GZDoom since I couldn't get it to work well enough within those boundaries. Getting the actual hardware is the least of the issues with adding this. About what is and isn't ray tracing, I consider anything that shoots ray queries into an acceleration structure as ray tracing (*). The term is used in so many different contexts that I think it is okay to advertise it as that. Path Tracing is simply one of many ways you can utilize ray tracing. Lightmap generation is another example of not shooting the rays from the screen either. Most commercial ray tracers use a mixture of ray tracing acceleration techniques to get what they want, as doing things only in the most classical ray tracing way will always be way to slow to be of practical use. Oh and if you think ray tracing is an abused term then try global illumination. Everything just remotely ray traced is claimed to be GI now. :) *) This definition actually also means a lot of collision detection falls into the ray tracing category. :p
  7. The whole point of always starting with a new branch is that you don't need to do any cherry picking, and you don't need to reset the master branch either. If you like your PR to be a single commit then squashing too becomes trivial. Even if upstream squashes your PR it all just works. It is literally achieving what Gibbon seeks without having to delete the fork and start over every time. Oh and just for the record - it isn't like it is actually hard to create a branch: git checkout -B <branchnamehere>. So it is actually even faster than Gibbon's approach because you don't have to clone all over again. That said, if I don't continuously work on a repository I tend to delete my forks as well, but that's just because I don't like to look at a long list of forks on my github page. :)
  8. It is much easier to start any work by first creating a branch in git. Then PR the branch instead. When it is merged upstream you can simply delete the branch. That way you don't have to fork again and again.
  9. GZDoom has an implementation of some of the optimizations. In particular the one that splits the scene into multiple slices for the BSP.
  10. Okay fair enough, I agree that those quotes clearly indicate they actually wrote the glide driver themselves while outsourcing the other two drivers to contractors. So I guess you're right about that. You should take the quote about OpenGL there with a bit of salt though. Their original OpenGL driver was never stable at all, which is why you had to explicitly insist on using it (via the radio button for unsupported drivers). It wasn't until Daniel Vogel started to fix the driver that it became actually usable. That didn't happen until the UT public source release for Linux. That's because the original version left out a few render states that both glide and D3D had implemented. Early on the OpenGL version also suffered greatly from mouse lag - at least on my system. I personally knew Daniel Vogel at the time, so I know he didn't work at Epic until later (in fact, doing this volunteer work was the way he landed that job to begin with).
  11. I don't know about that. Originally the DirectX renderer was far better than the OpenGL one. So much so that OpenGL wasn't even officially supported by the game (you had to click a radio button for unsupported renderers to choose it). It is also debatable if it was a Glide-based game as it released with all three renderers.
  12. This most likely has something to do with the vulkan backend not resetting the descriptor sets or image views for textures/materials that changed. Given that it only happens for palette mode, the most likely candidate is that the palette texture changes when you play around with those settings (for reasons unknown to me, since it seems they shouldn't really affect that texture, but the internal workings of the hardware renderer layer is often exotic and nonsensical) and then the descriptor for the software renderer material isn't updated. I don't think it is an AMD specific bug. The bad news is that I won't hunt down this bug and fix it for you. And if I don't do it then nobody will. You will have to switch to OpenGL or just accept this as one of the quirks of the current vulkan backend. Sorry. Maybe sometime in the future both backends will be done by the same author and then maybe you will see an improvement. The nature of vulkan makes it impossible to implement the contract between the hardware layer in GZDoom and vulkan. The hardware layer simply isn't stable enough (too many authors dicking around with it) and vulkan too unforgiving whenever those changes to the HW layer breaks something that OpenGL blissfully would have handled automatically for you.
  13. You mean the rounded corners on the windows and the uxtheme update? Visually I find it a slight improvement compared to Windows 10, but like I said, I barely even notice. Both are kinda ugly, just in each their own way. The start menu was trash before and is also trash now, just in a different way. Big deal. :) So, a +3% speed increase in some of the tested game titles on Windows 11, and a -3% speed in the some others. With most of them hovering around +-1%. Huge performance issues indeed (read: no it's not, marginal at best). That data was from your first link. Trust me, without a benchmark tool you wouldn't be able to tell the difference. I agree there are a lot of reasons to dislike Windows 11 - the telemetry and candy crush bundling in particular. But here's the thing. Those things also apply to Windows 10. Only difference is the home edition is now officially useless for anyone not wanting a MS account. And no, you can't use the argument that because you can find a 100 dollar gold plated edition of Windows 11 that this is the normal price for the product. I didn't search hard to find a 16 dollar version - it was the first link on googling when I bought it. By this kind of logic Linux isn't free because I can buy Red Hat Enterprise Linux Server for 349 dollars!
  14. Seems pretty silly to make decisions based on rumors, but maybe that's just me. If you want to use Linux then use Linux, but please don't pretend that Windows 11 somehow was the magical red line crossed that Windows 10 didn't have. The two OSes are virtually identical. So much so that I tend to forget which one I'm using. I bought Windows 11 Professional version for 16 dollars. Let's keep this gigantic expense in mind when we are talking about how outrageous a request it is to switch to the pro version.
  15. The differences between Windows 10 and 11 are so tiny that there no real reason to bother upgrading. You aren't missing out on anything important by staying on Windows 10. Personally I would just stay on Windows 10 until it actually reaches EOL. At that point your current PC should be fairly old anyway. Switching to Linux should IMO only be done if you have some special interest in the OS and want to try it out. It shouldn't be because you can't move to Windows 11 on your current PC. At least not until the EOL date. PS. What's with this silly notion that the NT kernel should be inferior to the Linux kernel? Unless you are actually working on kernel drivers then who cares? When I run Linux on servers it isn't because of the kernel - it's the easier user space (SSH with unix tools vs RDP with cmd/powershell is a slam dunk victory to Linux), that it only does what I asked it to do, and that it's free.
×