That might work . . . : ) On Tue, Jul 12, 2011 at 6:58 PM, Brian Fisher <br...@hamsterrepublic.com>wrote:
> If the layering is something that is consistent from one moment to the > next, and you really have an overdraw of 3x, you can pre-combine and cache > the visible parts, which could potentially make it take 1/3rd the speed > (that's your goal, right?) > > > 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 >>> >> >> >
