<div class="gmail_quote">On Fri, Jun 12, 2009 at 6:29 PM, Johannes Schickel <span dir="ltr"><<a href="mailto:lordhoto@gmail.com">lordhoto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">J Northup wrote:<br>
><br>
><br>
> On Thu, Jun 11, 2009 at 7:08 AM, Max Horn <<a href="mailto:max@quendi.de">max@quendi.de</a><br>
</div><div class="im">> <mailto:<a href="mailto:max@quendi.de">max@quendi.de</a>>> wrote:<br>
><br>
><br>
>     So far, I see no actual cons to using Graphics::PixelFormat -- I<br>
>     think LordHoto refuted all claims otherwise so far. Maybe we miss<br>
>     something, though -- then I'd like to hear concrete arguments,<br>
>     though ;).<br>
><br>
><br>
>     Bye,<br>
>     Max<br>
><br>
><br>
><br>
> Sigh, I should have made a posting to the list right after the<br>
> conversation LordHoto and I had on IRC wednesday night.<br>
> The cons to using Graphics::PixelFormat are<br>
> 1) It is overkill -- it easily allows engines to specify a format that<br>
> is completely impossible, by mistake<br>
<br>
</div>And the engine author would easily notice it, because his screen would<br>
look strange. So? It's like that they have a typo in the enum...<br>
<div class="im"><br>
> 2) It requires the engine to specify color order, meaning that a minor<br>
> oversight on the part of the engine developer could result in it being<br>
> unusable on all backends with a different color order.<br>
<br>
</div>Why? Your idea was anyway to let the backend worry about such<br>
conversions, thus it would work just fine. Maybe explain this to me again.</blockquote><div><br>Err, that was my original idea several weeks ago. You convinced me that it wouldn't be a good way to handle it.<br>My current idea is:<br>
Backends which have hardware support for format conversion always respond that formats are supported, and handle conversion.<br>Backends which would be slowed by conversion respond that they don't support formats that they can't display natively.<br>
Engines whose preferred format is not supported either convert pixel formats on image loading (using generic functions provided for this purpose), or error out and refuse to run entirely.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">> 3) Additionally, the wide range of color orders that the engine could<br>

> potentially request necessitate a great deal of sanity checking on the<br>
> part of engines that only support one.<br>
<br>
</div>I still don't get this one, sorry.</blockquote><div>Do you understand what sanity checking is?<br>The backend would have to run a variety of tests to make sure that colors are in the correct order (eg: RGBA), or the PixelFormat won't make any sense to them. If backends aren't going to use the color order specified by the PixelFormat, then why use a PixelFormat at all?<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 4) Setting up a Graphics::PixelFormat structure takes a minimum of 8<br><div class="im">

> lines of code per structure. Engines like gob and groovie which<br>
> convert from YUV have to set up a list of several, and the difference<br>
> in coding required adds up over the course of three current and an<br>
> unknown number of future supported engines.<br>
<br>
</div>GOB and Groovie won't have to setup any PixelFormat struct. They'll just<br>
use the backend function to query all native pixel formats, you didn't<br>
implement that yet though :-).</blockquote><div>You keep saying that, but nobody else agreed with that...<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

With the SDL backend this isn't really possible, since you can first be<br>
sure to see the mode it chooses, when you setup a real video mode. So we<br>
might need to think about that. Maybe we'll just return that no pixel<br>
format can be used natively. Thus the engine just uses the best mode it<br>
supports and let the SDL backend worry about conversions. This might<br>
need some more thought!</blockquote><div>I think you aren't understanding this. The idea isn't that the compatibility list is a list of natively supported formats.<br>The idea is that the compatibility list is a list of formats that the backend can accept from the engine. If the backend responds that the format is unsupported, then the engine <b>can not</b> use that format for data.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> The compromise that LordHoto and I came to on IRC is thus:<br>
> Engines use the colormode enum type, and pass a list of supported<br>
> colormodes to initGraphics.<br>
<br>
</div><br>Yes.<br>
<div class="im"><br>
> initGraphics gets the color order (RGBA, ABGR) from the backend, and<br>
> converts the colormode enums.<br>
<br>
</div>No the color order has to be fixed, if the engine requests RGB555, it<br>
has to be R, G, B order. An engine not doing any conversions can't<br>
easily switch between RGBA and ABGR, the screen would look wrong.</blockquote><div>That's why I said that the engine <b>must</b> do conversions...<br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">> into Graphics::PixelFormat structures using a generic function<br>

