|Posted by Dynamo on 2023/08/25 11:43:02|
|For those who have not heard it by now, on the 10th of this month, during the early part of QuakeCon 2023, id Software and Nightdive Studios released the remaster of Quake II, featuring all previously available content and the two original expansions as well as improved visuals, gameplay enhancements, the inclusion of the Quake 2 64 campaign, the PlayStation exclusive enemies, and finally brand new episode by Machine Games, called "Call of the Machine". The remaster is included as a free upgrade to people who already owned Quake II on digital storefronts, and has also been made available to modern consoles.
Read more about it here: https://bethesda.net/en/article/6ucW3H8R8mYDWrn3ndqgYX/quake-ii-enhanced-release
Better Late Than Never
It's great that this remaster finally came out, as I've been a fan of both Quake 1 and 2 since the late 90's. Since we got the 25th anniversary remaster of Q1, I was a little bummed last December when basically nothing happened for Q2's 25th. But now it's happened, and it doesn't disappoint! And I knew MachineGames would do a good job with the expansion, especially since techbases are right up their alley (though they also added a nice tie-in which I won't spoil here.)
How Would U Rate The Missions From Call Of The Machine Episode?
I would say
Corpse Run and Laser Eyes top,
Searching for the abused keyboard configuration.
All These Streamers With Zero
texture filtering but coloured lighting.
YOU CAN'T HAVE BOTH!!! IT'S ILLEGAL!
Those Lowres Textures
Look really blurry with filtering on. Being able to turn that off is a blessing. But I'm digging the new dynamic shadows and lighting (just like they did in the Quake remaster).
The guy behind KEX Engine seemed like a cool dude but it really irks me that Nightdive just re-releases old games on that engine. They completely disregard all of the amazing source ports that a few or even just one dedicated developer worked to maintain for all these years. There are people painstakingly reverse engineering logic from binaries in order to remain faithful to the original engines but Nightdive just disregards all of that.
I understand that some of this might be due to licensing issues but there has to be a better way.
But they look really pixelated with it switched off. I mean surfaces in real life don't look blurry. But they don't look like grids of square colours either.
I understand what you're saying, but licensing restrictions are more than you might think. In particular Nightdive have been making these games available on modern consoles, which are a much more constrained ecosystem than PC. Incorporating code from (in particular) GPL source ports is just not legally possible; Nightdive don't have a choice but to disregard other people's work, and that shouldn't been seen in a negative way, it's just them doing what they legally have to do.
Which textures are too blurry or pixelated? Q2 has most of textures as 64x64 or 128x128, same as Q1.
Well, enabling the CRT filter reduces the screen resolution a lot, making the textures look more like in the 90s.
Fact: The first 2 Quake games were made to run primarily at 320x240, and that vertical resolution of the screen is only 3.75 times bigger than the vertical resolution of a 64x64 texture.
Meanwhile, today's full HD screen resolution is 16.875 times taller than a 64x64 texture.
This means that to actually give the same visual impact of a 320x240 screen, full HD screens needs textures to have dimensions that are 4.5 times bigger. Which is why I'm planning to use 4x natively sized (not upscaled) textures when I manage to create my own game.
Yes, Quake's texel density is very poor nowadays. There's a significant reason why most visually praised maps nowadays are big maps with huge open areas; the farther away the textures are, the closer their texel density is to the pixel density of the screen.
If texel-to-pixel density was not an issue you wouldn't see people favoring 1024-sized or 2048-sized skyboxes nowadays. Nobody releases a modern map with a 256-sized skybox nowadays, despite so many people claiming to love blocky textures.
I Always Think Of Quake As
THE 3dfx Voodoo II game. So 640x480, bilinear filtering. (yes, I know it would also run at 800x600) And that sick coloured lighting. I'm pretty sure that it was developed with hardware acceleration in-mind. But yes - when I first played it on a P133, it was 320x240. My SIS graphic chip could manage about 1 fps with OpenGL mode :D I still looked at it though, to see the beauty.
The development of Quake 2 can be traced from John Carmack's .plan files in 1996 and 1997. The lineage is clearly a merging of the Quake and QuakeWorld executables with a switchable renderer added on. There's grumbling about having to still support software rendering and 8-bit colour, and this is substantiated by independent comments made by Brian Hook.
I don't view there as being any intent in the texture sizes or texture mode defaults. The pragmatic reality was that in 1997 3D accelerator market penetration wasn't sufficient to do a hardware-only game. This was even viewed as a risky enough proposition when Q3A was being developed, even though hindsight has proven it to have been the correct decision.
For 1996/1997 class hardware CPU and memory constraints were a reality. We're too accustomed to being able to max-out games these days, and then complaining about lazy developers and unoptimised code if we can't. Nobody couid max-out Quake 2 for several years after it released. I clearly remember PC magazine benchmarks from the time.
Linear filtering was new and for many people GLQuake and Quake 2 were the first time they'd ever seen it. In cases where something is new people often overlook flaws, especially if it is seen as solving other perceived problems.
At 64x64 a texture contains lots of fine texel-level detail. Individual texels are important, and blending them with neighbouring texels can cause this detail to become smudged, smeared or lost. Irrespective of opinions on intent, that is the pragmatic reality. It then becomes a matter of preference, and whether or not one is willing to accept the trade-off.
For remastering Quake-technology games my own opinion is that moving to 32-bit colour is more important than moving to a higher texel density. High resolution textures on low polygon geometry look very incongruous. Other people's opinions can differ.
Well, I said nothing about intent. I strongly suspect that the texel-to-pixel density in id's software-rendered FPSs (Wolf3D, Doom, Quake 1&2) evolved organically, with each game simply following the density of the previous versions.
If I recall correctly, their first textured FPS was Wolf3D. For that game, the texel density was probably defined by the artists, based on the amount of detail they wanted to define on the enemy characters.
That's a pretty safe assumption, because the enemies have the minimum resolution possible for expression: 1-pixel diameter eyes, 1-pixel high mouth, etc. Combine the player's bounding box with the walls having the same texel resolution as the enemies, and you'll get a well defined standard of texel-to-pixel ratio from the viewpoint of a player directly facing a wall.
All that defined organically, with no strict plan or calculations.
Quake 2 simply inherited the texel density from Q1, because the Q2 engine was much more about polishing everything from the Q1 engine than about replacing the tech. Its major technology change was in the switch from the QCVM to Windows DLLs, iirc. Quake 3 seems to have a higher texel density, but I can't confirm it at the moment.
Anyway, what I'm talking about is about reaching the same visual impact of Quake's textures in a 320x240 screen, which was the default resolution of both Quake and Quake 2.
The higher the video resolution, the less impactful the textures closer to the camera will look. Saying that texture resolution doesn't matter is false, because even in the mid-90s there were clear cases of low-res textures being frowned upon (see all the PS1 vs N64 debates). Also, Quake 64 looked awful mainly due to its very low-res textures, while Doom 64 is one of the best looking games on the platform thanks to having one of the highest texel densities in the entire N64 game library.
From my thousands of hours of analyzing Quake in all kinds of possible resolutions, the Q1 texel density is pretty much in a sweet spot for low-res video modes. Back in the early 2000s, I always played at 512x384 because that's the highest resolution at which the polygons would be clearly defined and the textures didn't look too blocky for me. 640x400 and higher would make textures look too blocky already.
Anyway, texture filtering certainly changes the visual impact of the textures, and I'd say that with texture filtering enabled, Quake's texel density is best suited for a 480p resolution instead of a 240p one. This still implies on textures needing to have at least twice the texel coordinates resolution of Q1 in order to not look outdated on a full HD screen (however, in my engine that applies dithering instead of bilinear filtering, 2x still looked too poor). I'm not saying this as a hard science, but as a parameter analytically extrapolated from my subjective judgment.
But when it comes to remasters, I agree that increasing the color depth can be a more sensible approach than increasing the texture resolutions, because most of the original textures will not have natively higher resolution versions, and texture upscaling algorithms often looks unfaithful.
I'm probably commenting more on suggestions that Quake 2 was intended to be run with OpenGL and bilinear filtering. I'm not sure about that intent; I do know that id viewed it as their preferred platform, but with the caveats that they were also working within the constraints of a software renderer, and that all of this was new technology and they didn't fully appreciate the tradeoffs involved.
Quake 3 did increase the texel density which did look better with linear filtering.
Different things annoy different people in different ways. I personally feel that Quake 1 looks amazingly crisp and solid at any resolution with GL_NEAREST_MIPMAP_LINEAR filtering. But any kind of noise on minified textures drives me utterly nuts, and I can find myself needing to switch off anisotropic filtering on some hardware. Likewise I can't use FitzQuake on account of it not mipmapping certain textures, irrespective of how true to the original software Quake that might be. Likewise for software Quake itself.
You must be logged in to post in this thread.
Website copyright © 2002-2023 John Fitzgibbons. All posts are copyright their respective authors.