hoot.lua (Handles-free Object Oriented Timer)

[farzher]

https://github.com/farzher/hoot-lua

Not sure if anyone will find this useful; considering how simple it was to make and the fact nobody made it yet, I assume it's not a programming style people care for. But I made it for myself and decided to share (:

Read the github for its description/usage (I put some effort into the github readme)

I just made it today, so if it's missing any features you think would be cool, just let me know.
Or if you think it's unnecessary/useless, you can tell me that too.

[Kingdaro]

The library should definitely allow timed events as opposed to frame-based events. Timing events in terms of frames is generally a bad idea, when taking differing computer speeds, vsync, and all that junk into consideration.

Basically, just let the library accept a time and a delta to update by. Also reduces the amount of math and head logic required for some things.

Code: Select all

function Enemy:knockdown()
  fme(self):set('is_down', 1) -- 1 second
end

function Enemy:update(dt)
  fme(self):update(dt)

  if fme(self):get('is_down') then print('Im down!') end
end

[farzher]

The library should definitely allow timed events as opposed to frame-based events. Timing events in terms of frames is generally a bad idea, when taking differing computer speeds, vsync, and all that junk into consideration.

I don't use dt. It's called "frame timer" for a reason. Maybe I should put at the top of the github "If you're using dt, don't use this"

If you're using real time, aren't there already nice timers out there? Or would extending this to accept dt still be ideal?

I don't know, I don't use dt because I'm working with frame perfect multiplayer games (like fighting games), where frames are what I want to use, and definitely not dt.

[adnzzzzZ]

Nice idea. I've been meaning to write something about "this kind of code" for a while and how you can fix it using timers and other mechanisms. But your idea of using frames instead seems valid too. And I like your interface, simple and gets the job done. Good job!

[Tesselode]

The library should definitely allow timed events as opposed to frame-based events. Timing events in terms of frames is generally a bad idea, when taking differing computer speeds, vsync, and all that junk into consideration.

Basically, just let the library accept a time and a delta to update by. Also reduces the amount of math and head logic required for some things.

Code: Select all

function Enemy:knockdown()
  fme(self):set('is_down', 1) -- 1 second
end

function Enemy:update(dt)
  fme(self):update(dt)

  if fme(self):get('is_down') then print('Im down!') end
end

Frame timing in this case (correct me if I'm wrong, farzher) isn't when you just don't use dt, frame timing is when all of your update events are run a certain number of times per second. So in your love.update, you would have something like this:

Code: Select all

function love.update(dt)
    updateTimer -= dt
    while updateTimer <= 0 then
        everythingElse:update()
        updateTimer += 1/60
    end
end

In this way, the game is still framerate independent, but you know the time that has passed between each update call for each object. This has a few benefits I can think of:

• You can measure times in gameplay in frames, so you could say "this is a frame perfect input" or "you're invulnerable for 5 frames," and people will know what you're talking about.
• You don't have to keep multiplying things by dt, which is convenient.
• You don't have to worry about extremely low framerates causing collision issues.

[farzher]

Frame timing in this case (correct me if I'm wrong, farzher) isn't when you just don't use dt, frame timing is when all of your update events are run a certain number of times per second. So in your love.update, you would have something like this:

Code: Select all

function love.update(dt)
    updateTimer -= dt
    while updateTimer <= 0 then
        everythingElse:update()
        updateTimer += 1/60
    end
end

In this way, the game is still framerate independent, but you know the time that has passed between each update call for each object. This has a few benefits I can think of:

• You can measure times in gameplay in frames, so you could say "this is a frame perfect input" or "you're invulnerable for 5 frames," and people will know what you're talking about.
• You don't have to keep multiplying things by dt, which is convenient.
• You don't have to worry about extremely low framerates causing collision issues.

Yeah. I personally override love.run to call love.update exactly 60 times per second (60fps lock), and it doesn't even pass dt to update

I've realized that the reason my timer library is cool is not because it's frame based, it's because it's a handles-free object oriented timer.
I see that most timer libraries return a handle that you have to keep track of if you want to later cancel or get/edit the timer.
Mine doesn't require that because of the fancy object oriented + key stuff I have going on.

It'll extend it to support dt, and rename it to hoot.lua (Handles-free Object Oriented Timer)
It should be good

[airstruck]

Nice, I like it. You could probably argue that the "key" is still a sort of handle, but it's still a good setup. It's not a "global" key, it's tied to the object, and you don't have to manage the scope of a returned handle.

[farzher]

Nice, I like it. You could probably argue that the "key" is still a sort of handle, but it's still a good setup. It's not a "global" key, it's tied to the object, and you don't have to manage the scope of a returned handle.

Right. It still has all the same flexibility that handles give you, but I think the thing that defines a handle is the fact you have to "hold on to it". Which you don't have to worry about at all here

[farzher]

This might be a fun challenge: If anyone has timer-related code that you think won't benefit from hoot, please share it!
(It'll help me design a better API)

[Tesselode]

This might be a fun challenge: If anyone has timer-related code that you think won't benefit from hoot, please share it!
(It'll help me design a better API)

I don't have specific code, but hoot wouldn't really work if you need to change the speed of or pause groups of timers. For example, I wouldn't be able to slow down or pause all of the timers in, say, the gameplay state, because the only way to group timers with hoot is by object. And also there aren't any functions for pausing a timer or updating a timer individually.