Deleting/clearing loaded objects between scenes

edited August 2010 in Help request
Say I've got two "scenes" or modes for my game---a main menu, and the actual game itself.

The main menu opens first, loads a config file, creates a hierarchy of objects (background, sounds, menu options, &c).

When the game itself starts, it will do likewise: load a config and create objects.

Obviously, I'd like to clear out all the resources that the main menu loaded (objects, images, input definitions, and so on) before bringing up the game itself.

Is there any preferred method of doing so, or some sort of "best practices"? Or should I just call orxObject_Delete() on the root object in the main menu?

Comments

  • edited August 2010
    First of all, if I were you I'd load all my config files at start, this way all your inputs are defined for both "scenes".

    Then, everything that you don't create explicitly will be automatically freed when not needed anymore. If you only create one object as your hierarchy root, you simply need to delete that object so that all related resources are freed (including sounds, FXs, shaders, textures, etc...) unless stated otherwise (see the KeepInCache config property for some structures).

    When you have deleted your menu scene hierarchy, you simply need to select the new input set using orxInput_SelectSet() as everything would already have been loaded in the config module.
    If you'd still want to load the new input definitions now rather than earlier, it's of course doable.

    So yes, a simple orxObject_Delete() is enough.
    However, if you're calling this from an event callback, it's safer to use orxObject_SetLifeTime(orxFLOAT_0) instead and will produce a very similar result (with the difference of all resources being freed during the update loop instead than directly from the event callback, which would be unsafe).

    NB: The C++ layer Scroll (which adds the map concept + embedded level editor, a C++ interface and easier object handling) built on top of Orx contains a system to prevent wild resource deletion from callbacks but orx itself doesn't.
  • edited August 2010
    Interesting, I didn't think about loading all the config files up-front. I'm still quite new to the API, and pretty much only working from Grey's tutorials (which are excellent, but there's only so many); might take a while to learn the "natural" Orx way of doing things.

    Once again, thanks for the thorough response.
  • edited August 2010
    My pleasure.

    As for the tutorials, there's also the ones I wrote, although not as good as Grey ones, that showcases very specific aspects of orx.

    As for the "natural" way of doing things with orx, I've recently learned that some people don't like the config system and rather stick with a more traditional approach of doing everything manually in the code.
    It's doable with orx and perfectly fine, but it's just not what I'm interested the most as I'd like an engine to do as much work on his side so as to reduce my own work load.

    So it just boils down to personal taste and you can use orx as you see fit. I personnally like to have a bunch of config files, all specialized in one domain (UI, object, character, etc...) and include them using the @include.ini@ operator.
    Config values can also be provided at runtime by code, which is a good way of automating config parameters which would have been tedious to write manually, till a config file editor arises, of course. :)
  • edited August 2010
    Yeah, I'm liking the config system myself right now. Just tell the engine where to find everything, and load it on demand. I've tried a few different APIs before (including coding one myself) and Orx seems to be hitting just the right spot of having a good, flexible, well-documented and well-structured C API, and taking care of a lot of things on its own behind the scenes. As I say, I'm new to it, but I'm liking it a lot so far.

    I'm also basically wrapping a ton of the C functions to be called from Lua. Maybe when I get more used to Orx in general, I'll see about making a Lua plugin...
  • edited August 2010
    I'm glad you appreciate the config system as it is, I learned to like it a lot. But I've been recently told that some people really don't like it as they find it more error prone without an editor.

    A wrapper written in LUA would be a nice addition to orx! :D
    I've considered doind an AngelScript one but I lacked the time to.
  • edited August 2010
    I've made a related observation, maybe you can verify it.

    When a parent is created with children through a config file, calling orxObject_Delete(parent) does indeed delete all the associated children as well (as I did with my root MainMenu object).

    However, I've also been creating a few objects in code, and attaching them to another root object, say LevelRoot, with orxObject_SetParent(newObject, LevelRoot). I can scale the LevelRoot object, and all the child objects are scaled accordingly, but it seems that when I call orxObject_Delete(LevelRoot), the child objects are *not* deleted.

    I think I saw some wording to that effect in the Orx API docs. Is that the case? It's not a problem---I can keep track of the child objects and delete them individually if necessary. I just want to make sure I understand how the code's working.
  • edited August 2010
    That's totally right.

    In the first case, you manually created the root only and other objects were created automatically by orx, so their deletion is orx's responsibility.

    Whereas in the second case, you created all of them, so you are responsible for deleting all of them when you see fit. The parenting only transfer position/rotation/scale to children, nothing more.

    In the same order of idea, if you separately create an object and a graphic, for example, and bind them in code, deleting the object won't delete the graphic, it will still be your responsibility.

    There's a trick to get an automated deletion if you really need it though, it's by using the orxObject_SetOwner() function, just be sure of what you're doing as it's also used internally with spawners (spawned objects have the spawner as owner, that's how the spawner can keep track of the counts).
    I don't personally recommend it as it breaks the create/delete symmetry, it was just FYI so you know it exists and you can use it at your own risk. ;)
  • edited August 2010
    Cool, thanks. That does make sense.
  • edited September 2010
    Aaand to continue the thread...

    Basically, I have a whole bunch of background terrain "tiles," and when I regenerate a scene (levels are generated randomly) I remove all the old terrain tiles with orxObject_SetLifeTime(). However, I'm noticing that it seems to be randomly throwing this assertion fail:
    [Assertion failed] : <(((orxSTRUCTURE *)(_pstObject))->eID ^ orxSTRUCTURE_MAGIC_TAG_ACTIVE) < orxSTRUCTURE_ID_NUMBER>
    

    I can't really decipher that message myself. Any idea what kind of problem it could be pointing to?

    Thanks again for the continued help.
  • edited September 2010
    Sorry for the delay, as I stated in another post, I'm currently preparing to move to the US so I might not be as reactive as usual for the next couple of weeks.

    As for the message, it means some code is trying to access a structure that has been deleted. =)

    The TAG_ACTIVE is used for validating an object and track illegal access to freed structures.

    The easiest way to see what's happening is to break on this assert and look at the callstack.

    There's probably some way you're accessing already deleted structures (such as children or related).

    If you don't find it, just mail me the archive, I'll look into it!
Sign In or Register to comment.