Welcome to Emulationworld

Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


Subjectcps1/mame question regarding resizing palette new Reply to this message
Posted byerikduijs
Posted on09/12/05 03:39 AM



I noticed that in the CPS1 driver, a 'resizing palette' feature from mame is used. In the MAME source in palette.c, this resizing stuff seems quite complicated and I can't really get my head around what that actually is, and why hardware would have a palette which has a variable size.
Can somebody enlighten me a bit in this? (layman's terms please ;-)

Thanks




SubjectRe: cps1/mame question regarding resizing palette new Reply to this message
Posted byerikduijs
Posted on09/12/05 09:16 AM



After looking some more at it, it seems to me that this resizing palette thing is a kind of legacy optimization, which for me is probably not important (I always render to 32bit pixels).
Am I on the right track, or am I completely wrong?




SubjectRe: cps1/mame question regarding resizing palette new Reply to this message
Posted bysmf
Posted on09/21/05 03:32 AM



I don't see any palette reduction code in the latest source. It does palette banking, which is what the original hardware does.

smf





SubjectRe: cps1/mame question regarding resizing palette new Reply to this message
Posted byerikduijs
Posted on09/22/05 09:16 AM



Yes, I understand this banking, but in the cps1 mame driver, a call is made to palette_recalc() in palette.c, which seems to resize the palette.

> I don't see any palette reduction code in the latest source. It does palette
> banking, which is what the original hardware does.
>
> smf
>





SubjectRe: cps1/mame question regarding resizing palette new Reply to this message
Posted bysmf
Posted on11/01/05 02:06 AM



> Yes, I understand this banking, but in the cps1 mame driver, a call is made to
> palette_recalc() in palette.c, which seems to resize the palette.

Not in the latest version. I guess you are looking at one of the older versions, like 0.36.

Older versions of MAME tried to run all games in 256 colours, the alternative at the time was 16 bit mode which was slower & couldn't show so many colours ( a palette entry is 24 bit ).

At first this was ok, but later as systems were added that could display more than 256 colours there were various attempts at making them fit into the 8 bit graphics modes. This worked quite well as the games were not necessarily using all the palette entries or there were large number of repetitions.

Around the time MAME switched over to Windows it was decided to throw away the old limitations as they made the source code more complicated. So now MAME has 65536 palette entries & can generate either 16bit or 32bit displays.

One of the reasons that 0.36 is regarded as faster as the later versions is that it will generally copy less data over to your graphics card, on older machines the amount of bandwidth to the video card is quite low. dosmame supports it's own colour reduction now, although I've not tested it for speed recently.

smf





SubjectThanks! (nt) Reply to this message
Posted byerikduijs
Posted on11/04/05 05:10 AM



nt




Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode