[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]

2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games

File: 2.70 MB, 640x480, FB_Effect.webm [View same] [iqdb] [saucenao] [google]

5038285

Anonymous Tue Sep 11 22:04:18 2018 No.5038285 [Reply] [Original]

Going back it's interesting noticing how many N64 games use sophisticated framebuffer effects that were basically nonexistent on PC. The pause menu in Perfect Dark, Conker, and DK64 copies the main buffer to a texture, applies a pseduo-DOF effect and then in PD's case places the little eyepiece in front of it to simulate the human eye focusing on it. Similarly, the Camspy is a super complicated auxiliary framebuffer effect that takes multiple buffers and distorts them in layers to create scanlines and a fisheye effect. In Conker, they used a super fiddly framebuffer effect to handle Bullet Time with the camera spinning around Conker and Berri.

You just didn't see this stuff on PC until several years later. Presumably because manipulating the framebuffer on PC was far more expensive since PC lacked the N64's unified memory architecture where you could copy the buffer up to 60 times a second, apply effects, and then copy it back.

You go back and play PC games from the 90s and early 2000s and they never did stuff like this. Even the PS1 had some framebuffer manipulation capabilities that typically went missing from PC versions. (For instance, Metal Gear Solid for PC is missing every single framebuffer blurring effect.)

>>	Anonymous Tue Sep 11 22:07:53 2018 No.5038287 Panty dropping talk right here bois

>>	Anonymous Tue Sep 11 22:34:48 2018 No.5038317 >>5038287 This, I wonder what retro hentai games OP plays.

>>	Anonymous Tue Sep 11 22:45:35 2018 No.5038334 File: 2 KB, 26x33, 1534414931996.gif [View same] [iqdb] [saucenao] [google] >>5038317 OP likes accumulation buffers, so prolly bukakke

>>	Anonymous Tue Sep 11 22:48:27 2018 No.5038340 >>5038285 I remember Ape Escape applying a software implementation of bilinear filtering on the game's framebuffer at the pause screen. Pretty cool effect although it wasn't immediate, it gradually changed from top to bottom.

>>

Anonymous Tue Sep 11 23:14:38 2018 No.5038384
File: 183 KB, 640x480, perfect_dark-075.png [View same] [iqdb] [saucenao] [google]

>>5038334
Accumulation buffers are responsible for some of the shittiest motion blur implementations of all time. This, on the other hand, is a pretty damn good use of auxiliary framebuffers.

>>	Anonymous Tue Sep 11 23:15:49 2018 No.5038386 You make an interesting point OP, however- >DURRRR FOG >HURRRR FRAMERATE >UHHHHHH ONLY LIKE 5 GOOD GAMES

>>	Anonymous Tue Sep 11 23:42:21 2018 No.5038436 >>5038285 oh,.. I see why I thought the N64 was a really amazing consoles in graphics even compared to PCs at the time. Really, it was the best in graphics. It could've done so much more if it had CD.

>>

Anonymous Wed Sep 12 00:04:08 2018 No.5038457

>It could've done so much more if it had CD.
Nah. Nintendo being Nintendo would have cheaped out on the cd assembly and you would have been waiting for loadtimes on nearly everything. I don't think smash bros. would be quite as fun when you would have had to wait 15+ seconds for a stage to load everytime. It's partly the reason things like Counter-Strike and WoW were so popular in their day because there was little amount of time between booting the game, jumping through hoops and to actually be playing the game. This is also a contributing reason as to why fortnite is so popular as well.

>>	Anonymous Wed Sep 12 00:51:20 2018 No.5038505 >>5038386 t. Nintencuck after exhausting every last drop of second from its 5 N64 games

>>

Anonymous Wed Sep 12 02:22:39 2018 No.5038581

>>5038285
It was hard to do framebuffer effects on 3D accelerators due to having a variable amount of VRAM, and together with the user's ability to change the resolution to pretty much anything that was supported.

Not to mention those older 3D accelerators tended to have a VRAM exclusively divided between framebuffer and texture space. Newer cards just did the equivalent of framebuffer effects through pixel shading, but that wasn't possible until ~2001.

N64 was particularly well-positioned for framebuffer effects due to, as you say, the unified memory architecture, so even the CPU could directly change the values in VRAM. Also the fact that N64 had disproportionately powerful T&L hardware for its time would have also helped in transforming those ancillary buffers in interesting ways.

>>	Anonymous Wed Sep 12 10:11:38 2018 No.5039029 >>5038285 Yeah, the N64 rocked!

>>	Anonymous Wed Sep 12 10:17:40 2018 No.5039032 >>5038285 Too bad it didn't make the games not look like ass.

>>	Anonymous Wed Sep 12 10:22:12 2018 No.5039040 >>5038334 Whaaa where is that roper gif from?

>>	Anonymous Wed Sep 12 18:41:56 2018 No.5039970 >>5038285 Well it had the most powerful graphics hardware available on release so it should be no surprise really.

>>

Anonymous Thu Sep 13 05:16:07 2018 No.5040802

>>5038285
It's because Nintendo worked with Silicon Graphics (SGI) for N64. SGI at the time, from 1990-1997 was the leader of interactive 3d graphics and Nvidia was made from engineers who left SGI when it was sinking down. Silicon Graphics died because they didn't change with the market. They used to sell awesome proprietary 3d workstations which cost a lot of money but in few years of time commodity PC took over and of course, Nvidia helped to do that. SGI's own engineers betrayed them.
Well this is why N64 was quite advanced in some terms.

>>	Anonymous Thu Sep 13 05:17:14 2018 No.5040803 Nintendo apologists go to absurd lengths, amusing.

>>

Anonymous Thu Sep 13 14:00:10 2018 No.5041346

>>5038285
OP, you severely lack context.

On consoles, 1993: built-in music visualizer in 3DO: https://www.youtube.com/watch?v=O6myKQhf7VM
1 MB of video memory allows you to have a lot of 320×240×2 buffers, and easily add feedback effects.

On PC, the same year: Cthugha. It even has a page in Wikipedia: https://en.wikipedia.org/wiki/Cthugha_(software)

(As a coincidence, both are hard to run now, as 3DO emulators lack audio CD implementation, and Cthugha gets data from CD/Mic input on sound card.)

We also assume here that Amiga didn't exist.

Later software rendered 3D was thoroughly spiced with effects:
https://www.pouet.net/prod.php?which=5
https://www.pouet.net/prod.php?which=26
https://www.pouet.net/prod.php?which=87
https://www.pouet.net/prod.php?which=3
https://www.pouet.net/prod.php?which=44
https://www.pouet.net/prod.php?which=74

Even fully hardware accelerated “kasparov” and “.the .product” had some frame blending effects.

So what you are implying is that first generations of PC 3D accelerators were conceptually unsuited to transfer rendered image anywhere except the hardware overlay processor (later, the combined output buffer), and often didn't even physically share any memory with the host graphical system, being a totally independent hardware device. This is true. Additional software-processed transparent textures were the best you could do. As standards progressed, fast two-way transfer became an option, and, from 2002-2003, haujobb and mfx started to show 3D graphics that didn't look like 3D graphics. Shaders wouldn't appear for a couple of years, actually.