Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pyros]

ok. if I am wrong, please, explain me how does WME synchronization works? This question is missing in WME help documentation.

 If I will use standard sleep (20) value and my vsync is ON and therefore FPS on my LCD is equal 60 - how to make FAST sprite and
save acceptable real-time speed (like i said: laser shot or energy ball?)

[pyros]

Naturally, the script can't sleep for shorter time than the frame render time. Even if you call Sleep(0), it will sleep for at least 1000/FPS millisecons.

It means that for Vsync=ON and FPS=60 -  minimal sleep() delay is approx. 17 msec? And I will not be able to render sprite faster

[Mnemonic]

How could you paint faster than how fast the screen is updated?

That's why I suggested the time-delta & velocity approach. It works best, because it's independent on framerate, only gives you smoother movement on faster machines. 3D characters and particles in WME use this approach. On the other hand, animation frames are never dropped, so if the computer is too slow, the animations run slower.

[pyros]

author=Mnemonic link=topic=2222.msg14809#msg14809 date=1186593895]
How could you paint faster than how fast the screen is updated?

That's why I suggested the time-delta & velocity approach. It works best, because it's independent on framerate, only gives you smoother movement on faster machines.

I really don't understand what are you talking about... In my case SPRITE MOVING SPEED (not its frames animation!) depends on FRAMERATE.
I've checked my sample on the 3 independent workstations - on each workstation sprite moving speed was different although animation smoothness must change only (like you said). I mean "animation" as sprite position changing but not as description of its internal frames cycle - which is correct and depends on real-time milliseconds.
You did not answer to my main question - does it possible to realize fast sprite position moving with vsync=on in WME or not?
i need sprite with constant physical (for gamer's eyes) speed 20 cm/sec on any middle level computer (manufactured in last 3-4 year)
By the way I've seen that WME particles doesn't have such problem at all may be due to really different approach to render.

Thanks.

[Mnemonic]

I believe I did answer all your questions. Maybe more than once
So once again: if you want constant movement speed independent on framerate, you need to take the time delta into account, not just change the position everytime the script is updated.

Something like this (not an actual code, just to give you the idea):

Code: WME Script

1. var PrevTime = Game.CurrentTime;
2. var Velocity = some_value_here;
3.  
4. while(true)
5. {
6.   var TimeDelta = Game.CurrentTime - PrevTime;
7.   PrevTime = Game.CurrentTime;
8.  
9.   Object.X = Object.X + Velocity * TimeDelta;
10.  
11.   Sleep();
12. }
13.  

This way if the framerate is high, the object will move in multiple smaller steps. If the framerate is low, it will jump in bigger steps. But the overall movement speed will be more or less constant.

[pyros]

I believe I did answer all your questions. Maybe more than once

Thanks for your patience But it seems that we have misunderstanding caused by my fuzzy explanations...

So once again: if you want constant movement speed independent on framerate, you need to take the time delta into account, not just change the position everytime the script is updated.
Something like this (not an actual code, just to give you the idea):

Code: WME Script

1. var PrevTime = Game.CurrentTime;
2. var Velocity = some_value_here;
3.  
4. while(true)
5. {
6.   var TimeDelta = Game.CurrentTime - PrevTime;
7.   PrevTime = Game.CurrentTime;
8.  
9.   Object.X = Object.X + Velocity * TimeDelta;
10.  
11.   Sleep();
12. }
13.  

Thanks for the idea, I understand time delta approach very well  but as I said in previous post - "without large coordinates increments because sprite will lose moves smoothness"

This way if the framerate is high, the object will move in multiple smaller steps. If the framerate is low, it will jump in bigger steps. But the overall movement speed will be more or less constant.

steps must be stable. in other words it means that I will not be able to calculate correct collision because moving steps will scaled.
In general when I switch off vsync i have 400 FPS and keyboard call executing very fast (performance of my PC is stable of course  )
when I switch on vsync i have 60 FPS and keyboard call executing much slower I think my computer doesn't works slower when FPS on my video card is changing

That's why I understand how to write code for case when PC performance is very low (but my game is not addressed for such old PCs).
But what should I do when computer is poweful and lower FPS limit is 60 and may be much higher.

Logically follows when I changed FPS from 400 to 60, WME proportionally increasing time delay between keyboard's calls in main cycle - I've checked it.

That is the question - how to manupulate 1000/FPS (like you said) time delay?

When FPS is not limited (vsync=off) time delays are minimal (near 2,5 msec) between keyboard call and my sprite moves are perfect
When FPS is limited (vsync=on) time delays are large (near 17 msec) between keyboard call and my sprite moves are very slow.
(attention! - moving steps +5 identical in both cases)

My code doesn't contains complicated structures which can utilize that time intervals.
In case when vsync=on, my computer forced to stand idle between keyboard calls? What's the reason?

[Mnemonic]

That is the question - how to manupulate 1000/FPS (like you said) time delay?

Well, the simple answer is: you don't. Rendering each frame takes some time, you can't avoid this. If vsync is disabled, the time is shorter, because the system doesn't wait for vertical retrace, but that's about it.
You can have either constant movement speed with variable increments, or you can have constant increments with variable speed, you can't have both.

In WME there's the Game.SuspendedRendering attribute, which can be used if you need more frequent script updates (without waiting for the frame to be rendered), but it doesn't solve your problem.

[pyros]

That is the question - how to manupulate 1000/FPS (like you said) time delay?

Well, the simple answer is: you don't. Rendering each frame takes some time, you can't avoid this. If vsync is disabled, the time is shorter, because the system doesn't wait for vertical retrace, but that's about it.
You can have either constant movement speed with variable increments, or you can have constant increments with variable speed, you can't have both.

In WME there's the Game.SuspendedRendering attribute, which can be used if you need more frequent script updates (without waiting for the frame to be rendered), but it doesn't solve your problem.

Ok. But delays  - time period between already rendered frames only.
In other words you mean that difference between these delays (400fps - 2 msec, 60fps - 17 msec) controlled by DirectX itself only?

By the way how to use Game.SuspendedRendering? How it works?
Thanks.

[Mnemonic]

Ok. But delays  - time period between already rendered frames only.
In other words you mean that difference between these delays (400fps - 2 msec, 60fps - 17 msec) controlled by DirectX itself only?

Yup, that's how the video hardware works. If vsync is enabled, it waits until the entire image is displayed before it starts displaying the next frame. If vsync is disabled, it doesn't wait, but you'll end up with an image which contains part of the old frame and part of the new frame.

By the way how to use Game.SuspendedRendering? How it works?

If you set Game.SuspendedRendering = true; the game will stop updating screen, i.e. no vsync will be slowing the execution down, but the screen isn't updated either until you set the attribute back to false.

[pyros]

Ok. What about triple buffering? Can it be realized in WME?

[Mnemonic]

I'm not sure triple buffering would help if vsync was enabled.. In any case, WME doesn't use triple buffering as of now.