MagicTimers ...

11-24-2007, 08:50 PM

So, I was bored so I decided to actually materialize this idea, it is basically timelib but exploiting new ideas I got after adding implementation inheritance.

http://www.wc3campaigns.net/pastebin...29b056bb4f49c6

I think I like the result and I think that in a pararel world their usage would be considered intuitive... Of course since most people don't even know what 'extends' is this is probably the hardest to use thing ever.

A sample:

JASS:

library test initializer init requires MagicTimer

    struct myMessageTimer extends MagicTimer
        string message="nil"

        method onExpire takes nothing returns nothing
            call BJDebugMsg(this.message)
        endmethod

    endstruct

    private function init takes nothing returns nothing
     local myMessageTimer t=myMessageTimer.create()

        set t.message="Hello world"
        call t.start(0.25,true)
        call TriggerSleepAction(20.0)
        call t.destroy()

    endfunction


endlibrary

So, they are isomorphic to your usual native timer object, the difference is that you can extend them and add fields and the timeout code is integrated to the custom struct based on MagicTimer...

Speed? Besides of the normal timer behaviour it requires a TriggerEvaluate + log_2(NumberOfMagicTimersInGame) * C ops where C is some constant factor, probably a bunch of if and array assigns, etc.

It does no attaching and it only uses 2 native timers for everything.

You need latest jasshelper (0.9.9.5) to make them work correctly, their development allowed me to find some more bugs with onDestroy that I just fixed.

11-24-2007, 09:08 PM	#2
cohadar	Let me just test this a little, brb with bashing in a sec...

11-24-2007, 09:11 PM	#3
grim001	how about onExpire returns boolean, true = repeat, false = stop and destroy struct instance.

11-24-2007, 09:14 PM	#4
HINDYhat	Heh, this is nice.

11-24-2007, 09:15 PM

Vexorian

Quote:

how about onExpire returns boolean, true = repeat, false = stop and destroy struct instance.

Then we'll have something as lame as timelib.

You can call .destroy , .start or .pause from onExpire.

11-24-2007, 09:27 PM	#6
grim001	anyway looks cool... adds another way to approach dealing with timers+structs.

11-24-2007, 09:32 PM

cohadar

JASS:

scope Test

    struct myMessageTimer extends MagicTimer
        string message="nil"

        method onExpire takes nothing returns nothing
            call BJDebugMsg(this.message)
            call .destroy()
        endmethod

    endstruct


private function Actions takes nothing returns nothing
    local myMessageTimer t=myMessageTimer.create()
    set t.message="Hello world"
    call t.start(2.,false)
endfunction

//===========================================================================
public function InitTrig takes nothing returns nothing
    local trigger trig = CreateTrigger()
    call TriggerRegisterPlayerEventEndCinematic( trig, Player(0) )    
    call TriggerAddAction( trig, function Actions )
endfunction

endscope

It works...
and is object oriented, really nice.

But like you said it would take a parallel universe...

11-25-2007, 01:19 AM

Vexorian

I did a minor update to the pastebin link, pause() now actually works in onExpire when the timer is periodic, and since pause() was quite worthless without resume() I added resume() , I removed isPaused and added isRunning().

Anyways I like it, and I think that once I execute the plan I have to cripple the TriggerEvaluate usage this will get very fast, although even with TriggerEvaluate it is going decently fast .

11-25-2007, 01:58 AM	#9
Malf	That is just sweet. I just realized I no longer have to use a global struct array with one timer that loops through, omglololdota this is hottt.

11-25-2007, 04:59 AM

#10

grim001

Quote:

Originally Posted by Malf

That is just sweet.

I just realized I no longer have to use a global struct array with one timer that loops through, omglololdota this is hottt.

You never had to do it that way unless you cared about speed... and you still need to do it that way if you care about speed...

11-25-2007, 07:58 AM

#11

cohadar

Quote:

Originally Posted by Vexorian

Anyways I like it, and I think that once I execute the plan I have to cripple the TriggerEvaluate usage ...

What does this mean?

11-25-2007, 01:16 PM

#12

Vexorian

Quote:

Originally Posted by grim001

You never had to do it that way unless you cared about speed... and you still need to do it that way if you care about speed...

Could make a version for such animation related timers.

In snow and and hazards I had like 100 triggerevaluates each 0.025 seconds and it didn't lag, well it did lag in the last level but it was due to the crazy special effect usage.

I don't think speed is the best reason for such loops I like not having to care about attaching things to timers or recycling timers much more.

Still I want to add some syntax that would make the whole timer 0.04 seconds loop automatically without much typing, no, not a syntax specific to it but one that would allow it.

Right now a text macro works but, textmacros are awful and they don't respect scopes.

Quote:

What does this mean?

There are ways to at least reduce the usage of TriggerEvaluate, just requires some more complicated compiling.

Edit: Using this for 0.04 seconds timers is not a great idea, just like doing multiple 0.04 seconds normal timers is not nice either. I think I could do something to prevent the performance hit when there are too many frequent, periodic timers... hmm.

Edit II: Made some tests and it looks like it can barely survive 200 simultaneous [0.04 seconds] magic timers without harming fps (These timers only increased one value periodically and nothing else)

11-25-2007, 02:14 PM	#13
zen87	interesting idea O_o, with this i can actually skip the part of using timerlib and just use this instead with my effect system! make it happen vex :D

11-25-2007, 02:20 PM

#14

emjlr3

Quote:

//this is yet another TriggerEvaluate() inlining the monster bellow would probably have been an optimization
//but the periodic option is intended mostly to be used by long timeout timers, since for the most periodic
//ones it is better/easier not to use this magic timer system

:(, those are 99% of my needs

11-25-2007, 02:35 PM

#15

Vexorian

Those ultra periodic cases function well with just an array. I am right now making an "AnimationTimers" class that works like this one but is intended for those quick ones. Let's see how performance is improved...

Edit: looks like AnimationTimers can survive with 700 instances of them. (not doing anything besides of increasing the value of a variable) Can't think of a situation in which you need more than 100 of those timers though.