Andre Majorel wrote: === On 2004-08-28 18:18 -0600, Lawrence Gold wrote:
> Hans de Goede added down-sampling support to the X11 and 3Dfx targets > in 0.86 that should allow 32bpp games to work on a 16bpp display.
That would certainly be a welcome addition.
> Eventually, this should make its way to the SDL and other targets, and > we may even finally end up with support for 8bpp displays again.
As TrueColor or PseudoColor ? Because, as I see it, the main point of running at 8 BPP is fewer screen updates for games like Bombjack that keep changing the palette. But Hans and you know that. ===
Well,
IMHO there are 2 possible reasons to support downsampling to 8bpp:
-use of tweaked vga modes in svgalib target (is/was this used by anyone?
-support of older hardware (non PC mainly) which only has 8bpp pseudocolor visuals
And there are three ways of doing the downsampling: -only support 16 bpp palletised games which have <= 256 colors and just only use the low byte of each pixel, this should be pretty easy. Pro's: *fast *moderatly easy to code Cons: *won't work with all games, but most older arcade games are palletised and have <= 256 colors. Since this are the only games which are playable on older hardware and are the games which need tweaked modes this might be an idea. -emulate direct 332 rgb Pro's: *moderatly easy to code *works for all games Cons: *colors will not be 100% correct -emulate direct 332 rgb, and try to initialise the pens to a color actually used by the game, or to an avarage color if there are more then 256 colors (the dos mame way) Pro's: *works for all games Cons: *hard to code *colors will still not be 100% correct all the time
And we could of course mix and match these depending on the game.
About games like bombjack, using 8 bpp modes isn't going to be such a big speedup as it used to be since we currently don't have any kind of dirty marking so we have to update the whole bitmap in the framebuffer anyway.
But the real question is do we really want to jump through a lott of hoops to get:
-tweaked modes in svgalib, but I have the feeling that nobody is using
the svgalib target and if somebody really want this he could/should use
advanceMame
Also svgalib itself seems to be pretty much unmaintained, the latest stable release is ancient and doesn't compile on modern distro's without a pile of patches. The unstable version needs a kernel module for some stuff and this module only works on earlier 2.4 kernels.
And svgalib has been dropped from most current distros (debian never drops anything, except for licensing reasons)
Besides that in 1 few years most pc's will have lcd screens, try throwing a tweaked mode at that.
-support some really old non-pc hardware or even older pc-hardware (most PC's can do 16 bpp for decades now)
The pseudo-color support has always been a bitch, take a look at the code still in x11_window for example:
-under X11 we need to share the palette with other apps
-thus we can't control the colors for each pen, so we need a lookup
table between the pen numbers as used by mame and actual pen numbers
which where free for use by us.
-we can use a private cmap, but using private cmap's sucks (the rest
of the displays colors go all funky, great!)
-also if we share colors we can't always write to a pen!
-because of this (sharing pens and/or using a private cmap) we need todo
a shitload of bookkeeping.
-the question is if we add 8 bpp downsampling thus all that code still
work, it still compiles but hasn't been used (ran) for ages.
So my 2 cents on downsampling to 8bpp are: -do we really really want this? I personally don't think it is worth the trouble -if we want it I might one day take a look at it, but this has low low priority -if we can reach concensus that we don't need it I would love to remove all the unused 8bpp code still lingering around in the unix tree. (Most of my current patches have not only been about adding/ fixing functionality, but also about making the code smaller and cleaner)
In other words: please tell me you don't want this cruft so I can clean it out :)
*** DISCLAIMER ***
Last but not least: I'm no longer the xmame maintainer and I'm in no way disputing Lawrences status as the xmame maintainer. As such the contents of this mail should be read as if it has been written by someone who just freshly joined the mailinglist.
Lawrence has the final word over any descissions concerning xmame including this one. As already written this mail is just my 2cents, my
personal opinion and nothing more!
I may be back todo some hacking for fun and glory, but I still have to be carefull with my health so I might drop of the radar again tomorrow.
Lawrence has been doing a great job and I hope he can keep doing it for a long time, I say: 3 cheers for Lawrence :)
Regards,
Hans
-- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es
_______________________________________________ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
