Clock Unregister issue

edited November 2011 in Help request
Hello everybody,

Newcomer here... I have been on the look for a 2D engine for a while (I have experience with 2D and 3D programming). Orx caught my attention and I am now giving it a try for a game.

Anyway, I have a bit of an issue with the way orxClock registers and unregisters callbacks.

Say I have an array of objects that I want to process with a certain frequency... Then I use orxClock_Register with the same function (say, Update), but different context, right? Later, when handling an event in Update, I want to stop handling events for this object only... I could use orxClock_Unregister, but that doesn't take the context, and therefore it only appears to remove callbacks in the order they were given.

Now, I know that I could code something to handle this problem myself, but I was wondering if there is a more elegant way to do this.



  • edited November 2011

    Well, actually clock-registered function are intended for you to be able to specify/customize your own game loop if need be, not really to be registered on a per object basis.

    If you want to have an Update function for your objects, I suggest to only register your Update function once, and inside it traverse your object collection and process them the way you want.

    You can either maintain your own list of objects of use the orxStructure API (orxStructure_GetFirst()/orxStructure_GetNext()) to go through all the existing objects and use your own custom test to considerate only some (either by checking their name, a config property by pushing the config section matching the object's ame or even your own class/structure that you attach to them).

    If you need extraordinary processing/timing, you can use timers (also in the orxClock API). They work pretty much in the same way as callbacks but allows more options, including fire&forget strategies.

    Lastly, you can have a look at Scroll/ScrollED. It's a C++ thin layer written on top of orx that adds a few convenient wrappers as well as the concept of levels and an embedded level editor. If you look at that thread, you can get a recent version of it that comes with a small game I wrote 2 years ago, called Mushroom Stew:
    I'll try to post some info on how Scroll works on that thread tonight.

    Oh btw, if your objective was to do time stretching on objects, you can bind clocks to them in directly in config. Any time stretching done on those clocks will directly affect the objects (including physics and sound pitch). You can also retrieve the clock bound to an object in code and look at its properties if it's of any use for you. That's how I implemented the bullet time localized effect in Mushroom Stew.

    If my explanations aren't clear, don't hesitate to ask further questions!
  • edited November 2011
    Thanks for the response... Yes, I suspected as much. I was just wondering if there was such a "remove" function. Anyway... I have made a work-around (using a list of all the objects I want to process) as you suggested.

    I have also checked MushroomStew and I think it is very good and enjoyable... Played it until I beat it! Definitely a good source of teaching materials. By the way, I saw in the assets that there is a DragonLady character, but it is not part of the game. What happened? Did you end up not using that boss?
  • edited November 2011
    Thanks for your appreciation! It's a bit buggy as a result of being updated to a version of orx/scroll that have evolved over the past 2 years, but I'll try to clean that soon.

    Yes there are a few unused assets, I started with the DragonLady as the playable character as she was the one that was the most visually advanced of all the available resources for the compo. She's not a boss but you can play with her, except she only had melee attacks and, being a bad designers, I wasn't sure how to use that in the game.
    Btw, all the characters in game can be either AI-controlled or controlled by the player. I added a very simple virtual interface to their actions. Those actions are linked directly to orxINPUTs in the case of a player character. In the case of AI, the "brain" simply activates those virtual actions instead of modifying the characters directly.
    This way you can easily debug characters by controlling them directly or add multiplayer and allow players to chose among all the available characters. The only exception is the end boss which is completely scripted and has no virtual interface.

    As for your collection of objects, if you use Scroll, you can traverse all the available objects on a per class basis.
    Scroll::GetNextObject() will go through all the ScrollObject-based objects whereas
    Scroll::GetNextObject<Type>() will only go through the objects of type Type.
    They're both as performant as I'm only using a single list and grouping objects based on their class for a better cache friendliness when updating them.

    As you've probably already found, ScrollObject gives a virtual Update() method if you want to do object processing without having to register your own clock callback for that purpose.
Sign In or Register to comment.