LexiMax

No offense taken. I wasn't trying to lay an offense minefield or anything. It's just that gamedev is complicated and sometimes there are compromises that have to be made. Besides, I was never a fan of leaning on official releases as authoritative, because authoritative releases can be done badly. There's also no accounting for personal preference, despite however popular or unpopular the preference might be. This is why I like to stick to facts. Facts like the original artwork never being designed for bilinear filtering, and that kind of filtering being an undeniable source of lost or obscured detail in pixel art. I don't mind filtering pixel art on principal, but I don't understand the reluctance to at the very least choose a better default filter - be that None or something else. These days, most people's first exposure to Doom won't be through a hobbyist source port played on a PC - it'll be through an official port like the Unity port. I don't have a crystal ball, but that port will likely never support GZDoom content, or have bilinear filtering as an intended default setting.

I don't think there's really a point in attempting to disprove anything, as the assertion seems almost un-falsifiable. Even before you said so, I get the impression that this is really just as simple as "Graf prefers texture filtering enabled, and there's no talking him out of it." I still think it would be a good idea to open up a PR, even if Graf closes it. That way, if the question ever comes up again, we can just link the PR. I implemented that feature, in concert with the actual widescreen implementation. Part of being a professional is delivering on time and on budget with the resources you're given, and this was the easiest way to deliver a relatively niche feature (that being 4:3 support in a port that is natively widescreen) in the context of a patch for a game that was already released and working. I was juggling working on this port with my old day job, and the time that I could have spent implementing 4:3 in a nicer way instead went towards other features and fixes. Scuba Steve was the one who drew the widescreen versions of the title screens, by the way.

Personally, I think that it would be a good idea to open a Pull Request that has the desired texture filtering setting change - and nothing else, no bundling it with any other baggage so the individual setting has a greater possibility to be accepted. The merits can be debated on a forum all day, but if it's literally a matter of accepting/rejecting a PR that might make the medicine go down a bit easier.

On a console as resource-constrained as the original Xbox, it likely would've caused loading times to be significantly longer.

Exactly. The game assumes pixelated, and the typical asset creation pipeline (Photoshop, GIMP, Paint, etc.) assume pixelated too. Adding filtering on top of that is really only a good idea in two situations: You are "abusing" filtering of ultra-low-resolution assets to achieve a specific effect, like in Mario 64. Your assets are high-resolution enough to where filtering implements its intended effect and sands off the rough edges of the asset instead of just blurring it into non-distinction. Thus why I think it might be possible for a heuristic to be used. If the scale of the assets loaded spreads more pixels across the same area than a standard Doom asset, it's probably a safe bet to turn it on, otherwise leave it off. And if someone is extremely opinionated either way, they can be more specific in their own settings. The goal would be to provide a better first-time experience to a greater percentage of users. For what it's worth, I actually don't mind most GZDoom-isms, and the only reason I don't play the port more is because I've had far more affinity for multiplayer content than single-player content. But I do think GZDoom could have a better out-of-the-box experience in the filtering department.

Bilinear filtering on Doom textures is tantamount to turning off filtering in Mario 64. There are certainly folks who prefer it that way, and there are romhacks where such settings might make sense, but it's pretty clear what the sane default is who people who just want to play some Mario 64.

Why not have a setting heuristic that detects the kinds of assets that are being loaded and is smart enough to choose accordingly? For doom/boom/mbf content (i.e. the kinds of content that other ports can play), default to no texture filtering, but if high-resolution or truecolor asset is loaded then turn on bilinear. You could still customize it if you wanted, the default behavior would just try to intuit the best setting based on the content loaded in the current set of loaded files. Obviously, the specifics of the heuristic would need to be hashed out, but I can't imagine that there isn't a way to deliver doom-style graphics to doom wads and modern graphics with texture filtering to modern pk3's through a heuristic.

Kex Engine remasters actually make the old code (or are reverse-engineered versions of said code) work with modern API's.

I recently came across an reason why certain Doomers continue to use 32-bit that actually made a sort of sense in a niche way, and that's because 64-bit drivers don't exist for certain MIDI devices they prefer to use. Other than that, though, I agree. 16-bit x86 has a certain retro-computing allure to it because the world of 16-bit Real Mode is so different from modern systems, but 32-bit protected mode is just a 64-bit protected mode with less memory and fewer guaranteed CPU instructions.

For me, I consider peaking to be equivalent to output. I like trying new and fresh things, and if I don't have an "idea" I simply don't open the editor. By that standard, 2004 was far and away my best year because I finished around 10 maps and detailed and finished for other people a fair few more between ZDaemon CTF 1&2 and UDM3. I don't know that I'll ever be that productive or creative again. But what's wild is that my second most productive year was last year; 8 maps and a custom gamemode in 2022. So less of a single peak, and more of a series of peaks and valleys. I suppose the lesson is that your best days might actually be ahead of you.

Mixing Doom and Quake is well traveled ground - ZDoom's interface is largely copied from Quake 2's. If you want something a bit more than surface level, you would likely need to rewrite Doom's entire gameloop. Doom is very much not friendly to client/server networked persistence, and is very prone to butterfly-effect mispredictions due to the enormous amount of shared state and unpredictability of its gameplay logic. Not to mention that due to the constraints of early 3D and running so much of the game out of the network protocol and console subsystem, in many ways Quake is a strictly inferior and less flexible engine than Doom. Also keep in mind that Quake is more than 27 years old. The engine was a marvel for its time, but game engines developed since then have surpassed it in many ways, so if you're going to be rewriting Doom from first principles anyway, there are many better places that you can draw inspiration from.

