Print

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

[pyros]

Hi all.
 Im novice in WME and perhaps this question has been considered earlier.
But im really tired.

I just need to move 1 sprite on the screen by using keyboard buttons UP, DOWN, LEFT, RIGHT.

It works, but VERY slowly - moreover my FPS  - 630, sleep scripts timing - 20 msec (standard) and i think that all Ok with my sprites.
i've checked it in VS 2005. Default "Direct Input" keyboard handling speed with my sprites very impressive - my protagonist sprite fly over screen less than 1 sec (from left to right 1280/1024, without using bitblt only with X screen coordinates incrementing by +1).
Sample was written in C#. I suspect that WME synchronized with some kind of internal timer, therefore keyboard handling in essence doesn't depends on graphic and scripting processing.

But i'm very interested in WME - Please help me find out how to increase keyboard handling speed? I mean how to increase number of keyboard event handler per second?

It should be very useful for me.
Thanks a lot.

[Mnemonic]

And how does your keyboard handling code look?

[pyros]

Here it is...
First block for UP, DOWN,LEFT, RIGHT inquiries. Next for diagonals.

on "Keypress"
{
     if(Keyboard.IsKeyDown(VK_UP)) { obj.Y = obj.Y - 1; }
     if(Keyboard.IsKeyDown(VK_DOWN)) { obj.Y = obj.Y + 1; }
              if(Keyboard.IsKeyDown(VK_LEFT)) { obj.X = obj.X - 1; }
     if(Keyboard.IsKeyDown(VK_RIGHT)) { obj.X = obj.X + 1; }
 
  if(Keyboard.IsKeyDown(VK_UP) && Keyboard.IsKeyDown(VK_LEFT))
     {
      obj.X = obj.X - 1;
      obj.Y = obj.Y - 1;
     }
  if(Keyboard.IsKeyDown(VK_UP) && Keyboard.IsKeyDown(VK_RIGHT))
     {
      obj.X = obj.X + 1;
      obj.Y = obj.Y - 1;
     }
       if(Keyboard.IsKeyDown(VK_DOWN) && Keyboard.IsKeyDown(VK_LEFT))
  {
      obj.X = obj.X - 1;
      obj.Y = obj.Y + 1;
     }
     if(Keyboard.IsKeyDown(VK_DOWN) && Keyboard.IsKeyDown(VK_RIGHT))
     {
   obj.X = obj.X + 1;
   obj.Y = obj.Y + 1;
     }
}

[Mnemonic]

If you need continuous keyboard checking, you shouldn't rely on the "Keypress" event. Instead you should be checking the key state in a loop:

Code: WME Script

1. while(true)
2. {
3.   if(Keyboard.IsKeyDown(VK_UP)) ....
4.   // etc.
5.  
6.   Sleep(20);
7. }
8.  

[pyros]

Thanks. I will try just now. But what difference (in execution time I mean) between main cycle and "on key press" checking ?
I think that keypress is some kind of callback? Or not? Please, explain me shortly events hierarchy in execution from while (true) to end-user scripts.
I dont understand clearly how fired event translates to the specific object? Where can i find possible events list?
What kinds of events included in "INTERACTIVE" (in object description) identifier?
Does exist limited number of predefined events or I can create my own events too?

Thank you for your help.

[pyros]

As result of experiment - most fast code for single sprite moving is:

