Technical question about Framebuffers...

[jdsony]

I have a question for anyone that can answer. I'm curious about why the N64 uses a framebuffer. Does it allow for effects to not have as much of a performance impact? It's just something that would be nice to know and I really know nothing about other than some games use them some games don't and 1 game maybe doesn't use them but can pull off an effect that another game needs it for.

 

[Reznor007]

By using the framebuffer you can do effects like motion blur easily. It also allows for render to texture effects, such as the Mario Kart display screens and Banjo Kazooie puzzle screens.

PC video cards can do this as well, but getting it to work in emulation is tricky.

 

[gamefreaks]

As Reznor007 rightly points out, the framebuffer is used for effects. Basicly, it allows you to take use the last frame's contents when drawing the current one. Eg: Drawing the current frame alpha-blended over the previous frame will give you motion blur over many frames.

The problem with frambuffer emulation on the PC is that the framebuffer is stored in Vram (on the video card) and to do framebuffer effects, the framebuffer must be copied back to system ram, which is REALLY slow.

 

[Reznor007]

Actually that is no longer the case. As of DX6/7(?) you can render to a texture and use that in the same way N64 does.

Download this http://www.scene.org/file.php?file=/demos/groups/elitegroup/e_kasp22.zip&fileinfo

It is a nice demo showing off motion blur in real time on PC's. A TNT or better should run it just fine.

 

[jdsony]

Actually that is no longer the case. As of DX6/7(?) you can render to a texture and use that in the same way N64 does.

Download this http://www.scene.org/file.php?file=/demos/groups/elitegroup/e_kasp22.zip&fileinfo

It is a nice demo showing off motion blur in real time on PC's. A TNT or better should run it just fine.

Interesting...I have noticed for the longest while effects like Motion blur and other interesting video effects have been used widely in consoles but not in PC. I remember playing Metroid Prime last year and noticing the textures could be out done on PC but the effects were things I hadn't seen before. Now PC games are starting to do things like that finally (of course they are console games too) Prince of Persia Sands of Time uses a nice motion blur and a hazy effect that makes it seem all dream like, and Legacy of Kain Defiance uses a crazy hazy effect as well. GTA 3 had a motion blur as well but it wasn't that great and it was a bit of a performance hog. Even Mirrors are a rare occasion in PC games.

I suppose most of this has to do with the compatibility issue...they are still making PC games with older hardware standards in mind even though the games will never run well on the old hardware to begin with at a decent speed but it will run.

 

[Tagrineth]

Actually that is no longer the case. As of DX6/7(?) you can render to a texture and use that in the same way N64 does.

Download this http://www.scene.org/file.php?file=/demos/groups/elitegroup/e_kasp22.zip&fileinfo

It is a nice demo showing off motion blur in real time on PC's. A TNT or better should run it just fine.

It isn't "in the same way". Render to texture is NOT the only use for "framebuffer effects" on a game console.

 

[Orkin]

