/vr/ - Retro Games

>>6108936
>there comes a point where you should definitely cross over
No there isn't. If the textures already look so terrible, like in your pic, filters won't save them.

>>6108936
Make a distinction between "textures" and "sprites". "texture" is usually in reference to the graphics being wrapped around 3d models. If a game is 3d, there isn't much of a down side to scaling the textures. If a game is 2d, then filters impact the entire screen at once and you can get some odd results from using filters.

>>6108946
I'm referring exclusively to 3D. 2D is a whole different matter, of course, and you wouldn't want to use bilinear upscaling for that.
Some choose to use nearest filtering even in 3D games, going so far as to say that it fuels the soul of Playstation games.

The rule of thumb is try you options available and choose whatever looks best for you.

>>6108961
It's common for 3d games to use mipmapping. It's a clean way of down-sampling textures at different distances. You can consider a texture filter to be doing something similar in the opposite direction. If you apply a xBRZ filter, it will only be in effect when you are standing so near to an object that the normal texture would have been exhausted. For all the objects that are more distant, you won't see the effects of the filter at all.

>>6108936
Basically anything that doesn't use sprites benefits from it's usage on PC. Console games I think should be left as is.

Don't be greedy. 2x is enough.

>>6108937
Yes they will. All the linear example in his pic needs is some scanlines to artificially add some sharpness to the texture, making it a slightly smoother version of the original that maintains most of the detail.

>>6108936
Filter textures, integer nearest neighbor scale pixel art. OP pic is clearly pixel art.

>>6108936
If textures were made to be seen filtered then filter them.

Who's gonna post that retarded fucking image of Ocarina of Time with no texture filters to try to convince us that it's a bad technique?

>>6108936
This depends on amount of details represented by a group of pixels. If details are represneted by low amount of pixels, filtering would butcher it.
If details re represented by high enough amount of pixels, then its ok.
Generally the point of crossing over is when the textures exceed the size of 256x256

However there are some instances where filtering is intended or not intended by the creator, which should be viewed on case-by-case basis. Note that N64 devs generally didn't have much of a choice, since disabling the filter would require more code than just allowing hardware to do it.

>>6109278
256 is pretty damn high. Textures were already being filtered en masse before that became the average.
I say it depends on the bit depth.
A shared 8-bit palette > Unfiltered
Anything higher > Filtered

>>6108936
depending on platform, composite and/or crt shaders, so it looks like my actual consoles instead of banded, pinstriped, checkerboarded

>>6109320
its literal dithering magic
https://imgur.com/a/tvwJDhY

>>6109312
>Textures were already being filtered en masse before that became the average
mostly because it was a hip and "high tech" things to do

>>6109225
This. You can’t have a conversation about texture filtering on retro games without scanlines.

>>6108936
Just choose the one you like more. I prefer playing Thief without texture filtering, but for example Deus Ex looks horrible to me in software mode.

>>6109278

Point to note about fine grained control if you have a choice here for OpenGL. If you are using anything below 1024x1024 (1K) textures, GL_NEAREST_MIPMAP_LINEAR is best for stuff like Doom and whatnot. Otherwise, for above 1k textures which is for nothing outside of heavy mods as far as this board is concerned, GL_LINEAR_MIPMAP_LINEAR works best. Not sure you have a choice for doing this on DirectX.

>>6110031
tell that at /doom/ and they will lose their unified shit, same goes to quake.

>>6110234
you know nothing of /doom/ as that advice comes directly from there

if it looks like an n64 game (shit) don't use it.

It really depends on the game, for Doom I say don't do it in-engine at all but instead use the textures / sprites from this neural upscaling project :
https://www.doomworld.com/forum/topic/99021-doom-neural-upscale-2x-v-10/

>>6108936
>but there comes a point where you should definitely cross over.

Which is?

>>6111410
Nevermind googled >>6109269 and it looks like shit

>>6110031
>(1K) textures

Where did you even get this idea, that is 2x more than what even this board would experience with game textures in modern indies like Minecraft. 1k is purely in the realm of modern gaming.

For any sort of modern gpu, you should always use linear mipmaps or *_MIPMAP_LINEAR, along with x16 ansiotropic filtering, far away objects scaling with the minification filter for textures without either look like shit if you use nearest or no ansiotropic filtering. So what really makes or breaks visual experiences is the magification filter for textures, where we have nearest or linear as a choice. My personal cutoff is that you use GL_NEAREST_MIPMAP_LINEAR for everything 128x128 and lower, which happens to be where /vr/ cuts off, so anything related to the board as it is right now, just use that. Anything 256x256 and above you use GL_LINEAR_MIPMAP_LINEAR, outside of the scope of the board right now.

