/vr/ - Retro Games

>Zoomer revisionists now want one of the most demanded features of GPU's gone

Fuck off, texture filtering is objectively better in the majority of cases. The only exceptions are highly synthetic textures that align perfectly with the sampling grid.

>Fake detail VS natural smoothness
The rule of thumb is very simple. Anything that reasonably approximates reality should be filtered. Anything that is heavily stylized and low-res benefits from sharp edges.

>>6125126
>visually defined.
Except that's not how texture filtering works, with most dumbshits thinking that it just applies a good old random blur over a texture.

Texture filtering works by reading additional samples from the texture. So while unfiltered would just grab the nearest texel and turn it into a pixel, filtered grabs the 4 nearest texels, does a weighted average on them, and then a pixel is drawn from that. Due to the additional sampling, the image is OBJECTIVELY more visually defined than unfiltered.

If I were to give two people a piece of paper to try and accurately trace the shape of this lava blob, with one person getting the filtered image and the other getting unfiltered, the person who got the filtered version would do better because you can obviously better make out the shape.

>>6042996
Generally speaking, no texture filtering makes textures look worse. Texture filtering is a bit like supersampling in that every drawn pixel is generated from multiple texel samples.

It would be idiotic and backwards to not at least have it as an option.

>>5389706

>>5250969
>no billinear filtering so you can actually enjoy the textures.
oh no, it's a brainlet

>>4582814
>IDK where you heard that bullshit, but it's outright false -there were never any extra low-res versions of the textures in the games, and no OpenGL implementation that I know of downscales textures prior to filtering.
You must be really young or something. It's famous that early 3D cards like the first three Voodoo cards had a hard texture limit of 256x256, and also textures with power-of-2 sizes. The OpenGL/MiniGL implementations of software mode games that used higher resolution or textures with unusual sizes/aspect ratios either had to be reduced in resolution or cropped.

GLQuake is the most infamous example, but there are plenty of others.

>Bilinear filtering the fuck out of details could be mistaken for lowering texture resolution, but in actuality, texture res stays the same.
It actually improves the perception of detail because it is similar in principle to supersampling (every bilinear filtered pixel drawn pulls on 4 texels instead of just 1). Check my picture for a good example. You can actually make out the shape of the lava and its finer details, while a lot of that is lost to aliasing in the unfiltered image.

>Example:
Pixel art doesn't filter well because it REQUIRES high contrast to be effective. So this is a deliberately bad example. This is why Doom 64, while still using 2D enemies had them generated from prerendered 3D models, because they have more realistic contrast.

On the other hand, look at how the acid water is improved by bilinear filtering.

>>4150395
>filtering removes implied high-frequency content in small, hand-crafted textures (read: hard edges)
>the resolution is high enough that you don't need the hard edges of aliasing to imply high-frequency visual content -- it's naturally there in the texture
As mentioned before in previous threads, this is not only wrong, but unscientific. There's nothing to differentiate the operation of texture filtering between small and large textures. The algorithm is identical and functions in a linear not exponential manner.

Even with textures which are the absolute lowest of the low resolution. See pic related for the absolute extremes of low resolution, filtering is of benefit. Without filtering the tree stem looks like a a complete glitch - with filtering it actually gets more definition. It makes sense, because texture filtering has algorithmic similarities to supersampling anti-aliasing - which is anti-aliasing via rendering at a 4 times higher resolution. Bilinear texture filtering involves reading the texture 4 times more than non-filtering - so it's almost like reading a higher resolution source texture.

(True) high frequencies are highly uncommon in real life, and so do not represent detail. Otherwise nothing in real life would be detailed. Detail simply comes from variations in colors - drastic differences between them are not required. In almost all situation, high frequencies are just digital noise.

>>4112943
>yet not at all indicative of the general quality of games on that console
But that wasn't your argument. You were saying that improvement was impossible due to the hardware/cartridges.

>I'm not aware of any N64 games that make use of a lot of dithering that would need to be filtered
Oh, so I guess you really don't know what you're talking about. Almost every N64 game (and Saturn and PS1 for that matter) uses a 16-bit framebuffer which is inherently prone to mach banding / dithering artifacts. A dither filter is required to remove these artifacts. Both PS1 and Saturn do dither filtering, but the N64's filtering is much more aggressive and thorough. This causes blur though because the colors are blended with each other to prevent clearly demarcated mach bands from appearing.

>Bilinear filtering makes shit blurry, that's what it does. If you think it does not, please let me know what you think it does do instead
It does make textures a little blurrier but only a little bit. Pic related.

Your images on the other hand, including the one here >>4112947
look like textures which have had their UV / tiling / mipmap coordinates incorrectly set by shitty N64 emulation.

The other thing to remember is that many N64 textures were pre-filtered to counteract the "rupee" triangulation artifact of N64's unique 3-sample bilinear filtering. N64 emulators use 4-sample bilinear filtering so their filtering doesn't play well with the pre-filtered N64 texture.