// infinite loop
while(true){

   if(Keyboard.IsKeyDown(VK_UP))
  {
  SpriteObj.Y = SpriteObj.Y - 2;
   Sleep(1);
  }
  if(Keyboard.IsKeyDown(VK_DOWN))
  {
  SpriteObj.Y = SpriteObj.Y + 2;
   Sleep(1);
  }
  if(Keyboard.IsKeyDown(VK_LEFT))
  {
  SpriteObj.X = SpriteObj.X - 2;
   Sleep(1);
  }
  if(Keyboard.IsKeyDown(VK_RIGHT))
  {
  SpriteObj.X = SpriteObj.X + 2;
   Sleep(1);
  }
 
  if(Keyboard.IsKeyDown(VK_UP) && Keyboard.IsKeyDown(VK_LEFT))
  {
   SpriteObj.X = SpriteObj.X - 2;
   SpriteObj.Y = SpriteObj.Y - 2;
   Sleep(1);

  }
  if(Keyboard.IsKeyDown(VK_UP) && Keyboard.IsKeyDown(VK_RIGHT))
  {
   SpriteObj.X = SpriteObj.X + 2;
   SpriteObj.Y = SpriteObj.Y - 2;
    Sleep(1);
  }
    if(Keyboard.IsKeyDown(VK_DOWN) && Keyboard.IsKeyDown(VK_LEFT))
  {
   SpriteObj.X = SpriteObj.X - 2;
   SpriteObj.Y = SpriteObj.Y + 2;
  Sleep(1);
  }
  if(Keyboard.IsKeyDown(VK_DOWN) && Keyboard.IsKeyDown(VK_RIGHT))
  {
   SpriteObj.X = SpriteObj.X + 2;
   SpriteObj.Y = SpriteObj.Y + 2;
  Sleep(1);
  }
  Sleep(1);
 
 
}

[Mnemonic]

But what difference (in execution time I mean) between main cycle and "on key press" checking ?

on "keypress" is meant for typing. That is, it's affected by typing repeat rate etc. While the while(true) loop allows you to check keyboard state asynchronously.

I dont understand clearly how fired event translates to the specific object? Where can i find possible events list?

The low level events triggered by the engine are listed in the documentation, in the "Script language reference" chapter.

What kinds of events included in "INTERACTIVE" (in object description) identifier?

Pleas rephrase, I don't know what you mean.

Does exist limited number of predefined events or I can create my own events too?

There are "low level events", triggered by the engine automatically (mouse, keyboard and a few others), plus you can define any custom high level events, and apply them yourself when needed. For example, WME demos use events such as "LookAt" or "TalkTo" to implement the game logic.

[pyros]

Thanks for your help

I spent all night yesterday trying to understand what happened with my previous script (). First time when i run it (after your advice) -  sprite reaction was perfect but when I restarted my computer and loaded WME and my project again - moving speed has decreased in three times!!! (FPS was stable) I didn't make any changes to my project.

And with script which was very fast when run first  - now i have STABLE LOW  sprite moving speed. 3x-4x difference approximately.
I create:
a) new project
b) all structures has been deleted except:
             one sprite
main cycle (within daemon)

 What else can affect the number of keyboard events per second? I dont understand what happened 

[Mnemonic]

Perhaps the "Sleep(1)" isn't such a good idea. That way the speed of your script will be dependant on framerate (the script will get executed in every frame). You should probably use higher values to get constant speed independent on framerate.
Or perhaps you should use a completely different approach, like checking if the key is down, and if it is, move your object using some constant speed based on time delta. That's how it's usually done.

[pyros]

Please look into my table...

Sorry I don't know how to insert picture into post. Is it possible?

[Mnemonic]

You'll need to upload the picture somewhere (like to flickr.com) and link it here.

[pyros]

I will use simple text better...
I've made some tests and i can't explain dependency.

Basic test conditions:

My workstation - CPU AthlonXP 2400+/RAM 768 Mb/ NVidia 6600 GT AGP Video

Screen resolution 1280x1024x32 + 4x antialiasing
30-frames 256x256 TGA-sprite moves straight down Y-axis with +5 px increment

A) Vertical synchronization is OFF - 400 FPS
-----------------------------------------------------------------------------
Sprite moving time for gamer's eyes  (in sec on the screen) top-to-bottom Y-axis with:
1. Sleep (0) in main cycle -  1 sec (OK) smooth animation (normal)
2. Sleep (5) in main cycle -  3 sec (3x slow) smooth animation (normal)
3. Sleep (10) in main cycle -  3 sec (3x slow) smooth animation (normal)
4. Sleep (20) in main cycle -  5 sec (5x slow) smooth animation (average)
5. Sleep (30) in main cycle -  7 sec (7x slow) smooth animation (average)
6. Sleep (50) in main cycle -  9 sec (9x slow) flicker animation (not acceptable)

