Re: [openMSX-devel] Removing 16 bpp support

[Alex W. <ale...@sc...>]

Hi,

In Android it's for performance reason. Here is the explanation in the
readme from the commander genius android SDL port:

/Also bear in mind that 16-bit BPP is always faster than 24 or 32-bit,//
//even on good devices, because most GFX chips on Android do not have
separate RAM, and use system RAM instead,//
//so with 16 bit color mode you'll get lesser memory copying operations.//
//
//The native Android 16-bit pixel format is RGB_565, even for OpenGL,
not BGR_565 as all other OpenGL implementations have.//.//
/
Cheers,
Alex


Op 17-11-16 om 16:51 schreef Maarten ter Huurne:
> Hi all,
>
> Currently openMSX can render in 16 or 32 bpp. MSX2+ has more colors than 
> 16 bpp allows for and gradients look better in 32 bpp, so 32 bpp is 
> clearly the superior choice. But we had 16 bpp support for systems that 
> either didn't support 32 bpp at all or where 32 bpp is possible but 
> slower.
>
> We currently force 16 bpp on Android and on Pandora. I think both those 
> systems should be capable of 32 bpp, so I'm guessing this is for 
> performance reasons. What I don't know is whether 16 bpp is actually 
> necessary to make openMSX run fluently or whether we did this without 
> testing. We use 32 bpp on the GCW Zero, which has relatively slow RAM, 
> so I imagine most devices will be able to handle 32 bpp just fine.
>
> The only system I know of that wasn't capable of 32 bpp is the Dingoo 
> A320, but we dropped support for that already because the toolchain 
> lacked sufficient C++11 support.
>
> Dropping 16 bpp support will reduce the size of the generated code a 
> lot, since we instantiate many rendering and scaling classes twice using 
> templates. It will also reduce the complexity of that code, by 
> eliminating the need for templates.
>
> It will simplify the image loading code, since we'd only have to load 
> images to 32 bpp surfaces. And it will simplify the move to SDL2, since 
> we then don't have to support 16 bpp in any of the video code that 
> requires replacement.
>
> Note that in SDL2, if you run in windowed mode or in non-exclusive 
> fullscreen mode (the mode that produces the best results), the window's 
> bpp is determined by the desktop/OS and not the application. So having a 
> full rendering pipeline using only 16 bpp, like we had on the A320, is 
> no longer an option anyway.
>
> I'd like to remove 16 bpp support on a branch and then have people test 
> the result, in particular on Android. If there are no serious 
> regressions, I'd like to merge it onto master, before the SDL2 migration 
> completes (since it simplifies the migration).
>
> So, are there any objections to removing 16 bpp support? Any details I 
> should take note of?
>
> Bye,
> 		Maarten
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> openMSX-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmsx-devel
>