At least on OS4 the handling of video memory is not so good, so if something uses too much video memory then the whole system can slow down. (AROS *may* be even worse, but it is typically used with systems that have tons of video memory. I'm not sure what happens on MorphOS.)

This is why my cGfx module allows you to mark bitmaps as "not drawable" using the setIsDrawable() method. A non-drawable bitmap is not stored in video memory, and so does not waste memory.... but you cannot draw it either (it must be set as drawable first, which will cause a very very small delay while the bitmap is copied to video memory).

Does that sound like a lot of boring work? That is why my cGfxSprite module automatically makes bitmaps non-drawable when their sprites are not visible on screen! But because this could cause a noticable delay when many sprite bitmaps are copied into video memory at the same time, I do allow you to disable this behaviour using setAutoIsDrawable().

PictureAlbum would work very slowly on the Sam440 (64MB of Video RAM) without this feature of cGfxSprites.


So if you want the easy life then use cGfxSprites. You have less control of how your bitmaps are drawn, but it saves you lots of hassle.

PLEASE NOTE that cGfxSprites cannot manage bitmaps that are not used by sprites. So you need to make sure that such bitmaps are marked as "non-drawable" as soon as they are loaded. You COULD use setIsDrawable(), but it would be more efficient to never load the bitmap into video memory in the first place. That is why the loadPicture() method has the "notDrawable=FALSE:BOOL" parameter (when set TRUE the returned bitmap is not drawable).

On initial stage coding of my new game I detect big gfx memory usage - now it 92 Mb. In future I expect over 128 Mb... So I want ask how coding my game. I have 2 options:
1) Load and initialise all graphics, even if not will be used (this is board game - for every possible board changes I must load gfx, but in single play will be used 10% of board...)
This have advantage: not delay between moves - I not must search what gfx I need load; easy code, and disadvantage: big gfx memory usage, waste of resources
2) after every move load and initialise only this gfx that can be used. Advantage: much less memory usage, even at game final stage. Disadvantage: hard code - I must check what i need between every player move - It increase coding time and decrease coding motivation. Between player moves game "do" little" delay for additional board check..

Or maybe I no need worry about memory usage - gfx driver take care of it and not should be big delay in performance even on low gfx memory board...