B) Vertical synchronization is ON - 60 FPS
-----------------------------------------------------------------------------
Sprite moving time for gamer's eyes  (in sec on the screen) top-to-bottom Y-axis with:
1. Sleep (0) in main cycle -  4 sec (4x slow) smooth animation (normal)
2. Sleep (5) in main cycle -  4 sec (4x slow smooth animation (normal)
3. Sleep (10) in main cycle -  4 sec (4x slow) smooth animation (normal)
4. Sleep (20) in main cycle -  6 sec (6x slow) smooth animation (average)
5. Sleep (30) in main cycle -  7 sec (7x slow) smooth animation (average)
6. Sleep (50) in main cycle -  9 sec (9x slow) flicker animation (not acceptable)

Number of executed Keyboard.IsKeyDown calls are EQUAL IN ALL THESE CASES - 174 for both states of vertical synchronization (on/off) and l Sleep(0,5,10,20,30,50) values (for my hardware profile of course) .

Why performance with the test cases B) 1, 2, 3 4x-decreased relative to the A) 1 test case?
Logically if in each of keyboard's event/call we will increase sprite Y-axis position  by +5  therefore our sprite speed should be constant .
Why for gamer's eyes sprite time moving speed depends on FPS if number of executed generative events per real-time second (for coordinates changing) are equal in all cases?

[Mnemonic]

Like I said, if you use Sleep(0), it's like saying "wait till next frame", because it always takes more than 0 milliseconds to process one frame. So in the end you're calling IsKeyDown in every frame. And higher framerate = more IsKeyDown calls per second.

[pyros]

No. For any values of Sleep(x)  - number of Keyboard.IsKeyDown() calls are CONSTANT. But real speed of sprite moving is DIFFERENT. For my code calls value is 174.  Because in my script sprite path on Y-axis has limit of 870 px. If sprite moves with Y=Y+5 increments then  870px/5px = 174 times (I've checked it very carefully - when I changed in script Y-axis increment to +10 number of Keyboard.IsKeyDown() calls has decreased to 87). I don't understand why it works this way .

This is very strange problem for me - if number of keyboard calls are constant in both cases and FPS under forced control (vsync on/off,  FPS 60/400) then logically smoothness of the animation must change only, but NOT the time period of sprite moving for gamer's  eyes (if I call keyboard and increase Y=Y+5 174 times per REAL second - my sprite must achieve bottom of the screen in one second in ALL CASES). And for these FPS values (60/400) I shall not see any visible difference in speed and smoothness down to FPS value equal 30 and less (approximately eyesight limit for animation).
Moreover internal animation cycle in any sprite entity works CORRECTLY with dependency on REAL TIME msec delays between its frames.

I think correct way is:
 I changed sprite Y position - if engine has time to render frame with current sprite position smoothly- it will render (acceptable FPS > 30), if  has not  - engine should calculate sprite in the next position but frame will not be rendered correctly for your eyes due to video hardware limitations (not acceptable FPS < 30) , therefore animation flickering will appear.

In WME real time sprite moving speed is decreasing proportionally to FPS fall (sleep() delays too but it is reasonable)
But I mean situation only when sprite controlled by gamer with cycled keyboard state checking.
Within any sprite entity internal frames animation renders correctly without explicit fps dependency.

It means obviously that WME internal time ticker synchronized to fixed reference FPS value as base of engine synchronization - may be equal 60 or another fixed value but NOT to REAL TIME? Therefore all processes within engine depend on this base reference FPS value?
Can be that any external script executed by engine (especially event handlers) cannot be synchronized to real time?
In this case how to make laser shot sprite? Or energy ball sprite with fast moving over screen? (without large coordinates increment because it will lose smothness)?

[Mnemonic]

But real speed of sprite moving is DIFFERENT

Yes, but only as long as you use too low sleep values (i.e. lower than how much time it takes to render one frame). 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 obviously that WME internal time ticker synchronized to fixed reference FPS value as base of engine synchronization

Nope, not true.

[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.