Breaking in animate()

Page: 1 2 3 4 5 6 ... 17 18 19
Sep 17 2013, 6:03 am
In response to Bravo1
Bravo1 wrote:
Kaiochao wrote:
You can't have animations faster than the game's framerate.
A while loop wouldn't work any faster than that either.
Just like in sleep and spawn, use world.tick_lag for the shortest possible delay.

Just increase the frame rate.

The issue is that animate() is always at 10 FPS. Regardless of world tick_lag or world FPS.

If you use a while() loop, you could update transforms at the speed of world.tick_lag.

Use a decimal value for time. Animate updates with world.fps on the client, but its calculations are based on 1/10ths seconds. just like everything else in DM.
Sep 17 2013, 6:11 am
In response to Ter13
Ter13 wrote:

Use a decimal value for time. Animate updates with world.fps on the client, but its calculations are based on 1/10ths seconds. just like everything else in DM.


Tried this. Anything <=1 results in an instant change and using any other decimal (20.5, 2.4, 1.25, etc) appear nearly identical to rounding the time up to the nearest whole number.

If I set the world.tick_lag to 0.25, setting the time on animate to 1.25 looks identical to a time of 2. if I set it to 0.5 it's instantaneous.

As I said. animate() only ever plays at 10FPS regardless of decimals in the time value or the worlds FPS.

I was only wondering if this is intentional or not.
Sep 17 2013, 6:12 am
I'd advise reporting that as a bug, then, as it should mimic all other delay behavior.
Sep 17 2013, 6:15 am
Yeah. Sleep(0.5) on a world.fps of 30, for example, ticks at 30Hz. Since animate() is supposed to be consistent with sleep() and spawn(), it should behave the same way and if it doesn't, that's either a bug or a slight design oversight.
Sep 17 2013, 7:12 am
In response to Bravo1
Bravo1 wrote:
Ter13 wrote:
Use a decimal value for time. Animate updates with world.fps on the client, but its calculations are based on 1/10ths seconds. just like everything else in DM.

Tried this. Anything <=1 results in an instant change and using any other decimal (20.5, 2.4, 1.25, etc) appear nearly identical to rounding the time up to the nearest whole number.

If I set the world.tick_lag to 0.25, setting the time on animate to 1.25 looks identical to a time of 2. if I set it to 0.5 it's instantaneous.

The key word here is "looks". You're just not noticing the difference, which isn't too surprising as the human eye is only really capable of giving you updates at 8 FPS; higher framerates become apparent only as a level of smoothness (which evidently we can see faster), but that's not as detailed and each person's ability to catch that subtlety seems to vary. Also if your drawing speed is slow, your client may simply be skipping frames, which would add to the problem.

As I said. animate() only ever plays at 10FPS regardless of decimals in the time value or the worlds FPS.

That's incorrect. Short of frame skipping, the map is drawn once per client frame. The client frames happen at the speed given by world.tick_lag. That's just how the whole thing works, so there's no way the animation could happen at only 10 FPS if you set the frame rate higher, unless DS can't keep up with the drawing.

The time value is a floating-point number and is passed to the client the same way. The client has for some time done all its animation timing based on floating point as well. So what you're seeing is absolutely an artifact of perception. I think you're just getting hung up on the fact that the timing is in "standard ticks", but that's totally in line with sleep(), spawn(), and even the delay setting in icon animations.
Sep 17 2013, 7:22 am
I've been trying to find a way to test this. Perception issues aside, the transforms do seem to be updated at the correct intervals. If the client is indeed resulting in 1/10ths second capped animations (which does not seem to be the case), the server appears to be recognizing transform changes accurately to the second. Testing it on the client, due to the nature of the system, is only possible by viewing minute changes on a frame-by-frame basis, and frankly, I'm not willing to put that much work into my tests.

I'd wager that this is an artifact of confirmation bias and the ever-present error presented by humans.

Sep 17 2013, 7:25 am
I'll get a project together to show you what I mean.
Sep 17 2013, 7:29 am
http://wolfcrow.com/blog/ notes-by-dr-optoglass-motion-and-the-frame-rate-of-the-human -eye/

The maximum fusion frequency for rod-mediated vision is about 15 Hz. The maximum fusion frequency for cone-based vision is about 60Hz. This corresponds to between 30 to 120 fps.
Sep 17 2013, 7:34 am
In response to Flame Sage
Flame Sage wrote:
The maximum fusion frequency for rod-mediated vision is about 15 Hz. The maximum fusion frequency for cone-based vision is about 60Hz. This corresponds to between 30 to 120 fps.

I stand corrected; the 1/8s rule is something I learned as a kid. I ought to know better than to trust anything remotely medical that probably originated in the '70s or earlier.

Nevertheless Bravo's case is absolutely confirmation bias, nothing more. I not only went over the code thoroughly but tested thoroughly, and got verified results that said the animation is happening when it's supposed to. My tests passed the eyeball check as well as the data check.
Sep 17 2013, 7:35 am
Human perception isn't really based on frames. While there is the equivalent to a frame rate, human vision is based on several different forms of visual detection. This is why anime looks fine at 12-15 FPS and live action doesn't. I read somewhere that in order to simulate a virtual reality that could trick the human eye completely, you'd need at least 500FPS.

