can we force millisecond accuracy animation frames using script?

[oldyz]

greetings , finally made some progress on some scripts, but now i am stuck on an issue:

i have this animation that in order to appear arcade accurate, the animation frames must run at 1.6667 centiseconds

anim special
    loop    1
    delay    1.667
    offset  124 124
    bbox    110 35 29 65

    #@script
    void self = getlocalvar("self");
    if(frame == 10){
    changeentityproperty(self, "aiflag", "attacking", 1);
    changeentityproperty(self, "aiflag", "idling", 0);
    changeentityproperty(self, "takeaction", "common_attack_proc");
    changeentityproperty(self, "animation", openborconstant("ANI_SPECIAL1"));
    }
    #@end_script

        frame data/chars/zombie/02 #0



        frame data/chars/zombie/01 #1

        frame data/chars/zombie/02 #2


        frame data/chars/zombie/01


    frame data/chars/zombie/02  #4

however the engine only works in centisecond accuracy, and for some of my other animationscript tricks,
running some animation frames at millisecond speeds would give the best results -

and altho the engine graphically does not seem to display an animation if i use
delay 0

i was wondering if at least the frames of animation using "delay 0" run at millisecond speeds...

(5 animation frames 5 milliseconds?)

the other option that could work, is for a script to use the "engine clock" to fill in those millisecond gaps after a command or script is executed -

 

[DCurrent]

i have this animation that in order to appear arcade accurate, the animation frames must run at 1.6667 centiseconds

That’s just 60 FPS - 1.6667 centiseconds is 16.667 milliseconds per frame, which matches a standard refresh rate, not an animation rate.

And no, you can’t really do that with native animations. Like most modern engines, OpenBOR sanitizes delays to a more human-readable scale — for example, a delay of 1 effectively becomes 2.

Also, arcade systems didn’t animate at 60 FPS. The screen refreshes at 60 Hz, yes, but sprite animations run much slower - often updating every 2, 4, or even 6 frames. The only time you’ll see per-frame animation at 60 FPS is during strobing effects, used to simulate fake transparency.

So no, your animation doesn’t need to be locked to 1.6667 cs to be "arcade accurate." That’s a misunderstanding of how arcade timing actually worked.

however the engine only works in centisecond accuracy, and for some of my other animationscript tricks,
running some animation frames at millisecond speeds would give the best results -

No - the engine doesn’t run on centisecond or even millisecond accuracy. Internally, it uses microseconds - that’s 1,000,000 units per second (as opposed to 1,000 for milliseconds or 100 for centiseconds).

That said, what you have access to at the scripting level (like elapsed_time) is based on an update tick, which is accurate to around 5 milliseconds. That’s roughly half a centisecond. Using update frame and elapsed time can get you 1.5 cs (15 ms). I could open the microsecond counters for making 1.6667, but you'd have to have a far more advanced understanding than your current level to make any use of it.

DC

 

[oldyz]

The only time you’ll see per-frame animation at 60 FPS is during strobing effects, used to simulate fake transparency.

that was my priority intention, to do 60fps to restore some effects to strobe/fake transparency -
specially the frankenstein battle monitor and the hospital level strobing of the lights and trees-
- maybe even christophers water counter too
a while back i shared a youtube video of a 60fps capture of them...
(and i had to rip the monitor frames using a direct capture of every frame with mame)

i tried using a sort of interlacing technique , ghosting of the frames too, but those monitors only look good using 60fps strobing

for example, a delay of 1 effectively becomes 2

i guess that will do for the trees and the monitors...

does the scripted fglayer animation technique allow for faster framerate for strobe effects?

That said, what you have access to at the scripting level (like elapsed_time) is based on an update tick, which is accurate to around 5 milliseconds. That’s roughly half a centisecond. Using update frame and elapsed time can get you 1.5 cs (15 ms). I could open the microsecond counters for making 1.6667, but you'd have to have a far more advanced understanding than your current level to make any use of it.

for the other trick i wanted to do, milliseconds where a must.
tho it is not a big deal since the adjustment can be made in another way so it matches on a centisecond scale.

update tick accuracy might be needed for another thing i have been trying to do, but i need to make a thread explaining what it is