Re: [hatari-devel] How many colors when rendering in Hatari ?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Le 16/04/2013 18:09, Eero Tamminen a écrit :
There's no direct support for 24-bits, only 32-bits.
Just look at the file names in src/convert/. :-)

24/32 are similar, just force the alpha byte to a constant value

ST VDI and monochrome modes support only 8-bits, higher bitdepths
are converted from 8-bit.

do you mean VDI mode is requesting a 8 bpp surface in SDL, whatever the screen real bpp is ?



Or we could add in Hatari an optionnal pass to convert the 24 bpp
surface to 8 or 16 bpp before. This would be a little slower (and that's
not even sure), but it would be much easier to maintain a 24->8 or
24->16 conversion of the whole surface instead of doing a specific
conversion by blocks of 16 pixels as it is today.

Most common screen formats nowadays are probably 16&  32-bit.

Main reason for having direct convertors for different modes
is speed, in ST emulation screen convertion is one of the
largest CPU consumers (with full timer-D interrupts).

I'm not sure there's such a huge gap between working with a 8bbp surface and a 24 bpp surface. More bytes to move of course, but with today cpu architectures and caches I'm not sure it matters anymore (especially with the rather small window's size we're daealing with)
..
Still, could be interesting to benchmark 10 seconds of a demo doing lots of color change in 8 bpp, 16bpp and 24bpp to see what kind of numbers we get.


But I think reducing&  simplifying that code would be good.
You could consider changing the conversion routines to be
line based, see todo.txt for more info.

The conversion routines could be line based / screen based (that's the same, just a loop for each line).

My aim for the video emulation is to have an adaptative mode that can draw pixels every 4 cycles when necessary or as a whole line when no video trick is detected (today, we always drw a whole line and that's also a pain to maintain when you consider all the border removal combinations that can happen)

Nicolas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/