Ok, I overestimated the size of the lookup texture. I've now implemented the hq2x algorithm and it runs at a pretty favourable frame rate.
Are the developers interested in merging this? If so, which version of xmame would you like me to diff against? 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
