Browsing this Thread:
1 Anonymous Users
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Home away from home
 
|
Beware that next release of PortablE renames "UsageCount" to "VisibleCount" for method names.
Posted on: 2014/5/24 11:34
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Home away from home
|
Mr Darek reported that non-drawable bitmaps still appeared to be using video memory. I have now found & fixed the problem, and it should be included with the next beta release of PortablE.
Posted on: 2013/5/6 8:49
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Home away from home
|
I have updated the code in my previous post, to make it easier to use. You can now use changeSpriteFrame() to set the first frame.
Posted on: 2013/3/31 16:06
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
if you DO share bitmaps, then I would have to modify my previous changeSpriteFrame() procedure to handle that case. I've rewritten that procedure so that it works when bitmaps are shared by sprites: Quote: <pre>PROC changeSpriteFrame(sprite:PTR TO cGfxSprite, newFrame) (Again, this is untested, but most likely works! Let me know if you have problems using it...) This should now work in 'all' situations, as long as you have disabled your sprite layer's Auto Drawable behaviour. You also need to ensure bitmaps are non-drawable before adding them to a sprite (as a frame). EDIT: updated code.
Posted on: 2013/3/23 11:17
Edited by PortablE on 2013/3/31 15:03:31
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Just can't stay away
 
|
OK, I decide total rewrite my code because start have trouble with all possible arrays. Now I have object style code. I have as many object as possible sprites on gamefield, in objects are store position, single sprite index and other important for game board field data. I save 20 Mb gfx memory so it not too bad result.
Posted on: 2013/3/23 11:10
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
I see - this method will not be good for me, because I will be must manually detect what sprite entering into visible screen area (after disabling autoupdate). You do not HAVE to detect which sprites are visible: If you want you can leave any 'active' sprites as drawable (even if they happen to be off screen). It will just use a little more video memory. In other words, mark all bitmaps as non-drawable, except those which are used by the current frame of any sprite. This should be quite easy to do if you do not share bitmaps between sprites... OTOH if you DO share bitmaps, then I would have to modify my previous changeSpriteFrame() procedure to handle that case. Does that solve your problem? If yes then I don't need to answer your double-dimension-table question (which sounds more tricky).
Posted on: 2013/3/22 14:23
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Just can't stay away
|
OK,
I see - this method will not be good for me, because I will be must manually detect what sprite entering into visible screen area (after disabling autoupdate). But I have other solution - I using frames like double dimension table :) I have array of ptr to sprites and frame is like second array. So I can replace using frames by using double dimension table for sprites. But I not know how defining that array. Can I ask about example or how adopt fast tables examples into double dimension tables of sprites...
Posted on: 2013/3/21 20:35
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Home away from home
|
Assuming you have disabled your sprite layer's Auto Drawable behaviour, and assuming Auto Redraw is disabled, and assuming you have one unique bitmap for every frame of every sprite, then you could do something like this to change frames of a sprite:
Quote: mySprite.getDrawable(mySprite.getFrame())::cGfxBitmap.setIsDrawable(FALSE) But that is a bit ugly to type every time, so I would create a procedure to do it, and that would also allow optimising it (and probably make it easier to understand: Quote: <pre>PROC changeSpriteFrame(sprite:PTR TO cGfxSprite, newFrame) This procedure also has the advantage that it works when Auto Redraw is enabled. WARNING: I have not tested this code, but will probably work!
Posted on: 2013/3/21 20:24
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
But I no need sprite animation in my project. So can I disable drawable atribute for all not current frames and it will be help for saving memory? I am intrigued what you are using sprite frames for, if not animation!  But yes, making unused frames non-drawable will save video memory... BUT ONLY IF (1) your sprite bitmaps are large, or (2) you use lots of sprite frames, or (3) you have lots of sprites with *different* bitmaps (i.e. they don't share bitmaps). Quote: Can I ask about example how set drawable and unset drawable for "X" frame Ysprite? You don't make your *sprite's* frame non-drawable, you make your sprite frame's *bitmap* non-drawable. Your code would look something like this: Quote: yourBitmap.setIsDrawable(FALSE) (where yourBitmap is the name of the sprite frame's bitmap) Note that you must ALSO prevent it from automatically making bitmaps (non)drawable by disabling it for the sprite's whole layer. For example, if you were using the 'cGfxSpritesSimple' module, then you would use this: Quote: gfxLayer.setAutoIsDrawable(FALSE) Or if you are using the 'cGfxSprites' module, and you want to disable it for ALL layers, then you can use something like this: Quote: gfxStack.setAutoIsDrawable(FALSE) (where gfxStack is the name of your stack of sprite layers) Quote: What changes will be done if sprite go out from visible area and return to it? - automatic drawable Portable language feature restore automatically drawable attribute for all frames of that sprite - how prevent it? PortablE keeps track of which sprite bitmaps are visible. When no visible sprites use a particular bitmap, then it automatically makes that bitmap non-drawable (and automatically makes it drawable when the bitmap becomes visible again). You prevent it doing this by using setAutoIsDrawable() in the way I explained above. BEWARE: If you share one bitmap between several sprites, then you must ensure that bitmap is drawable if any of those sprites are visible.
Posted on: 2013/3/21 20:04
|
|||
|
||||
|
Re: coding strategy for big gfx memory usage
|
||||
|---|---|---|---|---|
|
Just can't stay away
|
OK,
Because all my graphics are multiframe sprites, I read that by default all frames are drawable (because frames must be ready for sprite animation). But I no need sprite animation in my project. So can I disable drawable atribute for all not current frames and it will be help for saving memory? Can I ask about example how set drawable and unset drawable for "X" frame Ysprite? I want manually handle frames, because set frame, set drawable for it and disable drawable for last used frame it should be anyway faster then hiding old sprite, unhiding new sprite + set position + search in table with calculation for proper sprite to display... What definition should be added in program code? What changes will be done if sprite go out from visible area and return to it? - automatic drawable Portable language feature restore automatically drawable attribute for all frames of that sprite - how prevent it?
Posted on: 2013/3/21 19:17
|
|||
|
||||
You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create PDF files.
You cannot get print page.
