/vr/ - Retro Games

>>4343443
Looks terrible. Bilinear filtering was a godsend.

is n64 called that because its 64 pixels?

Btw there's an option to disable filtering by using Glide plugin.

These are always really interesting to see.

I expect lots of shitposting from people deliberately ignoring the fact that they were designed with the blinear filter in mind.

>>4343510
This looks surprisingly alright.

>>4343502
It's neat looking at the Rare screenshots in this thread and seeing just from how the games look unfiltered that they were made with filtering in mind.

>>4343506
this actually looks pretty good still

>>4343443
Looks like Minecraft :^)

What I'm really interested in seeing is what N64 games like SM64, BK, and Ocarina of Time would look like with the PS1's lack of a Z-buffer.

>>4343524
https://www.youtube.com/watch?v=TuH7RDIDZN4

>>4343502
It's because everything had to fit on a cartridge and work around the N64's tiny maximum texture size. Or at least that's what I half remember from a post from one of the guys that worked on WDC.

>>4343528
Turok had a cheat that turned off all graphical effects, filtering, animation interpolation, lighting, etc. Looked real ugly but the fps went way up. I can't find a youtube video of it.

>>4343549
It was called Quack mode, for reference.

A lot of people seem to forget that N64 games had free reign over whether to use bilinear filtering. Most games used it selectively. It wasn't like Nintendo held a gun to dev's heads and told them they had to bilinear filter textures. But Nintendo "encouraged" developers to do everything possible to make their games not look like PS1 titles. This included sacrificing 30% of your performance for coverage-based anti-aliasing.

>>4343562
Not even trolling, the only instances of nearest neighbor texturing I can think of in the N64 are for 2D elements such as the HUD, and that one instance in Paper Mario with the pixelated floor.

>>4343491
The ice there looks pretty fuckin cool.

>>4343572
Perfect Dark's background elements are often point sample filtered. HUD elements were very commonly point sampled. It was very rare because 3-point bilinear was basically free and use cases for point sample were basically "we need it to look sharp" and nothing else.

>>4343539
The cart really wasn't all that limiting when it came to textures, there's still plenty enough space for them.

The real limit was how the N64's texture buffer worked.
The N64 has 4kb of RAM to store textures in, which is 2kb more than the PS1.
However, unlike the PS1, the N64 can ONLY render textures that are in the texture buffer, so you're limited by how fast you can move textures in and out of the N64's texture buffer.

>>4343461
Kill it with fire!

>>4343583
>However, unlike the PS1, the N64 can ONLY render textures that are in the texture buffer, so you're limited by how fast you can move textures in and out of the N64's texture buffer.
There is a very interesting workaround which almost no developers made use of. Render entirely on the CPU and blit to the framebuffer. That's how the 64doom homebrew works.

https://www.youtube.com/watch?v=j2fXAZy09b0

There's absolutely no reason why, for example, developers couldn't make a 2D side scroller game rendered entirely on the CPU with no sprite size limitations. It's actually a crying shame N64 homebrew development is almost non-existent.

>>4343528
That texture warping is trippy as fuck

>>4343591
That's an interesting workaround, but kind of a waste.
The Reality Coprocessor is really the heart and soul of the N64, and was pretty state of the art at the time it was released.
The RCP would be (but still kinda is) a real beast if it wasn't limited by that 4kb texture cache.

The other ting you loose out on by rendering on the CPU is audio quality, since the N64 lacks a true soundchip. All it really has is a DAC that's driven directly by the CPU.
You can hear that in the high pitched notes from the guitar riff, which wind up a bit crunchy.
This is because the N64 can't spend as many cycles outputing audio to the DAC, effectively lowering the sample rate.

Also yeah, I wish there was more N64 homebrew.
I tried to get into it, but the only choices for SDKs are dragon-n64, which lacks support for any kind of polygonal rendering, and the official Nintendo SDK, which requires 32 bit windows XP or older.

>>4343640
>The other ting you loose out on by rendering on the CPU is audio quality, since the N64 lacks a true soundchip. All it really has is a DAC that's driven directly by the CPU.
N64 audio can be handled on the CPU or RSP. It depends entirely on how the game was programmed.

>>4343649
Right, sorry I forgot about that.