Unfiltered looks better if the game has consistent texel density. Filtered looks less bad if it doesn't. Games with texel density all over the place generally don't look very good though.

>>6112105
This guy gets it.

>>6111410
>me at the park with my PHAT ASS gf and her pet monkey

>Everyone that's played Doom knows that when you get close to a wall, all those block-like pixels really stand out.
The Righteous however does something called bilinear filtering which smooths out low resolution textures for
a more sublte apperance.
>Watch this. Not bad

>>6112478
>bilinear vaseline
No thanks.

3D games in 90s looked great when they were designed to be blocky, later games from 2000 looked worse.

>>6108936
I always used interpolaton on Zsnes. Might have did a 25% scanline if I was feeling cute.

>>6112504
Nah, I like the early days of "texture filtering is the norm now"

>>6112486
What retarded image is this? That's just a shitty framebuffer upscaling.

>>6112119
Jeez, that HUD actually looks good unfiltered. Why couldn't they design the N64 so that it would only filter some elements on the screen and not others?

>>6109269
But that's only because they made the game literally with filtering in mind.

That's the only reason it looks good. If it's not built from the ground up to use it then it looks like shit.

>>6113320
>That's the only reason it looks good
Ocarina of Time does not look good.

>>6111410
filtered like this?

>>6108936
It would depend on the game, but anything from like Unreal and forward should have filtering on. Quake 1 and 2 look way better with it off, though.

>>6113268
>Why couldn't they design the N64 so that it would only filter some elements on the screen and not others?
It can do exactly that. It's entirely under the control of the programmers. The HUD is not filtered on real hardware, it matches the output resolution so no scaling of any sort is needed.

>>6109278
>Note that N64 devs generally didn't have much of a choice, since disabling the filter would require more code than just allowing hardware to do it.
This is a myth. Stop repeating it.

http://n64devkit.square7.ch/pro-man/pro12/12-05.htm#01

Wow, look at all that extra code that N64 devs required! gsSetTextureFilter(G_TF_POINT) instead of gsSetTextureFilter(G_TF_BILERP)!

>>6108936
Also the answer is just depending on art style. The people who say you need over a certain res or color depth are full of shit. Filtering can rescue low res / low color textures, it just depends on the design.

I’d say as a general rule of thumb, highly ‘ordered’ textures like brickwork don’t need filtering to look good (and filtering can make them look bad), while for chaotic/natural looking textures it’s the opposite.

i hate any filtering whatsoever on sprites. i like em raw, crisp

>>6113890
What are some N64 games that used nearest filtering outside of 2D graphics?

>>6108936
Bicubic.

>>6114278
Background skyscrapers on Perfect Dark’s first level

>>6113890
>Wow, look at all that extra code that N64 devs required! gsSetTextureFilter(G_TF_POINT) instead of gsSetTextureFilter(G_TF_BILERP)!

I dunno where the "extra code" thing comes from but I can tell you that turning off bilinear filter was an automatic submission fail in the early days. The rule was your game couldn't look like a PS1 or Saturn game so you had to plead your case if you wanted to use nearest neighbor.
Similar things were with the z-buffer. They didn't want you turning the z-buffer off and doing your own z-sorting. But in that case they couldn't stop you since you always have to manually sort something. In that case it was a fail if >Z polygons were rendering in front of <Z polygons in a noticeable way.
Basically all PS1 mainstays, affine mapping, z-fighting, wibbly vertexes, etc. were failures and given that, it's no surprise that everyone just ran full features on and damn the slowdown just to appease the big-N.

>>6115590
I think that stuff in your post is all a myth too except for the z-buffer one. IIRC Nintendo really did fail games for release if they found polygons rendering in the wrong order.

The difference is that the former is just called not using a feature, while Nintendo classified the latter as actual glitchy graphics (even though it was standard on PS1).

The N64 manual pretty openly suggests that not using AA for example was fine, so I doubt they forced anybody to use bilinear.

>>6115715
Forgot pic

>>6115715
This is the pic I wanted to upload

