Hi Dariusz! 32-bit image support would be a nice feature indeed, and I considered it some time ago. The problem is that the entire rendering pipeline is done in 8-bit indexed mode -there are some intermediate buffers to determine visibility and some effects-, and it's just in the last step that the palette color is fetched and set to the final. So it's not possible to feed the input of the pipeline with direct RGBA colors, because they don't fit. There may be a compromise that is 32-bit images would go directly to the framebuffer, bypassing the intermediate steps, but that would result in severely reduced feature set compared to regular 8-bit images, and that's not what people may expect... what do you think?
What sort of limited feature set are we talking about? Anything that deals with palettes is a fair game, I guess since you can't do palette swaps/shifts with ARGB or even RGB images (other than doing graphical equivalent of search and replace I guess, but it's less performant and unneeded).
Also what visibility checks are you doing? If you are doing these to avoid overdraw, you can safely disable those I guess as modern devices are performant enough to handle overdraw in 2D space.
Perhaps if you'd write more about what algorithms stand in the way we could figure ways to change the algorithms involved so they'd work with 32bit images (other than palette shifts, since they'd be too cumbersome to do with 32bit images and should be limited to 8bit assets).