> provided for this purpose.<br>
> initGraphics queries the backend regarding format compatibility, and<br>
> passes the first compatible format to the backend for initialization<br>
> during the gfx transaction.<br>
<br>
</div>Yes. (for cases, there's no natively supported format, check the next<br>
answer).<br>
<div class="im"><br>
> initGraphics errors out if endGfxTransaction returns an error in<br>
> setting up the screen with requested pixel format<br>
> engines query backend to determine the accepted pixel format<br>
<br>
</div>No, if there's no native supported format, the backend should do<br>
conversions. I thought we did agree on that.</blockquote><div>You were the one who convinced me that this was a bad idea...<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> When loading graphical resources, engines call a generic color-order<br>
> swapping function as necessary.<br>

</div><br>Kirben told me that those conversions would make the SCUMM code much<br>
more complex, but I'm not exactly sure. Kirben, maybe you can comment on<br>
this again? Anyway since the backend is forced to do conversion, this<br>
isn't exactly needed, it might be used by engine authors when they<br>
expire performance problems on certain backends. (See the mail from Max<br>
on 9th of July 10:54 AM).</blockquote><div>I am very confused as to why you believe we agreed that the backend is forced to do conversions. I said this at first, but you said it was a bad idea, and after a bit of discussion, I agreed with you that it was a bad idea.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> This way, engines get the simplicity of the enum type, but backends do<br>
> not have to worry about dealing with any format but Graphics::PixelFormat.<br>
> I am working on the proof of concept for this, but if there are any<br>
> complaints about this remaining, I will go ahead with one that uses<br>
> Graphics::PixelFormat exclusively.<br>
<br>
</div>Just for completeness, here's how I think it should work:<br>
<br>
The backend is required to implement the following functionality:<br>
<br>
"initFormat", used for initializing a specific format. This takes a<br>
PixelFormat.<br>
"queryNativeFormats", this returns a list of PixelFormat structs<br>
supported without conversion by the backend.<br>
"getScreenFormat", used to return the currently setup PixelFormat.<br>
<br>
Now there are different possibilites:<br>
<br>
1) The engine can work with any mode out there:<br>
<br>
In this case the engine should just use "queryNativeFormats" and select<br>
the one it thinks would be best. If there's no natively supported<br>
format, let it setup *any* format and let the backend worry how to deal<br>
with it.<br>
<br>
ALTERNATIVE proposal: let OSystem::initFormat take a pointer to a<br>
PixelFormat, if that one is zero, let the backend choose the mode it<br>
thinks is best for it. The engines will then just use the format<br>
returned by "getScreenFormat".<br>
<br>
That alternative proposal might be best for the SDL backend, since it'll<br>
first know the native mode when it has the video mode setup via<br>
SDL_SetVideoMode.<br>
<br>
2) The engine has a limited set of formats (at least 2):<br>
<br>
Let the engine pass a list of the enums to "initGraphics", as you<br>
proposed. "initGraphics" is now supposed to use the first format<br>
supported natively by the backend. If not it errors out. (One could<br>
think of some default graphics mode parameter, which will be used then<br>
no format has native supported, so the backend does conversion).<br>
<br>
All this is implemented by comparing requested formats to the return\<br>
value of "OSystem::queryNativeFormats".<br>
<br>
3) The engine can only work with a single format:<br>
<br>
Pass that mode directly to initFormat and let the backend worry about<br>
conversions to it's native mode.<br>
<font color="#888888"><br>
// Johannes</font></blockquote><div><br>Okay, let me try to explain my proposal better, because there has definitely been a misunderstanding.<br><br>The backend is required to implement:<br>void initFormat(Graphics::PixelFormat format): used for setting up the backend with a requested format.<br>
bool isABGR(void): true if the backend uses ABGR color order, false if backend uses RGBA.<br>bool isFormatCompatible(Graphics::PixelFormat format): true if the backend can accept data in that format, false if it can't<br>
Graphics::PixelFormat getScreenFormat(void): returns the currently set pixel format.<br><br>Now, there are two possible cases for the backend:<br>1) Backends which support fast conversion from any format, which will always return true from isFormatCompatible.<br>
2) Backends which support a limited number formats, which will fallback to CLUT8 if no compatible format is listed.<br><br>With backend case 2, there are two possible cases for the engine<br>1) Engine has an 8-bit fallback mode<br>
2) Engine reports an error and returns immediately.<br><br>Engines, meanwhile, are required to support ABGR and RBGA color modes, via convenience functions uint32 toABGR(uint32 color) and uint32 toRBGA(uint32 color) which I will provide.<br>
<br>If you have any questions or complaints about the proposal, please reply.<br>If I do not recieve any complaints about this proposal, I will post it and a list of other proposals currently under consideration on my blog to solicit further feedback about which option is best.<br>
<br>I sincerely apologize if I seem stubborn about this. What is happening is that each option continues to evolve in absence of discussion, so that by the time people say "we should do this", I have a set of better proposals. I will be more transparent about any further refinements to these proposals, adding the information to the discussion as soon as it becomes available, because I really do not want to tie the process of finalizing the API up any further than it already has been.<br>
<br>Jody<br></div></div>