
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

</style>

</head>

<body class='hmmessage'>

<br><br>> Date: Sat, 13 Jun 2009 17:33:54 +0200<br>> From: lordhoto@gmail.com<br>> CC: scummvm-devel@lists.sourceforge.net<br>> Subject: Re: [Scummvm-devel] Bitdepth/pixel format API concerns<br>> <br>> Eugene Sandulenko wrote:<br>> > On Sat, 13 Jun 2009 12:15:22 +0000 (GMT)<br>> > Bertrand Augereau <bertrand_augereau@yahoo.fr> wrote:<br>> ><br>> >   <br>> >> Different GPUs have different framebuffers format, and moreover<br>> >> graphic hardware endianness is not always the CPU endianness (ie<br>> >> XBox360 vs PS3).<br>> >>     <br>> > But should engines bother about that?<br>> >   <br>> I guess only in the case these platforms would have too limited <br>> performace otherwise. So if the engine is able to convert all data on <br>> the first load to the native format, it would be better than doing a <br>> conversion every copyRectToScreen call. Of course if the backend is able <br>> to do that conversion without any real performance loss it should be by <br>> the backend.<br>> <br><br>Why not use the appropriate set of functions to do that depending on the backend<br>itself, in a similar fashion to how we handle platform endianness? (like I mentioned<br>in a previous e-mail). There won't be any performance loss there, as each backend<br>would use its own set of functions.<br><br>> Thus I agree with Max' proposal:<br>> <br>> 1) Let the backend worry about conversion.<br>> 2) If an engine expires too much performance loss on an specific <br>> backend, try to optimize the engine with format conversion on load if <br>> possible.<br><br>I agree with that too :)<br><br>Filippos<br><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' target='_new'>See how.</a></body>

</html>