>>4343640
>>4343649
The N64 is a fascinating piece of hardware and it's really annoying that there just weren't enough god-tier programmers working with the thing. Most of the Mega Drive's top games, for example, were made by very good programmers with an intimate grasp of the hardware's quirks. That kind of thing was much rarer on the N64. I'd love to see some good N64 homebrew.

Looks like the 64doom project is still active. However, it's not pure CPU rendered anymore. I'm not entirely sure what's going on.

https://github.com/jnmartin84/64doom/commits/master

>>4343698
Turns out he's still working on it, and has made significant headway. Huge optimizations. https://www.doomworld.com/forum/topic/69538-64doom-classic-doom-on-n64/?page=4

You want to know what's insane? If he gets 64doom stable, it'll literally be the best performing pre-Xbox 360 console version of the 2.5D Doom games.

>>4343776
Wasn't Doom 64 way more demanding than Doom II? It's had a pretty complex lighting system, bigger weapon/monster sprites, skies with several animated layers, etc.

>1024x768
But that's not the resolution of N64 games. Or /vr/ games in general.

>>4343478
It would look better if the texture size wasn't all over the place. These games were made with filtering in mind, if you had more space and made games with this in mind, they'd actually look pretty good.

>>4343698
>>4343776
How’s he compiling it?
I’d love to get into N64 homebrew, but I haven’t been able to get a working assembler running.

>>4343786
No known N64 emulator supports N64's native internal resolution, so anything goes, I guess.

N64 LLE emulation fucking when.

Some games look pretty good without the filtering though, Rareware games especially because they mastered the hardware and knew how to push it hard.

>>4343443
N64's had good 3D hardware that could do extreme distances, that's why it needed bilinear filtering, because they stretch the living shit out of those textures.

>>4343583
>so you're limited by how fast you can move textures in and out of the N64's texture buffer.

And fillrate, because apparently polycount is for pussies. Lots of PS1 games made extensive use of the texture cache, but textures looked nicer because they were spread across more polys, which also mitigated distorsion.

>>4343784
Doom 64 was a completely different kettle of fish. Very different engine that runs at a locked 30fps on the N64, but it's fully 3D rendered and has all the advantages and limitations of N64 3D rendering. If you render on the CPU, you don't have to worry about the 4KB texture cache limitation.

Doom is designed to run at 35fps. It's one of the shittier traits of the engine.

Imagine being an artist trying to make something that has to go through a filter. What sort of tools did they have that allowed them to see how the N64 filtered everything and then what it would look like on CRTs. Making anything sounds like a nightmare.

>>4343786
NO SHIT SHERLOCK

>>4343792
All we can do is pray that someway, somehow, the N64 documents get leaked and the emulation community work overtime on that shit. Look at the wonders it did for PSP.

>>4343791
Some custom job that only works in Linux. Basically nobody except him seems to be able to successfully compile the raw source.

>>4343798
What he means is that talking about textures at the incorrect resolution is kind of pointless.

>>4343790
>killed every piece of greenery literally just because of Yoshi's existence

>>4343791
You need a MIPS assembler right?

>>4343792
>No known N64 emulator supports N64's native internal resolution
GLideN64 does. Angrylion's does.

>All we can do is pray that someway, somehow, the N64 documents get leaked and the emulation community work overtime on that shit.
We've had the N64's hardware documentation for decades. I have it sitting on my hard drive.

>>4343806
Well shit.
I can handle Linux, but if no one else has had any luck I’m not that hopeful.

>>4343786
>1024x768
>not the resolution of /vr/ games
What did he mean by this

>>4343794
>because they stretch the living shit out of those textures.
No, they didn't. Have you people never heard of tiling?

>>4343823
Did you not see the first few posts of this thread?

>>4343821
What /vr/ game/console has HD resolutions natively?

>>4343812
Nah, I think they just chose to make the palette more pastel and easy on the eyes. The original is a bit acidic.

>>4343825
>Did you not see the first few posts of this thread?
The ones with literally no textures "stretched" over terrain?

>>4343815
Yeah, and one that has support for the N64’s unique instructions.

I tried to get the official Nintendo one working, but it won’t work on 64 but windows.
I tried running it in a VM to limited success.

