System Timer32

[chobibo]

"haha you're wrong"

Actually what I wanted t say was "that's wrong, please change that.", I'm glad you didn't take that offensively.

About 1.03, you switching to a linked list?

 

[Jesus4Lyf]

Yep.

Reason is instead of i=i-1, fire Data you have set i=Next, fire i. Removes the subtraction. It also makes the firing order more consistent, which is kind of neat.

Kinda makes this unique too, y'know?

(PS. The realisation that this would be faster actually came from looking at kenny!'s code a while back. Funny stuff... so thanks kenny!, I guess. )

 

[Kenny]

Wow... lol. Thats all.

Clever, using: thistype(0). Quite clever.

 

[Jesus4Lyf]

>Clever, using: thistype(0). Quite clever.
It's like using a pointer, but not! But it is. (Beats the hell out of that First var thing, which then needs if statements to set it... *shudders*)

 

[Joker(Div)]

What does thistype(0) do?

 

[kingkingyyk3]

Struct index is always starting from 1. thistype(0) is struct #0, it is not used in default.

 

[Kenny]

Struct index is always starting from 1. thistype(0) is struct #0, it is not used in default.

That doesn't really explain what using thistype(0) does...

Using thistype(0) is like having a head node pointer, without it actually existing in the list. It removes the need to set a value to the head (start) of the list, which in turn makes it a little faster.

So thistype(0).next will be referring to the first instance of a real value in the list.

(Please correct me if I am wrong )

 

[Jesus4Lyf]

Normally, when removing a node:

if this.prev==0 then // We must be removing the first node.
    set First=this.next // or "set First=First.next"
else
    set this.prev.next=this.next
endif
set this.next.prev=this.prev

Now, of course note that this could be the last element in the list. Usually I throw away the unlinking commands to the "0" node (the last element will have a "next" of 0). So for the last element, "set this.next.prev=this.prev" would be setting "thistype(0).prev=this.prev". 0 functions as null basically, so it more or less throws away the command, just saving an "if this.next!=0 then" command.

I realised that I'm throwing it away in a consistent manner. thistype(0).prev will always be the last node in the chain. Likewise, you can "throw away" the next value to the 0 node. So instead of having a "First" global, you just use thistype(0).next, and instead of a last, thistype(0).prev (which I don't need, though). So this saves a global var, and an "if" clause on removal.

Come to think of it, kenny!'s linked list module can probably be updated to use the same principle, as I deliberately picked "first" as "next" and "last" as "prev" and reused the fields.

Hope that explains or utterly confuses. :thup:

(So to answer things more directly, both the above answers are right, and...
>What does thistype(0) do?
It simply returns the "null" struct, which actually can contain and store values. For once, ignoring typesafety has improved efficiency... (kenny!, think of thistype(0) as my list struct...))

Good to see thoughtful questions and responses (+rep).

 

[RaiJin]

private static method PeriodicLoop takes nothing returns boolean
            local thistype this=thistype(0).next
            loop
                exitwhen this==0
                if this.periodic() then
                    // This is some real magic.
                    set this.prev.next=this.next//Im guessing this is the thing that stops timer from calling .periodic()?
                    set this.next.prev=this.prev//whats this do aswell?
                    // This will even work for the starting element.
                endif
                set this=this.next//why are you setting this=this.next?
            endloop
            return false
        endmethod

        method startPeriodic takes nothing returns nothing
            set thistype(0).next.prev=this //???why are you setting all these stuff
            set this.next=thistype(0).next
            set thistype(0).next=this
            set this.prev=thistype(0)
        endmethod

lol sorry, but i am fascinated and is there anyway you can explain this in simple terms? (or else ill get lost xD) and how is everything happening

 

[Jesus4Lyf]

Think of "thistype(0).next" as "First", and "thistype(0)" as "null".
So you have a list of objects, each knows its "next" and "prev"ious object.

So

            set thistype(0).next.prev=this //???why are you setting all these stuff
            set this.next=thistype(0).next
            set thistype(0).next=this
            set this.prev=thistype(0)

Becomes...

• Set the object before First to this.
• Set this's next object to First. (Completes the link in attaching this BEHIND First.)
• Set First to this (First is a pointer pointing to the first object). So now we have successfully changed the First object to "this" and shifted the rest of the list forwards.
• Set this's previous object to null (because it should have nothing behind it).

Hope that helps. Feel free to question more.

(I just thought here was better than in visitor messages so people can learn if they so desire. :thup

I'll explain the rest when I get some more time if I still need to. Let me know if that much makes sense to you yet.

 

[RaiJin]

i really appreciate you explaining all this, honestly appreciate this a lot,

Let me get this straight, so we have 3 things

Previous, Present, Next ?? and were trying to set it up so we know whats going to be next and what's going to be behind that?

what really confuses is this because i havn't seen much of it before

set thistype(0).next.prev=this

 

[Jesus4Lyf]

You seem to be following. For a visual, to help...

Linked list (as a whole):
+--------------+-------------------+------------------------+--------------------------...
|thistype First|thistype First.next|thistype First.next.next|thistype First.next.next.next
+--------------+-------------------+------------------------+--------------------------...
Until .next is equal to 0 (null, or in other words, no more structs left).
(Hence exitwhen this==0)

For each single struct, to make this chain effect, we know:
+------------------+------------------+------------------+ <-- Your struct.
|thistype this.prev|"THIS" STRUCT HERE|thistype this.next|
+------------------+------------------+------------------+

So yes, we know previous and next.

So for any "this" struct, if we wanted to remove it from the list, we say... well, we need the next to think it's previous is this.prev, and the previous to think it's next is this.next. That will simply cut me out of the list!

So we say this.next.prev=this.prev and this.prev.next=this.next.

Now, what about when we're using the first element? .prev will be 0...

+----------------------------------+------------------+------------------+ <-- "First".
|thistype this.prev (==thistype(0))|"THIS" STRUCT HERE|thistype this.next|
+----------------------------------+------------------+------------------+

(Remember that in structs, thistype(0) is effectively the null struct - which yes, can store data.)
So when I say this.prev.next=this.next as part of removing this element, it will set thistype(0).next to the first element. Well, usually when we write linked list stuff on TH this gets thrown away - it's more efficient to just write to null.next than to say "if not first, set .prev.next=.next". But why not use it? We can make thistype(0).next reliably hold the "First" struct.

So when adding a new struct, in T32, I add it to the start of the list (start or end, doesn't matter... I might even change it). But currently it is the start.

So we say this.next=thistype(0).next (set this.next to the First...

this|whatUsedToBeFirst(andDoesn'tKnowThere'sSomethingBeforeItStill)|whateverElseIsInTheList

And, just before that, the line you asked about: set thistype(0).next.prev=this
Which, of course, lets that "First" element know there is something now behind it.
(Because thistype(0).next is "First".)

Why do I have to let it know there is something behind it? Because if I didn't when I remove that node, it will need to tell its PREVIOUS node what its new next node is, remember? Which would result in failing, and not remove the node.

Basically: In doubly linked lists like this, every action has an equal and opposite reaction. If you set something's "next" node, you must also set that "next" node's "previous" node too... So both sides know about the link. Likewise, if you set node A's "previous" node to B, you must set node B's "next" node to A.

(I don't necessarily do one or the other first, efficiency can vary mildly with which you choose to do first.)

Feel free to ask more or tell me I made no sense. Education is good. :thup:

 

[Viikuna]

Structs do make this kind of linked lists stuff work pretty nicely.

 

[kingkingyyk3]

The tutorial has confused me. :nuts: Never mind.

KT2 has similar stuff, is it?

 

[Jesus4Lyf]

Yeah, to keep the data list the same as the triggerconditions on the triggers. I actually had to use linked lists for that.

Except I wrote those without structs.

 

[Tom Jones]

You could trow out

set this.prev = thistype(0)

if you assign 0 to prev when you declare it. And maybe for the sake of readabilty change

            set thistype(0).next.prev=this
set this.next=thistype(0).next

to

            set this.next=thistype(0).next
set this.next.prev = this

?

I saw the benchmarks, pretty amazing results, did you make them with japi stopwatches?

And lastly, why T32? Pretty vague name

*Edit*

//           Put "implement T32" BELOW this method.

Why?

 

[Tyrande_ma3x]

> Why?
It will use trigger evaluate instead.

 

[Jesus4Lyf]

>You could trow out "set this.prev = thistype(0)" if you assign 0 to prev when you declare it.
For the sake of readability, I'll keep it there. Actually, changing it would break it if people stopped a struct and then added it again, and declaring an initial value just does a set command on allocate anyway, so there is no efficiency difference.

>And maybe for the sake of readabilty change ... to ... ?
For the sake of efficiency, I'll keep it like that. (Using 0 instead of "this", it's constant, no var read.) I actually already thought about that one.

>why T32? Pretty vague name
Timer32. A single timer to execute 32 times a second.

>"Put "implement T32" BELOW this method." Why?
Tyrande_ma3x is right. We magically find out that it doesn't matter what order methods are in in a struct. What we don't find out is if they're in the wrong order, it uses triggerevaluate. (And of course this is pointless if it doesn't have speed.)

 

[Tyrande_ma3x]

I was wondering if this is going to cause any performance issues (fps) if I have, say, around 30-40 active struct instances in use with this. My current search is to find something that can handle such a number of low frequency calls without a huge amount of performance loss as in concern of the user/player.

 

[uberfoop]

TBH, just about any timer system can handle 30-40 active instances without serious performance issues.

But like J4L has said, this system is extremely light on your computer. It is more limited than some systems (read the pros and cons section of the documentation) but yes, it's extremely light.


But like I said, 30-40 instances should be fine with just about anything. Even something incredibly stupid like this could probably manage it without issue:

Spoiler

library AWESOME
globals
    private timer array TA
    private integer array IA
    private integer array TD
    private integer size = 0
endglobals

function GetTimerIndex takes timer t returns integer
    local integer use = 0
    local boolean b = false
    loop
        exitwhen b == true
        if t == TA[use] then
            set b = true
        endif
        set use = use + 1
    endloop
    return use - 1
endfunction

function SetTimerData takes timer t, integer i returns nothing
    local integer use = 0
    local boolean b = false
    loop
        exitwhen b == true
        if t == TA[use] then
            set b = true
        endif
        set use = use + 1
    endloop
    set TD[use - 1] = i
endfunction

function GetTimerData takes timer t returns integer
    local integer use = 0
    local boolean b = false
    loop
        exitwhen b == true
        if t == TA[use] then
            set b = true
        endif
        set use = use + 1
    endloop
    return TD[use - 1]
endfunction

function ReleaseTimer takes timer t returns nothing
    local integer use = 0
    local boolean b = false
    loop
        exitwhen b == true
        if t == TA[use] then
            set b = true
        endif
        set use = use + 1
    endloop
    set IA[use - 1] = 0
endfunction

function NewTimer takes nothing returns timer
    local integer use = -1
    local boolean b = false
    loop
        set use = use + 1
        if IA[use] == 0 then
            set b = true
        endif
        exitwhen use == size or b == true
    endloop
    if use == size then
        set TA[use] = CreateTimer()
        set size = size + 1
    endif
    set IA[use] = 1
    return TA[use]   
endfunction
endlibrary