> The problem with 1) is it requires rendering to a P-buffer,
> which
> according to F.J McCloud has performance issues. The problem
> Maybe 1) could be implemented as an option to xmame, that way
> people
> will understand why they might get performance issues.
I'm not sure P-buffers are the only way to do it. Whatever
happened to ye olde glCopyTexSubImage2D()?
But I thought P-buffers were supposed to be faster than that.
Obviously I haven't kept up with the OpenGL scene much lately.
Problem is when your GPU's pixel shader runs out of resources
you want some way to multipass through multiple shaders without
losing (much) internal precision. This is a common use of
P-buffers, but it means allocating large regions of memory
(which, IIRC, are always power-of-2 behind the scenes) with a
large depth (64-bit or 128-bit pixels). How these buffers get
managed behind the scenes probably varies from driver to driver
and depends on the size of the VRAM, but I have never seen
people praising them for speed. At least not on large
P-buffers.
I was once approached by someone asking why his P buffer code
worked fine and reasonably fast on an Nvidia card, but had
corruption and speed issues on an ATI card. I was told simply
by someone else "P Buffers are slow". Not sure about the
corruption issue, because the other guy I knew using P buffers
never had problems, so it was probably bad code on his part
that the drivers just reacted differently to.
But for xmame? Hey....never know 'til you try! I'm just
cautioning you to try it on a variety of GPUs/drivers before
pushing it out. That would save complaints later on.
And cheer up! With effort underway to replace P-Buffers
entirely with something else (uberbuffers/superbuffers) maybe
the future is bright?
__________________________________
Do you Yahoo!?
Send holiday email and support a worthy cause. Do good.
http://celebrity.mail.yahoo.com
_______________________________________________
Xmame mailing list
[EMAIL PROTECTED]
http://toybox.twisted.org.uk/mailman/listinfo/xmame