The N64's problem was that RAM access was brutally slow. This is the single biggest design flaw, and it doesn't get talked about enough. It's the reason so many N64 games struggle to run at a stable 30fps, much less a stable 60fps.

>>4343826
I don't get it. Did your /vr/ games not have 1024x768? This game was from 1998, and I'm definitely sure Need For Speed III had it too.

>>4343830
>>4343461
you blind son

>>4343825
N64 developers tended to use low resolution textures for certain visual effects. Like, if you want a glass window, you want a very low resolution texture applied to it with bilinear filtering so it looks like a glossy specular reflection. I think a lot of people misunderstand the artistic intent of N64 graphics designers.

>>4343846
The N64 blended multiple texture layers together. It's supposed to look like a smooth circle.

Flash memory was expensive as fuck back in that time period, as the result most N64 games were only 8 or 16 MB in size. Compare this to say Duke Nukem 3D's PC version which takes 40+ MB. So, you can't really have nice, consistent size textures with this little space.

Yeah, much later in the console's life cycle ROM sizes got way bigger, all the way up to 64 MB, but this was still more of an exception to the rule.

They really shouldn't have pissed Sony off. The originally proposed Nintendo Playstation could've been amazing.

>>4343846
Take this for example >>4343565 the blood decals in Perfect Dark are created so they'll look like blood splatter when bilinear filtered.

>>4343840
They're hipsters. They don't know shit about old games, they've only heard that the games are supposed to be all lowres and pixelated.

1024x768 is a standard VESA resolution. All Build games supported it. And pretty much all later 3D games starting with Quake.

>>4343851
The issue was never texture storage space. The N64 was capable of all sorts of crafty fuckery including using JPEG compression for textures. The issue was that all textures had to fit in a 4KB texture cache. This limited individual texture size to 64x64 or 128x32 or whatever. Rendering in software was a workaround almost nobody used.

>>4343840
Now that you mention, yeah I played NFSIII, but I didn't know it had 1024. I didn't get a 1024 monitor until like 2000 anyway.
Didn't know that Sierra racer, any good?

>>4343857
>>4343840
Well, 1998 is pretty close to the limit.
>>4343786 said "/vr/ games in general", meaning there can be exceptions.
Most /vr/ games are 240p or similar.

>>4343858
>The issue was never texture storage space.

Please tell me how you can fit any at all good textures in 8 MB, which was Super Mario 64's ROM size, including music, sounds, level data, etc. Even the original DOS Doom was 12+ MB.

>>4343836
Technically the RAM was blazing fast, it just suffered from pretty bad latency, so the system would sit around twiddling it’s thumbs waiting for the RAM to respond, but once it started it was pretty damn fast.

>>4343863
JPEG compression. You'd have to store the textures as JPEG, decompress them to RAM as YUV, convert them to RGB, and then use them as normal textures. Also, most N64 titles used some kind of compression. http://en64.shoutwiki.com/wiki/N64_Compression

>>4343871
Aren't compressed images like JPEG rather CPU intensive?

I know some games like Conker used MP3 for voice clips which sounds pretty impressive since MP3 was known to be a CPU hog on older hardware.

>>4343876
>Aren't compressed images like JPEG rather CPU intensive?
Decompress them during loadscreens or something. The N64 had a Nintendo-provided ucode for JPEG decompression on the RSP. Battle Ogre 64 and Resident Evil 2 use JPEG.

>>4343860
It had full damage simulation including a hop button you can fuck with which can take you to the skies if you hold it down and then abuse your poor Viper until it crumpled into a little tissue ball, literally. It also had a Trackmania style skin editor where you stamp shit all over using your mouse.

>>4343863
The fact many 3rd parties couldn't afford 32MB cartridges was a factor, but devs always hit the brick wall that was the 4KB texture cache long before they hit the cartridge size limit.

So they look like PS1 games except with perspective-correct texture mapping.

>>4343896
PS1 games look nicer tho.

>>4343927
No, they really don't. PS1 games are fucking atrocious to look at, particularly in motion. The jittering 3D, warping textures, and so on.

>>4343936
Those things are forgiveable when the average game on the N64 without filtering looks like this

>>4343443
>>4343449
>>4343493
>>4343538
>>4343546
>>4343461