If we're bikeshedding over a standard, I think that something with a schema like Protobuf3 would be a much better fit. The availability of schemas actually makes writing serialization code much easier for the supported languages and platforms, but the protocol is also simple enough to be parsed by hand without one. There are a few things I'm not a fan of (missing fields are assumed to be 0, varint encoding is not fast as designed), but i tried writing my own protobuf-alike for a work project and in retrospect wish I hadn't.

The current codebase is geared towards OpenGL and the development team hopes to claw back some GPU performance in the future by prioritizing Vulkan. Makes sense to me. 🤷‍♀️

For a feature-rich hardware-rendered port like GZDoom, compatibility should not be the only concern. Speed is also an important consideration, and to put it simply, OpenGL does not accurately reflect the way modern graphics cards render graphics anymore. It is supported as a best-effort compatibility shim, but being limited to OpenGL means that there is performance being left on the table, not to mention opening yourself up to a myriad of a nightmarish compatibility matrix due to the spotty OpenGL conformance of various drivers and cards. Besides, the future - and also quite frankly the present - is not OpenGL. It's not even Vulkan, necessarily. It's writing multiple platform-specific backends. nvidia has historically had the best OpenGL support. AMD has historically had less than stellar OpenGL performance. Intel OpenGL support has been dire for ages, both on their integrated and especially their discrete GPU's. The less said about OpenGL support on mobile the better, some of the implementations are just straight up broken and unusable for anything non-trivial. Apple never supported anything beyond OpenGL 4.1 and mothballed the API in 2018. Microsoft uses DirectX on their consoles, obviously. Sony uses their own proprietary API on their PlayStation consoles. Nintendo Switch uses whatever that Tegra X1 chips have on-die - which technically includes OpenGL, but also Vulkan and NVN. If you only care about PC's, Vulkan and Metal through MoltenVK are probably the path of least resistance these days. That will cover you for hardware going back a decade or so.

Not really. If you're using AI to write an article like this, and the result is this badly put together, then writing a good article wasn't really the objective in the first place, getting something put to paper to meet a deadline was. Jokes on them, though, I use adblock.

Every person is entitled to their good-faith opinion. It's the kind of argument you use to defend Civvie 11 not liking Redneck Rampage, or James Stephanie Sterling giving both Breath of the Wild and Tears of the Kingdom a 7/10. But I think it's clear to the thread that what was linked is either AI-generated or an SEO clickbait article that was rushed out to meet some sort of deadline, which is evident by the fact that it was ranked in release order and hardly makes sense as English. Which just goes to show - if you want good long-form content, you need to pay for it.

Our discord would be a good place to start: https://discord.gg/aMUzcZE We have highlight groups set up so you can ping people for a game, and every Monday we also run a weekly session on our Horde gamemode. And for what it's worth, I'm actually unsure if it's possible to implement Horde in GZDoom - at least not in the mod-friendly way we did it, with a custom HORDEDEF lump and everything.

When these sorts of discussions happen, it's a lot easier to frame justifications for using other ports in terms of GZ's few shortcomings. Because honestly, why not use GZDoom but for those shortcomings? After all, GZDoom is by most measures a very usable, capable, and moddable port.

MF DOOM. All caps when you spell the man's name: Rest in Peace, Daniel Dumile.

This is a definite strength of GZDoom, but there's a gigantic asterisk attached in the form of its netcode. A missed opportunity, imho.

On a technical level, I can understand the lighting model. But not texture filtering. I'm sorry, but this does not look good. It almost looks like I need to clean my glasses or monitor.

GZDoom as a codebase is very difficult to "fool around" with, from a code point of view. Other ports are much easier to build, and much easier to make code changes to and actually see the results. I think that lively ecosystem of Chocolate Doom and WinMBF forks is proof positive of this, compared to the relative dearth of ZDoom forks post-GZDoom 3.0. Also, not only is modern GZDoom not a great multiplayer port, but it's also not a great port to base a modern multiplayer port on top of. Too much is exposed to ZScript, which leaves not enough places for networked persistence to "hide" like they could in older ports like Zandronum and Odamex. The last thing is kind of minor in that visually, I don't like GZDoom's defaults. Doom's art was not designed for filtering, and it's beyond me why in TYOOL 2023 GZDoom still defaults to blurry textures, sprite filtering, and a flat lighting model that frankly looks pretty bad on original Doom content.

What would this break? I think I remember some 90's games depended on MMX (the one I remember specifically was Sega's PC port of Virtual On), but is there some other widely-deployed thing I'm not thinking of?

Why doesn't UDB work in Parallels?

Modern x86 actually still boots into 16-bit mode natively. The boot sequence of the OS is responsible for transitioning into one of the other modes, which is usually 64-bit mode, and once you're in a more modern mode generally you can't go back unless you reset the CPU. So if you truly want to run 16-bit code on bare hardware, you have to boot into a 16-bit OS like DOS and stay there. So how does DOSBox run 16-bit executables? The same way NES emulators work - by emulating the hardware. This is by far the better option for most people, because if you're emulating the CPU you're also generally emulating all of the 90's era peripherals that were designed to work with DOS - which you would otherwise have to buy off ebay or something equally silly.