Really, they taught that? They didn't even teach us about vision when I was in school.
Sep 17 2013, 7:41 am
Like I said. I'll get a test set up.
Sep 17 2013, 7:48 am
In response to Hiro the Dragon King
Hiro the Dragon King wrote:
Human perception isn't really based on frames. While there is the equivalent to a frame rate, human vision is based on several different forms of visual detection. This is why anime looks fine at 12-15 FPS and live action doesn't. I read somewhere that in order to simulate a virtual reality that could trick the human eye completely, you'd need at least 500FPS.

I've never seen anime aspire to anything higher than 4 FPS, but admittedly I've never looked very hard. Maybe the high-quality stuff reaches 12 FPS.

Really, they taught that? They didn't even teach us about vision when I was in school.

I don't remember if the 1/8s thing was something I read in a science class, something like a textbook or a magazine, or an encyclopedia. (If it was from an encyclopedia, it was likely our set at home, which was printed in 1972. My parents were still in high school then.) I'm certain I didn't learn it on TV, anyway. But we're talking about the '80s here; a lot of information got printed based on ideas that were wildly outdated or where more modern research on the subject just hadn't happened yet. The '70s were the freaking dark ages as far as medicine was concerned.

You know how Wikipedia sometimes gets things wrong, and mistaken song lyrics get put up on lyric sites all the time because the people who put them there are morons? It was just as bad before the Internet, when information was reprinted willy-nilly without verification. Sadly it still is; our history textbooks are full of deplorable inaccuracies. My 5th grade teacher told a story of how once she had a student looking up Thomas Jefferson's DOB, and she suggested using another source to confirm; three separate encyclopedias had three different dates.
Sep 17 2013, 7:52 am
On a side note, animations won't play unless I'm moving for some reason. This is on a fresh project.
Sep 17 2013, 7:53 am
In response to Bravo1
Bravo1 wrote:
On a side note, animations won't play unless I'm moving for some reason. This is on a fresh project.

That's a fixed bug. I think the update is out for that one.
Sep 17 2013, 7:59 am
In response to Bravo1
Bravo1 wrote:
On a side note, animations won't play unless I'm moving for some reason. This is on a fresh project.

That was fixed in 500.1207. If you're still on an older build then the problems you've seen with animation frames would make a great deal of sense. You posted your bug report against 500.1208, but you should double-check you're on the right version.

All other factors aside, on 500.1208 I can visually confirm, as have other users, that animations are happening at the right speed. The code says this as well, as does actual debug output. I won't absolutely rule out that maybe you found a niche case where something unexpected is happening, but at least in basic tests the animation is working correctly.
Sep 17 2013, 8:04 am (Edited by moderator on Sep 17 2013, 10:06 am)
Good lord, that's awful. That's also one of the reasons why I argued with my teachers about the merits of citing Wikipedia. Wikipedia cites sources that you can generally see. I know at that point, you can simply cite the source itself, but I liked arguing with my teachers. Anyway, I'm not sure if you've ever tried find a book by it's ISBN but it's not fun. EDIT: This may just have been because I grew up in the middle of nowhere.

As far as issues like Jefferson's DOB, I find encyclopedias difficult to use because they always seem to take one source and run with it, rather than stating that it's disputed.

While not anime, Richard Williams' 'The Thief And The Cobbler' was animated at twenty four hand drawn frames per second. It was a visual masterpiece, but unfortunately the parent company [screwed] him on it.
Sep 17 2013, 8:10 am
Looks like when I updated to 1208 it didn't stick. I've been on 1205 the entire time. I had to completely uninstall byond and then reinstall for 1208 to finally stick.


Edit: Yep, that was it. It was a 1205 bug that was giving me hell.
Sep 17 2013, 10:12 am
In response to Bravo1
Bravo1 wrote:
Looks like when I updated to 1208 it didn't stick. I've been on 1205 the entire time. I had to completely uninstall byond and then reinstall for 1208 to finally stick.

Edit: Yep, that was it. It was a 1205 bug that was giving me hell.

That makes way more sense to me now. Chances are you're having the good old VirtualStore problem on your system, where your OS is interfering with BYOND's updates.
Sep 17 2013, 10:41 am
In response to Lummox JR
Lummox JR wrote:
I've never seen anime aspire to anything higher than 4 FPS, but admittedly I've never looked very hard. Maybe the high-quality stuff reaches 12 FPS.

I believe most anime, or at least the movies, are produced at 24 frames per second these days. Akira was supposedly one of the first to do it that way, or at least made it popular. Some studios are lazy and stick with 12fps, only switching to 24fps during action scenes.
Sep 17 2013, 1:42 pm
In response to SuperAntx
SuperAntx wrote:
Some studios are lazy and stick with 12fps, only switching to 24fps during action scenes.

Sometimes it's not laziness, but money. Studio Pierrot did this quite well with the original Naruto run, saving money with poorer animation in some places so that they could have the money to absolutely wow you in the really important scenes.
Page: 1 2 3 4 5 6 ... 17 18 19