Oops, here is an updated diff: http://users.ox.ac.uk/~newc2303/gpupatch2.txt
On Wed, 15 Dec 2004 09:07:52 -0800, Christopher Stone <[EMAIL PROTECTED]> wrote: > This is a bad patch, it is full of indenting changes. It is much > better to sumbit whitespace changes as a separate patch. > > > On Wed, 15 Dec 2004 15:01:47 +0000, Matthew Earl <[EMAIL PROTECTED]> wrote: > > Ok, heres what I've got so far: > > > > http://users.ox.ac.uk/~newc2303/gpupatch.txt > > > > Details: > > - All effects implemented except for 6tap+scanline, lq and hq > > - Behaves exactly like the x11 software driver when in windowed mode > > - With no resize effect selected, behaves exactly like the old gl driver > > - Area drawn is exactly equal to the unscaled game size muliplied by > > the scaling factors > > - In fullscreen mode screen resolution is switched to make the game > > fill as much of the screen as possible without cutting anything off. > > > > Todo: > > - Fragment programs have to be in the current directory. This isn't > > suitable, but where would be a suitable place? > > - Should already behave sensibly on hardware that doesn't support > > fragment programs, but this needs testing. > > > > As far as the implementation of the HQ/LQ algorithms are concerned, I > > am worried it may not be possible to implement efficiently in a > > fragment program. The overview of the algorithm on Maxim Stepin's site > > ( http://www.hiend3d.com/hq3x.html ) describes a table with 256 > > entries being used to look up coefficients. This in itself should be > > implementable by using a lookup texture. However, looking at the C > > implementation of the algorithm, it seems a lookup table is not used > > at all; a large switch statement is used instead. This would be > > isomorphic to a lookup table were there not further if statements > > inside the switch block. Incorporating these conditions into a lookup > > texture would make for a rather large texture. > > > > I think that the inherent differences between the GPU and the CPU mean > > that efficient algorithms for one are not necessarily efficient for > > the other. I think it is just fortunate that the scale2x algorithm > > could be implemented reasonably compactly as a fragment program. I > > will look at the HQ algorithm again but it might be that the algorithm > > will have to be changed slightly for it to be usable. I think the best > > GPU scaling program would be given by a completely new algorithm > > designed with fragment programs in mind, but this would require > > research and above all would break xmame's model of having the same > > algorithms accessible across different video drivers. > > > > _______________________________________________ > > Xmame mailing list > > [EMAIL PROTECTED] > > http://toybox.twisted.org.uk/mailman/listinfo/xmame > > > > _______________________________________________ > Xmame mailing list > [EMAIL PROTECTED] > http://toybox.twisted.org.uk/mailman/listinfo/xmame > _______________________________________________ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
