(I just wish for a simplified accurate answer) On Tue, Jul 12, 2011 at 6:26 PM, Brian Brown <bro...@gmail.com> wrote:
> 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 >> > >
