Hey there everyone,
I've been working on encapsulating some allegro functions. Though I do have some experience with programming, I'm not as confident as I'd like to be. that being said I'm looking for some opinions on what I have for my timer class. I wrote the member function definitions in the class's header file because it's functions are pretty short and sweet, and I don't plan on changing them much. I'd like to keep all of the smaller components as concise as possible.
Essentially, I plan to glue instances of this class together with other components to create new objects with a common "entity" interface, with the "tick" function being called in it's parent object's update function.
I was just going to add the ticker to an event queue, but I wanted to keep it as independent as possible.
Here's an example of how I was planning on using it as a countdown timer:
I personally think it will work quite well, but then again this is my first attempt with the Allegro library, and I am using it to sort of expand my horizons. I suppose my primary concern is any leaks I may have missed, as well as any performance related issues I didn't consider. I was also wondering if there was a way to allow an instance of this class to be created and then added to a specified event queue without giving it an event queue argument? I doubt it, but I would appreciate any suggestions for possible solutions.
Also, I'd like to take a second to thank Schyfis and furinkan for their feedback on my previous thread. Although I didn't have time to post it earlier before the topic was locked, I really appreciate your feedback. The suggestions you guys offered gave me a lot of ideas for approaches to solving the aforementioned problems.
That's not the best way to use an ALLEGRO_TIMER. You're polling it constantly, which will use 100% cpu every time you do so. Use an event queue and wait for a timer event. That way the cpu can sleep, and your prog won't do anything until it gets a timer event.
What if instances of this class were only used within an entity's update function, which is only called after a global FPS timer event?
Then would it be appropriate to use?
My problem is that entities might not always have a reference to the event queue. Unless its beneficial to somehow have more then one?
Entities in your program shouldn't have any idea what an event queue is nor have access to one. Pipe the events from the queue to your entities in a HandleEvent function or similar or use an Update function that you call when you receive a timer event. Register your timer with an outside event queue and then monitor that queue for events, dispatching them to your engine / entities from there.