• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

One Timer System

spam timers in multiple structs until fps goes down. Be sure to constantly add/remove timers. State which has higher fps.

Another way is to examine the operations of both. Which one does more operations?


I'll give you a hint. I can tell you right now that your resource is way freaking harder to use than CTL or T32. As for as usability is concerned, yours gets a 2/10, lol.
 
Look at the demo code

JASS:
    *    module CTL
    *
    *       Allows creation/destruction of timers in a struct. Provides instancing of those timers.
    *
    *       -   static method create takes nothing returns thistype
    *       -   method destroy takes nothing returns nothing
    *
    *       CTL (optional)
    *           local variables, code before running any timers
    *       CTLExpire (not optional)
    *           timer code
    *       CTLNull (optional)
    *           null any locals, runs after all timers
    *       CTLEnd (not optional)
 
OneTimer

Performance: 8 (use of indexed array makes iteration slower. Use of trigger timer event makes code execution slower. The creation/destruction is a *tiny* bit faster than a linked list)
Ease of Use: 1 (you put it on the user to create indexed array)
Learnability: 1 (you put it on the user to create indexed array)
Code Generation: 1 (resulting code from indexed array + creation + destruction + struct allocation + struct deallocation + timer initialization + globals)
Reliability: 4 (because your stuff gets out of order due to indexed array)
Functionality: 1 (I shouldn't have to explain why this got a 1 here. If I could give it -50, I would.)

Final Score: 2.6


CTL

Performance: 9 (the only thing faster is using an array)
Ease of Use: 9 (doc'd for strange use of module)
Learnability: 8 (doc'd for strange use of module)
Code Generation: 10 (just about all code located within library, not module, if I could give it +15, I would)
Reliability: 10 (highly reliable due to use of recycler and maintaining order)
Functionality: 10 (contains both struct and single timers)

Final Score: 9.3

T32x

Performance: 7 (callback makes this slower)
Ease of Use: 10 (perfect)
Learnability: 10 (if I could give this +15, I would)
Code Generation: 7 (spams arrays and puts behavior in module, but still very little code)
Reliability: 7 (because it can bug up in one situation)
Functionality: 7 (missing single timers, always requires a struct)

Finale Score: 8

The best scores you an hope for are CTL/T32x, so I vote for rejection.

edit
if you're seriously going to argue these scores.. compare -.-

JASS:
    struct CTL_Test extends array
        implement CTLExpire
        implement CTLEnd
    endstruct

JASS:
    struct T32x_Test extends array
        private method periodic takes nothing returns nothing
        endmethod

        implement T32x
    endstruct

JASS:
library Test requires OTimer
    globals
        private OneTimer a
        private integer M = 0
        private integer array StructData
    endglobals

    private module Init
        private static method onInit takes nothing returns nothing
            call init()
        endmethod
    endmodule
    
    private struct test
        private method destroyData takes nothing returns nothing
            set StructData[i] = StructData[M]
            set StructData[M] = -1
            set M = M - 1
            call a.recycleData(M)
            call destroy()
        endmethod
        
        static method onPeriodic takes nothing returns boolean
            local thistype this
            local integer i = 1

            loop
                exitwhen i > M
                set this = StructData[i]
                set i = i + 1
            endloop

            return false
        endmethod
        
        static method create takes nothing returns nothing
            local thistype this = allocate()

            set M = M + 1
            set StructData[M] = this

            if not a.havedata then
                set a.addPeriodic = function thistype.onPeriodic
            endif
        endmethod
        
        private static method init takes nothing returns nothing
            set a = OneTimer.create()
        endmethod

        implement Init
    endstruct
endlibrary
 
Last edited:
Okay, but i don't get it 0.0, i can't test those code you share, and i think OneTimer only use when struct create and use it, and you said:

spam timers in multiple structs until fps goes down. Be sure to constantly add/remove timers. State which has higher fps.

I don't see anything about add/remove here.

JASS:
library test15 requires CTL
    struct test15
        implement CTLExpire
            call this.destroy()
    //--------------------------------------
        implement CTLEnd
        static method onCast takes nothing returns nothing
            local thistype this = create()
        endmethod
    endstruct
endlibrary

This code is correct ? right, after test it (though 15 struct, 4 period trigger call back), it causes laggy on my PC and OneTimer work perfectly fine.

Anyway:

Nothing to say with your score, i'll improve and compare with you again. I will never give up until defeat the CTL, yes, i will..

P/s: Oh my, you can delete it, reject it whatever you want (I hope this topic will be deleted)
 
Last edited:
This code is correct ? right, after test it (though 15 struct, 4 period trigger call back), it causes laggy on my PC and OneTimer work perfectly fine.

You got those results because you were overflowing. I did a test across 30 structs with 32400 timers and it ran at 64 fps. So did yours. However, yours had the issue of improper code order and what not >.>. Yours also had the usability issues, the learnability issues, and the list goes on. However, CTL did flash a bit because I had to cnp the entire library 4 times, meaning that it did take a performance hit, so it wasn't a true benchmark. If it could handle more than 8191 instances, it wouldn't have been flashing to 63 every once and awhile like it was.


I believe the scores I gave were fair. I fairly benched yours and mine against each other under the same conditions. I've already benched T32x in the past. For functionality etc, I listed reasons. I also provided demo code. Although yours beat CTL in the benchmark, if it was a true benchmark, that is CTL didn't have to be cnp'd, it wouldn't have because your iteration is actually slower (you have a couple of extra operations) and your code execution is slower (you do a trigger timer event instead of a trigger evaluation inside of a timer, and the former was proven to be slower in a benchmark many years ago, which is why T32x, CTL, and so on evaluate triggers inside of a timer).

I just get the feeling that you feel like you are being slighted here simply because CTL was approved first. This is not the case. If you fix all of your issues, you'll end up with a list, a recycler, a single timer, and you'll only be able to handle 8191 instances, which is exactly how CTL is. If you go the other route for ease of use, you'll have a clone of T32x. No matter what you do, you're going to clone either CTL or T32x, there are no other paths >.<.


My benchmark did have add/remove. I performed my own benchmark because your results seemed whacked.


Now, if you believe that a score was unfairly given or you believe that CTL is being unfairly promoted, please say so and why. In my own benchmark, I proved that CTL was marginally faster than OneTimer. Yours is a bad benchmark because you didn't cnp CTL 4x to account for overflow (using values > 8191 for the array reads). I proved that CTL and T32x are much easier to use than OneTimer by showing the demo code side by side of each resource. OneTimer was by far the most complex to use, the hardest to learn, and generated the most code (the user had to write more code than what was in the T32x or CTL modules). I'm trying to be very fair and objective here. I freely trash my own systems as well when I see problems in them, I am being as hard on you as I regularly am on myself.


I wanna see more resources from you in the JASS section, I really do. Just because this one failed doesn't mean that others will. I just want you to know that everyone is here to help you =).


If you want safe bets, here is a list of systems that have yet to be coded

http://www.hiveworkshop.com/forums/jass-resources-412/resources-have-yet-coded-239105/

If not, I'm sure that there are many other things that are useful that have yet to be done. I've yet to figure out how to solve the memory problem in BooleanExpression myself.
 
Top