Now take any Crash game, MGS1 or Tomb Raider. They look phenomenal in comparison even without filtering, so imagine when people found out the PS2 could get the N64 treatment to any PS1 game. Some of them, were not for resolution or model quality, could legitimately pass off as lower tier 6th gen games.

>>4344027
>MGS1 or Tomb Raider. They look phenomenal in comparison even without filtering
Those games have horrifically bad graphics compared to a typical N64 title. MGS in particular.

>>4344042
>MGS in particular.

Texture definition in MGS was out of this world, game looks stunning at higher res. But you're probably going to post the model faces, even though it was intentionally done to avoid uncanny valley stuff (with the added benefit of saving memory).

>>4343528
>DUDE SHROOMS

>>4343485
heh

wow I don't remember the n64 looking this shitty
must be nostalgia and the mandela affect

>>4343443
>>4343449
>>4343461
>>4343485
>>4343491
>>4343493

it looks like ps1 graphics. That's what sonyfags prefer over "hurr durr blurry n64 grafix"

>>4344048
A lot of Metal Gear Solid's textures are really not that high resolution. They're like Vagrant Story in that they're very square. This is very tricky asthetic problem. N64 developers textured completely differently to PS1 developers. I don't think the PS1 could even DO texture blending.

The N64's bilinear filtering was absolutely essential. You couldn't render smooth skies and water and vegetation and transparencies without it. PS1 games that tried to replicate these effects looked terrible. Shadow Man PS1 looks and runs horrifically.

Another bizarrely misunderstood aspect of N64/PS1 graphics is fog. The PS1 and N64 both had pretty short draw distances. The difference is the N64 was capable of rendering very nice distance fog for free. PS1 fog had to use custom solutions, and so devs generally just had distance culling, which frankly looks like shit.

>>4343443
Some Majora's Mask anyone?

>>4344027
>MGS
>looks phenomenal
It looks phenomenally wobbly.

>>4343521
holy shit, is that bleak and boring. they took literally everything that made the scene memorable and stripped it off.

>>4344590
what do you mean

>>4343443
looks like a PS1 game

>>4344548

Wobbly or not your picture is a perfect example of why people think it looks good in the first place, the shading and proportions are phenomenal. They worked with the limitations of the console and standard 1998 CRTs in mind to create a quirky but realistic aesthetic. Besides, there IS a PC version if the wobble annoys you that much.

>>4343518
To be fair, it does look like Conker's standing on BRRRROWN BRRRRICKS

>>4344264
>you couldn't render smooth skies without it

Not without some creative thinking.

>>4343851
>Flash memory
Do millennials think all non-volatile memory is flash memory nowadays?

>>4344690
I'm just kidding bro, I like both N64 and PS.
Both look good on CRT.

>>4345086

Probably, I'm not entirely clear on the differences myself, except that there is one. I get that there's ROM, EPROM, and EEPROM, etc. but haven't been able to wrap my head around the rest.

>>4343443

Thank you for making this thread. Lotta great content here.

>>4344709
Gouraud shaded clouds? That's interesting actually.

>>4345165
vertex painted

>>4344257
>A lot of Metal Gear Solid's textures are really not that high resolution.

They actually are, most of if not all of them are comparable with the sequel which is darn impressive, and the texturing work is also well done in giving the stages a highly detailed look (fueled by the absence of LOD). TTS looks so bland in comparison, and not just because of the dull lighting. I don't know what you mean by square, stages are mostly built with quads (as far as the assets are concerned) but the textures come in all forms and shapes.

>I don't think the PS1 could even DO texture blending

I don't see why not, the GPU does have a semi transparent texture opcode but it wouldn't be a very computationally cheap thing to do since you're rendering the same (large, compared to the average N64 game) texture multiple times at a close distance.

>>4343517
You look pretty good still.

>>4343517
It doesn't look too bad (especially the bridge and the stepping stone) but it's stil subpar, as a whole.

>>4343662
This actually looks neat

>>4344249
No, it doesn't.
PS1 has much higher res textures, because it can afford extra space on a 700 meg CD-ROM, when biggest possible N64 cart had 64MB.
Pic related, look at how much more detailed those textures (without ANY filtering) are compared to:
>>4343443
>>4343461
>>4343493

