|
This is very interesting. I had no idea. So guide me a slight bit and then I’ll 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-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx] On Behalf Of René Dudfield Yeah, Run Length Encoding :) 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 <lparkh@xxxxxxxxxxx> wrote: OK I didn’t recognize the acronym “RLE encoding” but decompressed I do ;-) I see how that would save memory but wouldn’t that slow graphical performance because presumably it would need to be decompressed to blit? I’m not worried about memory efficiency but FPS. Please advise. From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx] On Behalf Of Lin Parkh Thank you. I suspect you are right about HWSURFACE. For example I used to be able to generate these and now I can’t 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 wouldn’t I or I would have slow downs due to mismatch? And that would be annoying to any user. I’ll look into “RLE encoding.” Don’t know about that. From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx] On Behalf Of René Dudfield 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 <lparkh@xxxxxxxxxxx> 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). |