The difference between the render-to-texture and framebuffer effects on the N64 and on a PC is that on the N64 the RDP (the N64's GPU) and CPU share the same RAM, so the CPU has full access to whatever the RDP is doing, plus the RDP can be told to use any address for the framebuffer. This allows a game to tell the RDP to render a scene, then the CPU can take that, modify it however it wants, and use it as a texture, blend it with a previous frame, change the color, blur it, the possibilities are endless because the CPU has full access to it.

On the PC, the CPU and GPU have completely seperate areas of RAM. Render-to-texture works by instructing the GPU to render to an area of VRAM other than the frame-buffer, and then use that as a texture in future rendering. The CPU has no part it in. Special effects, such as motion blur, can be acheived through advanced blending, and vertex and pixels shaders, but it is still limited by the capibilities of the GPU.

The problem with emulating framebuffer effects comes when the game's code wants to modify the contents of it...we can't emulate the game code on a GPU, so the CPU has to do it, but the framebuffer isn't directly accessible by the CPU as it is on the N64. This means we have to copy it from VRAM to RAM, let the game code modify it, and then copy it back, an extremely slow process.

glN64 partially works around this problem by trying to keep everything on the GPU, but this only works for render-to-texture effects, and doesn't allow for any modifications to the framebuffer's contents.

The next version of 1964 tries to remedy this problem by notifying the video plugin when the CPU is trying to access the framebuffer, so the plugin can copy the framebuffer to and from system RAM only when needed, this helps out alot, but isn't perfect.

I hope that sorta sums up the situation, it kinda got a little long-winded...

 

[gamefreaks]

A thought has crossed me!

Where does this leave us with cards that use SMA? (The graphics card takes a chunk of system ram)
Normally these are built into the motherboard and should be avoided like the plauge for gaming but a gf4 MX could handle N64 poly counts.

Is it still as slow to copy from the SMA framebuffer?

 

[jdsony]

A thought has crossed me!

Where does this leave us with cards that use SMA? (The graphics card takes a chunk of system ram)
Normally these are built into the motherboard and should be avoided like the plauge for gaming but a gf4 MX could handle N64 poly counts.

Is it still as slow to copy from the SMA framebuffer?

I would guess it is probably the same as having the ram on the video card because the system reserves the system RAM for the onboard video and doesn't allow the CPU to access it anyway.

 

[Reznor007]

The difference between the render-to-texture and framebuffer effects on the N64 and on a PC is that on the N64 the RDP (the N64's GPU) and CPU share the same RAM, so the CPU has full access to whatever the RDP is doing, plus the RDP can be told to use any address for the framebuffer. This allows a game to tell the RDP to render a scene, then the CPU can take that, modify it however it wants, and use it as a texture, blend it with a previous frame, change the color, blur it, the possibilities are endless because the CPU has full access to it.

On the PC, the CPU and GPU have completely seperate areas of RAM. Render-to-texture works by instructing the GPU to render to an area of VRAM other than the frame-buffer, and then use that as a texture in future rendering. The CPU has no part it in. Special effects, such as motion blur, can be acheived through advanced blending, and vertex and pixels shaders, but it is still limited by the capibilities of the GPU.

The problem with emulating framebuffer effects comes when the game's code wants to modify the contents of it...we can't emulate the game code on a GPU, so the CPU has to do it, but the framebuffer isn't directly accessible by the CPU as it is on the N64. This means we have to copy it from VRAM to RAM, let the game code modify it, and then copy it back, an extremely slow process.

glN64 partially works around this problem by trying to keep everything on the GPU, but this only works for render-to-texture effects, and doesn't allow for any modifications to the framebuffer's contents.

The next version of 1964 tries to remedy this problem by notifying the video plugin when the CPU is trying to access the framebuffer, so the plugin can copy the framebuffer to and from system RAM only when needed, this helps out alot, but isn't perfect.

I hope that sorta sums up the situation, it kinda got a little long-winded...

Have you heard about BrookGPU? It's a shader based API for using the GPU shader engine to run general purpose code. A MPEG2 encoder has already been done, amongst other things. If the emulator can recompile the code to the format BrookGPU uses, could you use that to do the N64 CPU effects entirely on the GPU without worrying about transferring back to the CPU?

 

[Reznor007]

It isn't "in the same way". Render to texture is NOT the only use for "framebuffer effects" on a game console.

I know, but most of the effects are motion blur and render to texture. Perfect Dark and Conker are probably the 2 worst offenders of using the CPU. Orkin, do you know of many other games that really abuse the architecture, or are most just general motion blur?

 

[Tagrineth]

Have you heard about BrookGPU? It's a shader based API for using the GPU shader engine to run general purpose code. A MPEG2 encoder has already been done, amongst other things. If the emulator can recompile the code to the format BrookGPU uses, could you use that to do the N64 CPU effects entirely on the GPU without worrying about transferring back to the CPU?

Frogger has also been done entirely in a DX9 2.0 shader. :flowers: