Toki Tori

2011-05-10 02:27:00 am

I love YaBB 1G - SP1!

Hi, I'm sure the game isn't very popular, and I'm not sure I want to finish this as they are about 96 levels :), the game is simple, apparently easy, although speedrunning it is strict on timings: every move has a time it takes after which you can input the next move, so if your timing is off you end losing milliseconds for simple moves or even whole seconds for moves that have a cool down.

The last three videos aren't speedruns but are on the playlist:

But anyway I post so that it can't be said that I didn't allow others to point improvements ;o

Thread title:

ralle32

2011-05-10 02:41:57 am

Ah, I remember playingh this, it's a really nice game. 96 levels means you got to remember a whole lot of things if going for SS (besides executing them at the exact moment which can be a problem in later levels). An IL table sure wouldn't be that hard to do. I don't know if this game involves any real speedtricks (solving the level in another way then it's supposed to) ?

does the game have a built-in timer ?

Anyway I would definitely watch the run

error1

Edit history:

error1: 2011-05-10 04:02:10 am

2011-05-10 03:25:37 am

Not a Zelda 2 refrence

ah yah the thing I like about this game is there are lots of unintended ways to finish levels
of the ones on that playlist there are different routs for test normal 3 and bonus 3, but I'm not sure if they are faster
there are also unintended tricks, for example with good timing you can teleport past an enemy, or walk in between them

error1

2011-05-10 04:18:03 am

Not a Zelda 2 refrence

yeah here are some tricks I was talking about

ralle32

2011-05-10 06:13:34 am

nice. looks like a possible speedrun of this would be even more watchable then.

gia

Edit history:

gia: 2011-05-10 11:41:23 am

gia: 2011-05-10 10:44:13 am

gia: 2011-05-10 10:40:05 am

gia: 2011-05-10 10:09:02 am

2011-05-10 10:08:34 am

I love YaBB 1G - SP1!

SS doesn't need to beat all the levels, I was thinking ILs to keep it easy, but with the practice maybe I could try SS too, memory wouldn't be a problem with me at least, just screwing up the timings and having to restart the whole thing

bonus 6 looks like its gonna take some to pull off Tongue

ill try the other way for normal 3 but it will be harder... maybe it allows me to skip the cycle I was missing to, nope, it IS way faster but still can't reach the spot to beat the level faster

Ok managed to do it, twice, however after checking the frames, the one that was slower visually is faster, the one that should have been faster is slower by 23 frames, which is a lot. After checking the video frame by frame, both start at the same time, and the monsters move in unison, however at certain points one of the movies starts gaining 1 frame advantage (in monster movement, which shouldn't be possible if the monsters have a constant speed value) and I assume this keeps going on for the remainder of the run, this happens even before I gain character control, while I'm teleporting in.

The game has a random element, the item thumbnails jump on screen on different order every time you start the level, but I don't know how this would affect the enemy movement. Unless the programmers have a single global decimal adder they use for all their "subpixel" positioning regardless of enemies or item thumbnails' movement.

So my only guess is that fraps drops frames depending on whatever load it had at the exact moment. Which means any run recorded with fraps will never be accurate without an ingame timer. And possibly that timer will be off too in certain cases. So what would it be, the run that is visibly faster or the one that has a lower frame number?

SS doesn't need to beat all the levels, I was thinking ILs to keep it easy, but with the practice maybe I could try SS too, memory wouldn't be a problem with me at least, just screwing up the timings and having to restart the whole thing

bonus 6 looks like its gonna take some to pull off :P

ill try the other way for normal 3 but it will be harder... maybe it allows me to skip the cycle I was missing to, nope, it IS way faster but still can't reach the spot to beat the level faster

Ok managed to do it, twice, however after checking the frames, the one that was slower visually is faster, the one that should have been faster is slower by 23 frames, which is a lot. After checking the video frame by frame, both start at the same time, and the monsters move in unison, however at certain points one of the movies starts gaining 1 frame advantage (in monster movement, which shouldn't be possible if the monsters have a constant speed value) and I assume this keeps going on for the remainder of the run, this happens even before I gain character control, while I'm teleporting in.

The game has a random element, the item thumbnails jump on screen on different order every time you start the level, but I don't know how this would affect the enemy movement. Unless the programmers have a single global decimal adder they use for all their "subpixel" positioning regardless of enemies or item thumbnails' movement.

So my only guess is that fraps drops frames depending on whatever load it had at the exact moment. Which means any run recorded with fraps will never be accurate without an ingame timer. And possibly that timer will be off too in certain cases. So what would it be, the run that is visibly faster or the one that has a lower frame number?

error1

2011-05-10 12:50:45 pm

Not a Zelda 2 refrence

It's weird though, fraps slows the game a lot for me. I don't think it has to do with the power of my computer or anything because toki tori isn't a demanding game, but there is a huge speed difference from playing with fraps and playing without it.

gia

Edit history:

gia: 2011-05-11 12:27:57 am

gia: 2011-05-11 12:27:36 am

gia: 2011-05-11 12:18:03 am

2011-05-10 01:06:46 pm

I love YaBB 1G - SP1!

well if your resolution is big the demand is on the hard drive, fraps trying to compress and write every frame to disk. I used to thik fraps hooked to the whatever "DirectX->DrawOnScreen()" call within the games so that it slowed down the game because you had to wait for every frame to be processed before resuming the game, but now I'm not sure anymore.

Ok, I figured out the videos have duplicate frames, the first video is 2352 frames long but has 376 duplicated frames, so if we take them out it has 1976 unique frames. The second video has a total of 2379 frames, 417 duplciates, 1962 uniques.

So the second video would be 14 frames faster which sort of coincides with what I thought I had improved the first one.

Now, without knowing how fraps or Toki Tori work, I assume fraps attempts to record video at 60fps realtime, if it can't grab the data on time it records a duplicate frame. In the meantime Toki Tori's code is frozen while writing to disk, that's why it or other games run slower. But the internal time variables have the time() value unaltered so issues may appear with objects teleporting because the game engine would still update the world on realtime. Unless fraps fixes this too, but no idea since Toki Tori is not that kind of game, it accepts the freezes without problems.

That leaves audio, the streams would be played and recorded on realtime, so if I remove the duplicated frames I'd either desynch the audio (if I don't drop the corresponding audio data) or drop audio data. Unless again, fraps fixes this by saving duplicate audio data as well, doubt it.

Assuming I am correct on everything, fraps videos' realtime timing would be frames minus duplicates, but while keeping all the frames on the final video to make the audio fit the video.

I used this Avisynth script to count the duplicates:

Code:

global dropped = -1
org = ConvertToYV12( my video here )
org_p = scriptclip(org, "Subtitle(" + chr(34) + " Total Dropped:" + chr(34) + " + string

(dropped), align=2)")
eq = Subtitle(org_p, "Same as previous:YES").frameevaluate("dropped=dropped+1", 

after_frame=true)
neq = Subtitle(org_p, "Same as previous:NO")
Conditionalfilter(org, eq, neq, "YDifferenceFromPrevious()", "<", "0.1")

You load it up and scroll through all the frames of the video in order (ie. play), then go back one frame to read the final number.

well if your resolution is big the demand is on the hard drive, fraps trying to compress and write every frame to disk. I used to thik fraps hooked to the whatever "DirectX->DrawOnScreen()" call within the games so that it slowed down the game because you had to wait for every frame to be processed before resuming the game, but now I'm not sure anymore.

Ok, I figured out the videos have duplicate frames, the first video is 2352 frames long but has 376 duplicated frames, so if we take them out it has 1976 unique frames. The second video has a total of 2379 frames, 417 duplciates, 1962 uniques.

So the second video would be 14 frames faster which sort of coincides with what I thought I had improved the first one.

Now, without knowing how fraps or Toki Tori work, I assume fraps attempts to record video at 60fps realtime, if it can't grab the data on time it records a duplicate frame. In the meantime Toki Tori's code is frozen while writing to disk, that's why it or other games run slower.  But the internal time variables have the time() value unaltered so issues may appear with objects teleporting because the game engine would still update the world on realtime. Unless fraps fixes this too, but no idea since Toki Tori is not that kind of game, it accepts the freezes without problems.

That leaves audio, the streams would be played and recorded on realtime, so if I remove the duplicated frames I'd either desynch the audio (if I don't drop the corresponding audio data) or drop audio data. Unless again, fraps fixes this by saving duplicate audio data as well, doubt it.

Assuming I am correct on everything, fraps videos' realtime timing would be frames minus duplicates, but while keeping all the frames on the final video to make the audio fit the video.

