On Mar 19, 2:33 am, dave <[EMAIL PROTECTED]> wrote: > First I want to say thank you all for your timely replies. This is all > good food for thought. I've been programming more many years, but fast > graphics rendering is new territory for me. > > I'm hoping to fine something like a buffer_blit, where I can set all > the pixels to change using basic operators, blit them all at once to a > pixel buffer, then swap the visible buffer. Ideally it will only > change the region of the pixel buffer that needs changing. > > Because I want layers, I would like to take advantage wherever > possible of the available hardware features. I.E. ideally I am hoping > that the layers can be textures in memory that get composited in > hardware onto the screen. Maybe this is wishful thinking though? > > I'm also thinking that maybe I can reduce the number of active layers > from N down to 3 - the active layer, the layers below it, and the > layers above it. Obviously only the active layer needs any sort of > sprite-like animations and it on this layer than response time is most > important. Having to layer the top layers ontop of it may also play a > factor but, as I suggested, I can merge them all together in one time > and then use the merged result to layer on top of the active layer. > > I'm a little nervous about going the C/C++ route. It's been a few > years since I used them, I'm new to Python, and jumping into coding > Python extensions with C/C++ is not particularly palatable (though > I'll do it if I have to.) > > > Any GUI toolkit will work if you find the low-level access > > to their image memory buffers. > > That's another new step for me. Any ideas where to start? Thanks!
Some reading on fast 2d graphics: chapters 35-42 from http://www.byte.com/abrash/ and a lot of great stuff here: http://tog.acm.org/GraphicsGems/ -- http://mail.python.org/mailman/listinfo/python-list
