On 29 July 2012 20:50, Ian Jeffray <i...@jeffray.co.uk> wrote:
> On 29/07/2012 20:34, Andrew Flegg wrote:
>>
>> 320x256 is common for games, but blowing these up by 3x to 960x768
>> seems sensible (on my setup at least). Adding another set for 3x would
>> be the easiest option, but adding support for arbitrary scaling
>> factors would be more flexible and also *reduce* the amount of code
>> (when the different variants of BPP & flags are taken into account).
>
> So long as we don't lose performance... lots of separately optimised
> functions are good for performance. And they're not /quite/ as
> similar as you may think at first glance.
I admit I didn't diff all 16 ;-)
But the differences between RowFunc8bpp2X and RowFunc8bpp1X seemed to be:
* VIDEO_STAT(DisplayRedrawForced) - 'flags & ROWFUNC_FORCE' vs. 'force'
(is that a mistake?)
* Shifting of "Available" (>>2 vs. >>3) - is that (4-HD.XScale)?
* Host_WritePixels vs. Host_WritePixel - could use a macro to avoid additional
function call overhead.
There was more difference between RowFunc8bpp2X and RowFunc4bpp2X, but
mostly power of two shifting; although the differences between the
palette and the cleverness around Shift may be harder to commonise.
Cheers,
Andrew
--
Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--
arcem-devel mailing list
arcem-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/arcem-devel