I used this Avisynth script to count the duplicates:
[code]global dropped = -1
org = ConvertToYV12( my video here )
org_p = scriptclip(org, "Subtitle(" + chr(34) + " Total Dropped:" + chr(34) + " + string

(dropped), align=2)")
eq = Subtitle(org_p, "Same as previous:YES").frameevaluate("dropped=dropped+1",

after_frame=true)
neq = Subtitle(org_p, "Same as previous:NO")
Conditionalfilter(org, eq, neq, "YDifferenceFromPrevious()", "<", "0.1")
[/code]
You load it up and scroll through all the frames of the video in order (ie. play), then go back one frame to read the final number.

error1

Edit history:

error1: 2011-05-11 12:31:18 am

2011-05-11 12:30:59 am

Not a Zelda 2 refrence

yeah editing the video that heavily is pretty suspect, and I don't think it would be allowed. I think it's pretty clear that toki tori doesn't give a consistent time when frapsed. For example setting it to record 30fps completely breaks it. It might be better to tell fraps not to sync audio and video and see what happens.

gia

2011-05-11 12:33:37 am

I love YaBB 1G - SP1!

If it happens here it should happen on every other game, I only noticed it here because the game is pretty simple and it was obvious I had done faster.

error1

2011-05-11 12:55:13 am

Not a Zelda 2 refrence

I don't think it's a problem with fraps, I think it's a problem with toki tori. Similar to how the speed of old dos games changed with cpu speed, I think toki tori speed is based on hardware, and any software based recording is going to slow it down

gia

Edit history:

gia: 2011-05-11 06:35:50 pm

gia: 2011-05-11 01:30:45 pm

gia: 2011-05-11 01:29:25 pm

gia: 2011-05-11 01:19:00 pm

gia: 2011-05-11 01:18:32 pm

gia: 2011-05-11 01:18:18 pm

gia: 2011-05-11 01:16:22 pm

gia: 2011-05-11 01:15:45 pm

gia: 2011-05-11 01:14:59 pm

gia: 2011-05-11 01:13:22 pm

2011-05-11 01:11:29 pm

I love YaBB 1G - SP1!

Ok got a stopwatch and got the video with duplicate frames removed, times match much closer. edited fraps video (~33s), fraps video (~38s), no-fraps stopwatch time (~33s).

So the game's "realtime" is the video minus duplicates, however while running I did have the benefit of the game slowing down and my actual realtime was the video with duplicates.

Depending on which is the time to be used the best choice to record on max or lower settings. If duplicates are removed max benefits the player, because it will most likely play with the game slowed, sure the controls are slowed too, but you get more time to react, I'd record max for the video quality.

If they are counted then it hurts the player unless he gets a pc that can record at max fps, so lowest settings to make the fps while recording as close as possible to the real thing and be hurt less by lag. If so I wonder what is the lowest I can go. 320*240 @30fps? The only thing I'd hate of this is that your best run may not be your best if you pc lagged for some reason, so you'd have to do several runs and just pick whatever happened to get a lower count. I guess I could try to record externally.

Now I think of it the rule was to use the ingame timer if accurate otherwise the video length so the only option would be the second. Still players should be wary when using fraps that their game may slow down actual gameplay while recording instead of skipping frames. They can use that script and do the same kind of testing.

Ok got a stopwatch and got the video with duplicate frames removed, times match much closer. edited fraps video (~33s), fraps video (~38s), no-fraps stopwatch time (~33s).

So the game's "realtime" is the video minus duplicates, however while running I did have the benefit of the game slowing down and my actual realtime was the video with duplicates.

Depending on which is the time to be used the best choice to record on max or lower settings. If duplicates are removed max benefits the player, because it will most likely play with the game slowed, sure the controls are slowed too, but you get more time to react, I'd record max for the video quality.

If they are counted then it hurts the player unless he gets a pc that can record at max fps, so lowest settings to make the fps while recording as close as possible to the real thing and be hurt less by lag. If so I wonder what is the lowest I can go. 320*240 @30fps? The only thing I'd hate of this is that your best run may not be your best if you pc lagged for some reason, so you'd have to do several runs and just pick whatever happened to get a lower count. I guess I could try to record externally.

Now I think of it the rule was to use the ingame timer if accurate otherwise the video length so the only option would be the second. Still players should be wary when using fraps that their game may slow down actual gameplay while recording instead of skipping frames. They can use that script and do the same kind of testing.