>>3998616
>if the textures are 64x64, I want to see them the way they were meant to be, not a blurry mess
Don't give me this "filtering is only good when the textures are big" meme.

Filtering will almost always make textures look better, no matter the size.

>>3735856
>Could you back that claim up?
The site that did the comparison doesn't seem to exist anymore, but it's pretty easy to verify if you extract the models for both systems.

Basically the Mario model in Mario 64 (and quite a lot of enemies) use a LOT of unnecessary extra polygons, but you can pretty much chalk that down to inexperience with 3D at the time.

>That's not to say texture filtering is bad - it looks fine when the textures are relatively large. But textures on the N64 and DS were just too low resolution for it to look like anything other than a muddled mess
No, this is pretty much rubbish. No matter the resolution, texture filtering will (almost) always look better in 3D. The only exception is where pixels will always align with the grid (e.g. 2D games or "vector-style" textures.

However, liking nearest-neighbor arbitarly-rotated "raster-style" textures is perfectly legitimate for nostalgia or novelty reasons. I know it gives people the kicks to see big pixels and go "woah I'm playing a fucking old game".

The problem is there are many instances where N64 games used lower-resolution textures than PS1, and that is where the muddiness comes from. Part of that is due to technical difficulties with programming the system, but part of that is simply that N64 had more "open-world" games where you have to display a larger number of textures simultaneously so each individual texture has to be lower-resolution.

Also N64 emulators can't replicate N64 texturing for shit. UV coordinates are usually wrong, and the filtering itself is fucked. Many N64 textures were pre-filtered with the expectation of being subject to a triangulated form of texture-filtering. When you expose them to the quad-filtering used in emulations, it distorts the textures making them even blurrier than the real console.

>texture filtering is bad meme

>>3086923

>>2794594
>smoothing out something this low-res produces horrible results
Objectively false. Pic related. Texture filtering almost always looks superior to nearest-neighbor (for textures of identical resolutions) unless the pixelated look is required for a particular artistic style.

Most people think that texture filters are some kind of blur algorithm that works on top of the final product, but this is simply because they don't understand how texture filtering actually works. Bilinear filtering uses 5 times more texel data to create pixels than nearest neighbor does, because you interpolate a texel color with four surrounding texel colors, rather than just grabbing the nearest texel color and just losing whatever texels existed between those pixels.

>>2794606
> it made the blocky structures more obvious
That's because it was a poor implementation of texture filtering, like most early hardware acceleration ports.

You have to interpolate the edge texels of textures with the texels of adjacent texels, otherwise you get a visible seam artifact. This is one of the reason shitty emulation of N64 games produces texture seams that don't exist on the real console.

>>2708468
>The N64's heavy filtering was more likely due to the way the hardware handled texture buffering
No, the N64 can do texture filtering because the GPU has a dedicated Texture Filtering (TF) unit in its texturing/rasterization pipeline. The hit to performance from activating texture filtering is very low due to this dedicated piece of hardware (although not completely free).

>the N64's main graphical bottleneck was a small amount of RAM dedicated to storing textures
No, the bottleneck is due to the memory bus architecture in which all textures must be explicitly loaded from the texture cache in 4KB allotments. The Playstation offers programmers the flexibility of loading textures either from its 2KB texture cache or from a texture page in its 1MB VRAM.
>MM made use of the RAM expansion pak that allowed for larger textures.
No, the Expansion Pak does not have any affect on the size of individual texture allotments, it will always be fixed to 4KB on N64. With a larger memory though, you can have an improved dynamic loading pool to make streaming into the texture cache more efficient though.

>>2708497
>On the PS1, you'd end up using a bit more polys (for texture position accuracy
Sort of. You need more triangles for large surfaces on PS1 to reduce the distortion caused by non-perspective correct texture mapping.
>pre-blurred texture
You can't pre-blur textures Nearest-neighbor will always make textures pixelated. Generally PS1 textures look better cause they are higher resolution, there's no other secret.

>>2708521
>instead of using gouraud shading for everything else
False. PS1 games tend to use far more extensive gouraud shading than N64 games. This is because loading textures from PS1's VRAM is very expensive, so you load several high-resolution allotments and shade the rest. Also because the PS1 needs many more polygons for texturing than N64, gouraud shading has an additional benefit there.

>>2581494
>Try to draw sharply outlined features (sign on a wall, artificial object on the floor) and bilinear filtering will fuck you hard, turning your sharp outlines into a mess
Then you don't render sharply outlined features with bilinear filtering, and you do with things that are not. It's not an all-or-nothing approach (unless you lack the ability to filter, that is).

>Your outcast image is misleading, as that's interpolation of the voxel heightfield
Yes, you are correct. I pulled the wrong image.