What's new

Frame buffer emulation

pj64er

PJ64 Lubba
mario kart actually has a small problem due to slow (poor?) framebuffer emulation in jabos. Most people who doesnt own Mario Kart dont notice it anyway. Many games have a much worse problem.

Pokemon Snap - cant save pictures, same problem in Zelda MM (proper frame buffer emu does fix this right?)
Jet Force Gemini - first boss, the big bee thing, needs frame buffer emulation to play.
Perfect Dark - some effects use Frame Buffer. One good example is the motion blurring when you get slapped. Instead, right now it just gets darker (I assume its just putting black textures on top of the screen over and over again?)
CBFD - rocket launcher aimer in multiplayer is said to use this. what good is multiplayer w/o accurate rocket launcher right ;)

these are some of the more serious ones that i can list from the top of my head. im pretty sure there are more.
 

EddyB43

British Old Gamer
This might be a newbie question, but since icepir8 said most (if not all) of the frame buffer speeds were caused by the OGL plugin and not the emulator core, why did the Banjo Kazooie image on TR64's WIP only get 3.19 D/Ls per sec vs. 1964 getting 41.2 VI/s. Only differences I can see is that the 1964 image is further along, perhaps it's easier to process later on, and that 1964 is running a CF of 2, whereas TR64 was doing a CF of 1.

I hope I've not made a silly mistake of assuming Vertical Interrupts are the same as DLists.
 

Reznor007

New member
Smiff said:



erm Reznor it's still a hardware copy video to system however you do it isn't it. you've got to get the image back into the scene.

What I was talking about is if the specific framebuffer texture is created via software on the CPU, or a hardware rendered texture. Of course doing it via software is slow. Also, if you render the texture via hardware, read it back into main system RAM, then use it as a texture it is slow. However, if you do a render-to-texture effect, it can be near full speed. Using that, the hardware renders a frame into it's on video RAM(not system RAM), then uses it as a normal texture. As mentioned before, the Kasparov 3d demo is a good example of this effect at good speed on PC hardware.
 

Doomulation

?????????????????????????
Actually...the framebuffer has nothing to do with the core.
The reason it may be running slower on some emus is that those emus cores are slower. Get it?

The real problem with the framebuffer is, to read from the gfx card and into the main system ram. This is where the speed is lost.

Then it's a matter of rendering the texture, but i assume that it's almost rendered as everything else.
 

pj64er

PJ64 Lubba
would icepir8 please explain (in layman's terms) to us what he did to achieve such speed? Everyone is confused
 

sk8bloke22

roll for life
i think he already has to dave2001. im guessing u'll find quicker frame buffer emulation in various of the new emus.
 

Doomulation

?????????????????????????
pj64er said:
would icepir8 please explain (in layman's terms) to us what he did to achieve such speed? Everyone is confused
I think he might have used some hacks that dave used. Or, well, not.
When reading the data from the card, it must be swapped somehow i think (i remember jabo saying somerhing like this). OpenGL has support for this, making it faster.

And also, he could drop some quality to gain more speed.
By lowering the resolution of the picture. That, I can tell, will speed up, and were discussed with Dave, and is which how he could obtain such high speed.
 

linker

Emutalk Member
Dave's framebuffer emulation is still slow. He's trying to find some solution, but the disadvantages in glide make that harder.
 

pj64er

PJ64 Lubba
yes Dave2001 already knows, he put some screenies of Glide64 with it enabled. But we dont know! Im betting on Reznor's method.

Doom, as youve said before, the slowdown is due to
The real problem with the framebuffer is, to read from the gfx card and into the main system ram. This is where the speed is lost.
if this is so, dropping the quality of the picture could not increase the speed by a lot.
 

linker

Emutalk Member
Actually, yes, dave used a hack - decreasing the quality to gain some more speed, but that seems to be not enough.
 

Doomulation

?????????????????????????
pj64er said:
yes Dave2001 already knows, he put some screenies of Glide64 with it enabled. But we dont know! Im betting on Reznor's method.

Doom, as youve said before, the slowdown is due to if this is so, dropping the quality of the picture could not increase the speed by a lot.
Actually, the plugin does not read all the data from the gfx card, which results in a lower resolution and therefore faster.
 
OP
icepir8

icepir8

Moderator
Glide vs. OpenGL
Dave and I handle the frame buffer emulation differrently. I explained my method to Dave and he is going to try to impliment it.
We also handle the swaping of the video card buffers differently. This is why some games flash the screen in Dave's plugin but not in mine. For example Shadow of the Empire flashes in Glide64 but not in New TR64 ogl ver 0.5H.

Also Glide does not have support for reading from the cards video memory.

1964 vs. TR64
Also comparing DL/s to VI/s is comparing apples to oranges. The two are measureing differrent timing issues. VI/s measures the emu core speed in releation to video interupts this gives an accurate messurment of emulation speed. DL/s meassures how many Display List sent to the plugin per second. You get Video Interupts even when there are not any Display List being generated.
 

Dave2001

Moderator
Glide doesn't give very much control over memory :( so there is not much I can do to increase speed but decrease the number of reads.

Also, I can't do other things like copy one buffer to the other, as I am FORCED to swap. (well, technically you can copy, but you can follow the current position as it makes it's way down the image b/c of the slowness :plain: )

btw, is your backbuffer somehow in system memory instead of video memory? That would explain the speed...
 
Last edited:

Doomulation

?????????????????????????
Dave2001 said:
Glide doesn't give very much control over memory :( so there is not much I can do to increase speed but decrease the number of reads.

Also, I can't do other things like copy one buffer to the other, as I am FORCED to swap. (well, technically you can copy, but you can follow the current position as it makes it's way down the image b/c of the slowness :plain: )

btw, is your backbuffer somehow in system memory instead of video memory? That would explain the speed...
Dave,
OpenGL has more control over memory than Glide has. That explains the speed i think.
 

Dave2001

Moderator
Umm.. but even so it still has to read it... Reading from video card's buffers is slow no matter what API you're using.
 

Doomulation

?????????????????????????
Dave2001 said:
Umm.. but even so it still has to read it... Reading from video card's buffers is slow no matter what API you're using.
I think it was something about the data has to be swapped when reading from the gfx buffer, which results in even more low performance.

OpenGL has support to read this data without swapping it i think. It's something like that jabo told me sometime before.
 

Top