Yes, I'm only blitting the visible parts. It's the tile layering that causes 3x more blitting. (floor, carpet, and a possible wall for every tile.) Blitting the whole 300x300 map will take a very looooong time . . .
. . . Okay so, will SDL 1.3 regular blitting be 3x faster? On Tue, Jul 12, 2011 at 11:52 AM, DR0ID <dr...@bluewin.ch> wrote: > ** > On 12.07.2011 20:12, Brian Brown wrote: > > Thanks guys, > I'm not using Pyopengl. (I found it a little too hard to use.) > Pygame and SDL are working perfectly for me-- except-- I need faster > blitting. That's all, I think. > I've designed my game's graphics to simply rely on the blitting of many > 60x60 24-bit surfaces. (Approximately 300 to 500 blits per frame on a > scrolling screen of 640x480 resolution. The game is tile based with an > overlapping 3D illusion. The floor is drawn first, the "mat" second, and the > characters and "blocks" sorted by distance from bottom of screen are last. > Should look fantastic when graphics are finished and when the fps is > higher.) > > If SDL 1.3 will blit basic 24-bit surfaces (with a single colorkey) 3x > faster I think my game will work quite nicely. > > * I am using convert(). > * I'm *not* using per-pixel-alpha. > * I even blit the freshly-loaded-surfaces onto a new surface to be sure the > surfaces haven't inherited any unnecessary data from the png file. (I found > this to significantly increase speed.) > * The whole screen is scrolling so I use pygame.display.flip(). > * I think I'm using 24-bit images. > * I need a high refresh rate for high speed chases with the local wildlife > . . . (bear, tigers, unicorns etc.) > * I'll have to try using surface.fill() instead of blitting . . . > * My program's code is already running at a nice speed. > > Sounds like a great idea to continue programming with pygame and then > later speed things up, but-- > > It's just a little harder to program with slow graphics --My personal > policy for low stress programming is to reward myself after every day of > hard work by playing the game, and it's not the most fun in slow motion. > > Is there a way to convert 24-bit pygame surfaces to 8 bit RLE just > to temporarily speed things up for testing? > Thanks for the great advice guys. > > On Tue, Jul 12, 2011 at 6:14 AM, René Dudfield <ren...@gmail.com> wrote: > >> On Tue, Jul 12, 2011 at 1:59 PM, Sean Wolfe <ether....@gmail.com> wrote: >> >>> Dude this was a really good answer. Rrrrrespect >>> >>> >>> Indeed, good answer. >> >> Also, are you using fast rendering techniques? >> >> - Using 8 bit RLE encoded surfaces for the low colour depth images >> - avoiding per pixel alpha surfaces. >> - using convert() appropriately (except not on those low colour >> surfaces). >> - using fill() to fill in colours instead of blit. >> - using LayeredDirty sprite group, and DirtySprite sprites to do dirty >> rectangle updates. >> - updating parts of the screen at the lowest refresh rate they need. >> eg, displaying fps, may only need be done once every 10 frames. >> - profiled your game ( to see which parts are slow.) >> http://pygame.org/wiki/Profiling >> >> >> >> SDL 1.3 is faster with opengl/direct3d surfaces. But it's _still not >> finished. >> >> >> cu. >> > > > > Hi > > Just a side note: If you have a scrolling world then blit only the visible > parts, that will give you a performance boost (not sure if you do this > already). > > ~DR0ID >
