> --Are you tied to palettal color?
Yes in many cases. I need also palettal rendering for higher
depths. Ideally graphical frontend should support also 16 bit and 32 bit
palettal rendering. And ideally the final colorisation should happen on GPU
namely I send an integer array to video system and video system
must resolve the values to the end format and ideally
this should be done in most effective way.
But this is not what Pygame can do.
So currently for higher depths I use numpy to convert integers
to composite colors in each loop cycle. So Pygame provides only 8 bit
paletted, but actually for many applications it is good enough.
Even if I'll write commercial arcade game, it would not suffer
much from being 8 bit color. Most of the the time it is not
about smooth gradients, it is about action and fun.
> The copy buffer trick you're using looks a little suspect to me.
But since there is no other method which is comliant with numpy order,
and as I see now, it works as fast as pixelcopy.
Look what I mean, if I use get_buffer() and then I simply copy a
memory chunk from one place to another(?), it works and the result
shows up correctly. So one numpy *row* is mapped to one image *row*
on the screen.
> In particular, if the internal layouts differ at all (for example, if the NumPy
> array is contiguous, and the SDL surface has row padding, both of which are likely)
> then the copy will fail (fatally crash) in some cases. I don't know whether PyGame
> is smart enough to anticipate that. Odd width/height surfaces,
> and especially truecolor surfaces, would be a reassuring test.
Yes there are a lot of alignment nuances here. As as understand
GPU surface must be memory aligned, so odd shapes must be padded
into aligned rectangels. Especially 24 bit formats makes it
even harder to convert.
Probably there is more criterias here that I am not aware of
and objective arguments to prefer "FORTRAN" order, apart
from having more traditional [x,y] notation?