<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Further to this: The problem posed seems to be exactly the same as platform endianess.<br>We can handle this in the exact same way that platform endianess is handled, and hidden<br>from the engines themselves. I.e. you can have a look at common/endian.h and the<br>SCUMM_LITTLE_ENDIAN / SCUMM_BIG_ENDIAN defines. We can use similar defines, e.g.<br>SCUMM_16BIT_ARGB and SCUMM_16BIT_BGRA or more, and we can define the appropriate<br>set of functions depending on the platform that ScummVM runs under, therefore hiding<br>the complexity from the engines themselves, and having only one format, RGBA.<br><br>Regards<br>Filippos<br><br><hr id="stopSpelling">From: philipk79@hotmail.com<br>To: scummvm-devel@lists.sourceforge.net<br>Date: Sat, 13 Jun 2009 14:40:51 +0000<br>Subject: Re: [Scummvm-devel] Bitdepth/pixel format API concerns<br><br>
<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>
<br>> I see no need on adding any code to perform RGBA->AGBR mode by engine.<br>> It is backend task to do that. Engine should provide fixed order.<br>> <br>> Consider this:<br>> <br>> If engine are to provide conversion, then on adding new backend engine<br>> authors have to work on it. This is bad. Instead backend authors should<br>> know what they platform really requires.<br>> <br>> And if, say, we will have some exotic ABRG1333 or whatever platform,<br>> why engines should bother? They should work with what is convenient for<br>> them, just as Kirben pointed out.<br>> <br><br>I agree with this, it's easier to provide *one* mode to the engines (probably<br>RGBA). The engines should be agnostic of the platform they run under, so<br>if a backend supports AGBR, then the conversion to and from RGBA should <br>be done at backend level, not engine level. This would simplify the overall<br>initialization phase at the engine level considerably, and the complexity <br>would be moved to the backend level (where it belongs). There shouldn't<br>be any need to provide flexibility to the engines, in fact it would make<br>life easier for everyone if the engines would only have to deal with one<br>order (RGBA, most probably, as that's the one used currently).<br><br>Filippos<br><br><hr>Insert movie times and more without leaving Hotmail®. <a href="http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009">See how.</a><br /><hr />Lauren found her dream laptop. <a href='http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290' target='_new'>Find the PC that’s right for you.</a></body>
</html>