I'm not sure what's easiest for Lawrence, but if you do a diff against the CVS over at mess.org, either Lawarence or myself can check the code in and get some more user testing with it.
On Fri, 17 Dec 2004 12:46:06 +0000, Matthew Earl <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
