This is very interesting. I had no idea. So guide me a slight bit and then Ill try to leave you alone J In the context of pygame how would I pursue RLE? My impression is I convert things into surfaces.. now it is out of my hands (it is a pygame surface) as I blit it. At what step am I intervening to RLE? If there is a link you can point me towards I will read.
Put differently right now I have tons of surfaces which I blit as needed (my sprites). I understand they could be derived from originaly RLE files but once they are pygame surfaces how is RLE involved? Thanks for your time! From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of René Dudfield Sent: Thursday, September 19, 2013 12:14 PM To: pygame-users@seul.org Subject: Re: [pygame] Pygame subsurface inherit surface flags? <-- RLE encoding Yeah, Run Length Encoding :) It is faster to blit as well. Iff your image repeats the same colour a lot. The reason is you can keep the same value in a register for multiple writes of the same colour, and you can batch colour writes into a multiple of eg 8 pixels at once. There is at least one less read per pixel. Note, that some array processing libraries also use compression for array processing. Since many times after a certain amount of memory used speed comes down to memory bandwidth. On modern CPUs, you often have the CPU just waiting for memory... and you have plenty of processing cycles to spare. So you can use those spare processing cycles to decompress or compress data, therefore allowing you to "transfer" more data over memory. cu. On Thu, Sep 19, 2013 at 6:06 PM, Lin Parkh <lpa...@comcast.net> wrote: OK I didnt recognize the acronym RLE encoding but decompressed I do ;-) I see how that would save memory but wouldnt that slow graphical performance because presumably it would need to be decompressed to blit? Im not worried about memory efficiency but FPS. Please advise. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of Lin Parkh Sent: Thursday, September 19, 2013 9:03 AM To: pygame-users@seul.org Subject: RE: [pygame] Pygame subsurface inherit surface flags? Thank you. I suspect you are right about HWSURFACE. For example I used to be able to generate these and now I cant at all with the same code! I suspect just doing a driver update to my video card squelched it. Color depth is good advice except I would have to drop my display color depth wouldnt I or I would have slow downs due to mismatch? And that would be annoying to any user. Ill look into RLE encoding. Dont know about that. From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of René Dudfield Sent: Thursday, September 19, 2013 12:28 AM To: pygame-users@seul.org Subject: Re: [pygame] Pygame subsurface inherit surface flags? Yeah, they should inherit the flags. However... you should generally avoid HWSURFACE surfaces. There are cases on some hardware and drivers where they actually get accelerated... but often they don't. If your sprites don't have many colours, dropping the colour depth will give you a speedup (less memory bandwidth used). Also RLE encoding can speed up drawing for some sprites. All the best, On Wed, Sep 18, 2013 at 9:11 PM, Lin Parkh <lpa...@comcast.net> wrote: Hi, I've read the documentation but am still hazy. If have defined a surface with specific flags (in particular pygame.HWSURFACE) should a subsurface of that surface inherit the flags (i.e. is also a hardware accelerated surface(i.e. in video card memory) or do I need to do an explicit 'convert' with the flags called again? My impression when I call 'get_flags' on the subsurface is that it is NOT getting the parent flags... but wanted to confirm this is expected and therefore I have to do an explicit convert. Thanks p.s. my overall context is I have loaded a texture atlas from file. I have given hardware acceleration flag (HWSURFACE) I now want sprite imagery derived from the atlas (subsurface seem the simplest and most efficient way to achieve this) but I want it to retain the same flags (e.g. HWSURFACE).
