On Fri, Dec 23, 2016 at 4:45 PM, Mikhail V <mikhail...@gmail.com> wrote:
> Could you elaborate please? > Now that I'm reading more carefully, it looks like you're creating a palettalized RGB surface (8-bit indices to 24-bit color). Offhand, I also would expect referencing the indices into a 2D array to work. I'm tempted to conclude a possible bug, or at least an insufficiently helpful exception. A few questions: --Do you need to create a surface from data, or merely update a surface repeatedly? --Are you particularly tied to pygame.pixelcopy? I've found the surfarray module works best of the three (pixelcopy, surfarray, PixelArray), and you can use any for either task. --Are you tied to palettal color? These are slower, and more relevantly, less common and therefore more likely to be less robust. Their main use today is for accelerating palette rotations. Their higher memory usage is usually irrelevant for typical surface sizes. The copy buffer trick you're using looks a little suspect to me. 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. Ian