>>6115715
My information is kinda second hand. I worked in an office that made shitty N64 ports and the programmers told many a tale of stuff Nintendo was failing the stuff for and not using bilinear was one of them. I think maybe Nintendo just had a nebulous "quality" metric that you could fail if the QA guy thought you weren't showing the hardware in a good light. Bearing in mind the N64 era was when Nintendo was at height of their dickishness.

>>6115723
AA is different though. Bilinear is usually "free" in terms of texel fill rate and it can be turned on and off at will without any changes to the rendering code. AA drops fill rate noticeably and worse, it causes problems with z-buffering and transparency meaning that turning it on requires that you model your rendering path knowing the problems you are causing and how to avoid them.

>>6115736
Fair enough point about performance, but you could argue too that the N64's AA was its single most advanced feature (unlike other edge AA solutions, those issues you mentioned about z-buffer and transparency aren't a big deal on N64 - you just need to separate transparencies from opaque and that's it, unlike other edge AA solutions where you have to sort everything).

Because of that, you'd think Nintendo would be more reluctant to allow devs to turn it off than anything else. From what I've seen, everything suggests that Nintendo just had an enormous z-buffer boner, to the extent that they never ever bothered to make a 3D microcode that allowed z-buffer to be turned off until the end of the console's life (and even then, they never finished the microcode, leaving interested devs to do it themselves).

The other thing is that the z-buffer on/off has a much higher performance penalty than edge AA on/off.

>>6115746
>unlike other edge AA solutions where you have to sort everything)
Ah, is that what they mean by "update the coverage value". I wasn't an N64 coder, I did 3dfx and you got overdraw problems unless you turned on what Glide called an alpha buffer. Basically storing the percentage of the pixel that was covered so that it could blend with the incoming pixel if the ztest failed. But you usually didn't turn on alpha buffering because it was a crapload of precious RAM to burn when you could use the big fat Pentium II to do the sorting.
I miss 3dfx :(

>>6115751
Yeah the N64's GPU gets around the nasty back to front sorting requirement of edge AA with two clever techniques

1) Coverage values stored in the RAM's ECC bit (internal framebuffer is 32-bit or 4 bytes, so that gives 4 ECC bits of coverage for subpixel precision)

2) Separating the anti-aliasing of inner polygon edges (which occurs in the middle of the pixel pipeline) from the anti-aliasing of outer polygon edges which occurs as a post-process during scan out while reading the completed framebuffer coverage data. That prevents the GPU pipeline both from being bogged down from trying to blend outer edges based on incomplete edge data or making blending errors.

It's pretty clever, and it's ridiculous how the PS2 implemented an edge AA solution (its only true hardware AA implementation) and they didn't implement any of these N64 sorting fixes, making edge AA on PS2 effectively worthless.

>>6115763
Actually I need to clarify, your typical N64 game with a 16-bit framebuffer and 16-bit z-buffer uses 2 bits of coverage (stored in the framebuffer ECC) and 2 bits of delta-Z (stored in the z-buffer ECC), the latter being somewhat equivalent to the 3dfx alpha buffer

>>6115779
Argh turns out the actual 16-bit (18-bit) external format is 15 bits for color + 3 bits of coverage, then 14 bits of z + 4 bits of delta-z

n64 certification checklist

for fun, n64 censorship guidelines

>>6108936
use linear only if nearest hurts your eyes or you're using a crt filter

>>6110031
>If you are using anything below 1024x1024 (1K) textures
Last time i checked 128x128 and 256x256 is the common texture sizes until the HD generation landed. Thats including some form of multi layer sampling to increase view resolution.

1024x1024? wtf

>>6108936
Think about it, weigh the pros and cons to either decision and make up your own fucking mind.

Fucking drone worker ant idiot.

>>6108936
You really just have to do it by eye.
Low-res textures often depend on having the hard-edges, but once you start increasing the texture size, you want to smooth those edges out since they're now interfering with the detail of the texture.

like, personally, I'd filter everything in >>6110017
but if I'm playing Quake 1, I wouldn't

>>6110234
>GL_NEAREST_MIPMAP_LINEAR
>they will lose their unified shit
you fucking what

>>6115851
I am guessing that is ironically enough translated from Japanese, which a lot of technical items would be.
I do also enjoy how they wanted people to use the joystick sprite, which you do see in a lot of games.

>>6116237
Maybe Doom players are so puristic that they don't even want mipmaps.
I say just use a software renderer at that point. I find the notion of imitating artifacts in OpenGL preposterous.