[Scummvm-devel] Bitdepth/pixel format API concerns

[Bertrand Augereau]

> > Different GPUs have different framebuffers format, and
> moreover
> > graphic hardware endianness is not always the CPU
> endianness (ie
> > XBox360 vs PS3).
> But should engines bother about that?

They should not but they may have to :)
If the conversion must be done by the backend through CPU on a small device, the good thing performance-wise may be to render directly in the good format.
This said, the DS for instance can do a full frame pixel swizzling in an adventure game frame. Maybe at the expense of quality scaling. I don't know if we have weaker devices than this, or if we even want to :)

> Consider this. DC does not have framebuffer at all, and it
> renders 2d
> gfx on couple of triangles. Does it mean that we have to
> add support
> for that to _engines_?

I don't know the details of DC rendering, I was doing PS2 rendering at the time the Dreamwast was alive and kicking, but surely the backend has to update texture memory with the content of the gfx frame, with a format supported by the PowerVR. 

> 
> The solution which we should use have to put least load on
> the team,
> still reaching its goals, i.e. compatibility and ease of
> use.

This is surely a noble goal but it has to be balanced with performance on small devices, I guess.
I'm playing the devil's advocate, because I'm quite sure any platform that can run ScummVM (which is quite "slow" compared to the original implementations of the games) can translate pixel formats every frame with a bit of fast brutal code on any platform we support, so I'm all for going with the least coupling between the engines and the backend.
Note that in the "ideal" case of orthogonality we would need one pass of color conversion and one pass of scaling which is a (at least theoretical) waste of resources.

My 2 cents... :)

Cheers,
Bertrand