Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Deleting / Unsetting Hierachical Objects / Faces

 [1/8] from: james::mustard::co::nz at: 20-Dec-2001 0:54


Hi All, At present I am working on a bit of code that encapsulates over 300 faces into a single context. Unfortunately since these faces are all ordered in an object-like manner and some have timers involved, doing a mass delete of the object is not always giving expected results and memory is not being released until the script ends - this gets to be an issue once the 65MB object is re-loaded a few times... (Am expecting on average about 1000 - 2000 reloads of the object as it is part of a game interface, also the test scripts and associated files are over 5MB compressed so they wont be sent anywhere in a hurry ;-) ) First I defined an object called desktop that is simply a screen-wide face (yes - i know this overrides the internal desktop command in view). To desktop/pane I append the my-object/my-top-face (which by default includes all its subfaces and animations). Then to test memory release I added a button to desktop (see below) to release my-top-face from the desktop and kill my-object like so: => button "Remove Object" [remove find desktop/pane my-object/my-top-face my-object: copy []] ;I also tried unset 'my-object in the remove button - but this did not affect sub-faces and timers Next I added a button to call in the %my-context-object.r file which creates the my-object and appends its my-object/my-top-face to the desktop. => button "Add Object" [do %my-context-object.r show desktop] (code from %my-context-object.r is merely an append desktop/pane my-top-face) What I need to know is: 1) How do I properly delete huge multi-level objects (please don't say property by property...) 2) How do I make sure that all memory is reclaimed (ie trigger garbage collection manually) - provided this is not already covered by step 1. Thanks :) James.

 [2/8] from: james:mustard at: 20-Dec-2001 1:19


For the curious: http://www.mustard.co.nz/rebol/grid1.jpg http://www.mustard.co.nz/rebol/grid2.jpg (No I didn't draw all the pretty 3D ships - i'm "borrowing" them until I have the game mechanics worked out enough to go talk to a artist friend.) Making this in REBOL has so far proven quite fun as REBOL has got to be the most rapid platform for idea coding I have ever found :) James.

 [3/8] from: petr:krenzelok:trz:cz at: 19-Dec-2001 13:43


Hi, 1) - let me say, that answers I am going to provide you belong more to Cyphre, who is nowadays sporadically connected to internet, so I will try to answer some of you questions ... - Cyphre uses different technique in his Beast game demo. He uses draw dialect, IIRC. He simply renders faces into background. Fast enough - you need only one update of the scene - the background update. - I am not sure above has something to do with timers. Too many of face timers could imo slow down the scene. Current fps rate is also limited to average of 20 fps IIRC. Let's hope RT removes that limitation .... - Cyphre also found a bug with even flow - although faces were hidden, their even mechanism was still active. I am not sure if it is corrected already or not. Maybe that is your case? Even removing face from its parent pane does not mean it is discarded? not sure .... - In opposite - Cyphre would welcome ability to "freeze" the face - so just let the face be part of the screen (visible), but stop receiving events for it ... - You can try to invoke garbage collection by calling 'recycle Take my comments with care, please, as I can be pretty inaccurate in above areas :-) Cheers, -pekr-

 [4/8] from: james:mustard at: 20-Dec-2001 2:49


Thanks for the tips Petr :) I got most of the memory recovered now - it seems that when you reset / unset an object none of its member attributes / objects are sent to garbage collection - especially in the case of large series of images like i am using in my image-bank. These all had to be deleted manually before resetting parent objects. eg: while [(length? space-station/image-bank/images) > 0][remove space-station/image-bank/images space-station/image-bank/images/1] space-station: copy [] recycle It would be nice if deleting the container removed all the contents rather than having to fish through the contents and kill each one... :) James.

 [5/8] from: petr:krenzelok:trz:cz at: 19-Dec-2001 14:56


How's the speed of your game? It can be imo hardly snappy, if you use so many faces in the display, no? :-) Thanks, -pekr- James Marsden wrote:

 [6/8] from: nitsch-lists:netcologne at: 19-Dec-2001 18:45


RE: [REBOL] Deleting / Unsetting Hierachical Objects / Faces ---releasing objects: Usually dont reference it and let gc do the work. but functions hold the arguments of their last call in current rebol. its freed when they are called again. with few large objects this is wastefull. clearing the tops levels of such a object/block might help. also there is 'load-image, which keeps a cache with all loaded images and looks there first. i expect rebol uses it internal. it has an option /clear to clear it. ---for referencing: why don't you use objects of objects? even if thats one-field objects like make object![value: something] this style is used in /view everywhere (like writing face/text the long way.. instead of hacking to use the 'text somehow). -volker [james--mustard--co--nz] wrote:

 [7/8] from: james:mustard at: 20-Dec-2001 9:45


Petr Krenzelok wrote:
> How's the speed of your game? It can be imo hardly snappy, if you use so
many
> faces in the display, no? :-)
Its seems to be running at 32tps quite happily... go figure :) I haven't tried it at a higher rate yet :) James.

 [8/8] from: james:mustard at: 20-Dec-2001 10:01


Volker wrote:
> Usually dont reference it and let gc do the work.
GC wasn't doing the work :)
> but functions hold the arguments of their last call in current rebol. > its freed when they are called again. > with few large objects this is wastefull. > clearing the tops levels of such a object/block might help.
Yup - that is what i resorted to.
> also there is 'load-image, which keeps a cache with all > loaded images and looks there first. > i expect rebol uses it internal. > it has an option /clear to clear it.
I didnt use this as i created my own image cache because I needed finer control over the structure.
> ---for referencing: > why don't you use objects of objects? > even if thats one-field objects like > make object![value: something] > this style is used in /view everywhere > (like writing face/text the long way.. instead of hacking to use the 'text
somehow). That's exactly what I did do :) my-object: context [ img: make object! [ img-path: none img-file: none image: none ] image-bank: make object! [ images: copy [] make-images: func [image-path /local c][ for c 1 16 1 [ append self/images make img [img-path: image-path img-file: join image-path [c ".jpg"] image: load to-file self/img-file] ] ] ;.... <snip> .... ] James.