>>4346324

>>4346324

they would all look better with N64 flitering.

also, those pictures are not from real hardware, they are from emulators that use a lot of ttechniques avaliable on the N64. On real hardware and in motion ps1 games look terrible.

Looks fine when not paused(who plays a game paused?) and on a CRT.

What's the point here?

>>4346614
They MAYBE would look better with filtering, but they COULDN'T because N64 carts can't fit all these textures. That's my entire points, N64 NEEDED the filtering because carts couldn't fit decent resolution textures. Superior hardware but terrible and expensive memory storage, that's N64 in a nutshell

Also both Klonoa and Megaman Legends rely on cartoony and crisp textures so I'm not sure if it'd really look that much better.
>>4346393
Wow, you cherrypicked ONE screencap that's super zoomed out. I can do that too, pic related!
Or here:
https://i.ytimg.com/vi/-Ua0VclnUvw/maxresdefault.jpg
^^ look at how RIDICULOUSLY low-res wall texture has become on N64, I think it's 8x8 repeating pattern!
Or here:
https://gamefaqs.akamaized.net/screens/2/1/d/gfs_51741_2_2.jpg
everything looks like a blurry vomit blob.
>>4346614
>that use a lot of techniques avaliable on the N64.
That's a plain lie. These pics don't use filtering like N64 does, and I'm pretty sure middle pic (Klonoa) is from real hardware. Point of my comparison was to show SUPERIOR TEXTURE RESOLUTION of PSX, which is undeniable. Yes, N64 had superior graphics hardware but it didn't have memory to use it properly.

>>4346860
>hat's my entire points, N64 NEEDED the filtering because carts couldn't fit decent resolution textures.
That is untrue. It ate draw calls, but you could make texture tile mosaics as large as you wanted and textures didn't use THAT much memory.

>>4346860
>https://i.ytimg.com/vi/-Ua0VclnUvw/maxresdefault.jpg
>^^ look at how RIDICULOUSLY low-res wall texture has become on N64, I think it's 8x8 repeating pattern!
That's literally a different texture.
>Or here:
>https://gamefaqs.akamaized.net/screens/2/1/d/gfs_51741_2_2.jpg
Looks fine to me.
>Also both Klonoa and Megaman Legends rely on cartoony and crisp textures so I'm not sure if it'd really look that much better.
Their "crisp" textures are blatantly pixellated. Some people like that, but it's frankly a technical limitation dressed up as art design. We saw something similar with the System Shock remake where you had purists demanding the developers use shitty non-filtered textures because the original version did.

God, the N64 is disgusting.

>>4343640
How many official SDKs do we have for consoles?

>>4346912

Not enough.

>>4346908
I think you misspelled "incredible".

>>4346860
>cherrypicked
Not him, but I think the N64 version looks better than the wobbly, jiggly pixelated mess ps version.
PC version is the best anyway
You smell like a huge PS fanboy.

>>4346393
where are Mega Man's legs on the PS version?

>>4346984
checkmate playstationfags

>>4346984
Hidden by the console's lack of a z-buffer. In all seriousness, though, why does Mega Man 64 cop so much flack? It uses a shitty audio codec, sure. It has some framerate issues, sure. But it's a really good game, and texture quality seems to be 1:1 mostly. There are some textures which are oddly different, but there's no clear drop in asset quality across the game. It just has nice filtering and doesn't jiggle and warp like crazy.

Megaman 64 may have slightly better handling of the 3D models than its legends counterpart, but are you really going to justify it with 64's cut content (removed audio tracks) and awful sound quality (I cannot understand what the fuck anyone is saying in that first flutter escale cutscene because of the loud, crunchy engine audio)

>>4347132
>and awful sound quality (I cannot understand what the fuck anyone is saying in that first flutter escale cutscene because of the loud, crunchy engine audio)
The sound quality is an extremely mixed bag. Some is fine, some is overly muffled. The problem is made worse by the original game having muffled voice acting.
>cut content (removed audio tracks)
You mean those CD samples that are basically a glorified sound test?

>>4347150
That and part of the Kattelox TV minigames had the length of their tracks reduced to a short loop. The music in 64 also plays at a lower tempo, for some reason.