Is this the right forum for development ideas?

[robinwatts]

Hi,

Is this the right forum for development ideas (for the WinCE version), or should suggestions/ideas etc go elsewhere?

On the assumption that it is, I'll drop the following in:

While I was looking at the SDL code the other day, I was struck by a random idea. Currently (as I read the code, and I could be wrong!) the code blits first (e.g. via Blit1to2) then does any scaling that is required (e.g. PocketPCHalf), then that gets rotated onto the screen.

Assuming I've understood it right, it strikes me that we could probably make significant savings by combining some of those steps; say by doing "Blit1to2AndScaleHalf".

I should immediately say that:

* I don't understand the code well enough to know how much of a paradigm shift this is - it could easily be completely impossible to combine the steps for architectural reasons.

* I know that there is a new version of the SDL in the pipeline - maybe that's done some of this stuff already?

* This may already be planned for future versions.

Regardless of the above, I thought I'd float the idea here for comments, at least partly because I've got a REALLY crap memory and if I don't, I'll unquestionably forget it...

Thanks,

Robin

P.S. Does anyone know what areas of the code are the 'slowest' bits? (i.e. which areas would benefit most from optimisation?). I've got an ARM coded version of the Tremor lib lying around, and I've done ARM coded MPEG2 and MP3 playing code before, but having some direction before launching randomly into assembly coding bits would be nice.

Everything seems to run pretty much full speed on my device here, but it's a 400MHz thing, so other peoples experiences may be different...

[knakos]

You're right, there's a lot of data copying going around in the SDL backend. It is also true that the order would be better optimized if, in one step, palette xlat, scaling and blit directly to the framebuffer was done (and I am doing this in other wince projects).

However, and I'm no way an SDL expert/architect, plugging in a couple of those steps in the Blit1to2 function does not seem right. If I interpret the API correctly this is a copy(translate)-blit. What would be needed here is a "StretchBlit" kind of operation. So, the semantics for this seem wrong to me and for such large projects as scummvm semantics are almost everything.

The perfect way to do this would be to ditch SDL completely and use OSystem's excellent facilities to drive the hardware directly. But I'm not in favor of doing that change at this time. I think I need to restore and improve the end-user experience in a few different directions before attempting a significant change which would put back development for a while and potentially introduce instability.

Also, I do not want to deviate from the external libraries much by coding in changes. SDL is the only exception, where the official ce subsystem does not meet my requirements, at least last time I checked. That's why I'm maintaining the 1.2.6 "custom" branch of SDL, as set forth by arisme.

Cheers,
K.