Demion

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

139 Neutral

About Demion

  • Rank
    Newbie
  1. I need to make realistic human movement (3D) using mouse click.   1. Get mouse click point using RaycastAll. 2. Smoothly Slerp to LookRotation. 3. Move transform.forward.   Everything works fine, except I have problem with circular movement (close radius).   1. Example If dont move transform.forward while Slerp to LookRotation or MoveTowards instead of transform.forward it will be spinning like whirligig on circular movement. 2. Example If do move transform.forward while while Slerp to LookRotation it will distort trajectory of straight direct movement.   Is there any solution to move circular realistic (not spin like whirligig) and move straight direct when needed (not distort trajectory)?   I need straight movement from first example and circular movement from second.   void Update() {     if (Input.GetMouseButtonDown(1))     {         Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition);           RaycastHit[] hits = Physics.RaycastAll(ray);           foreach (RaycastHit hit in hits)         {             if (hit.transform.tag == "Ground")             {                 DestinationPosition = new Vector3(hit.point.x, transform.position.y, hit.point.z);                   DestinationRotation = Quaternion.LookRotation(DestinationPosition - transform.position);                   break;             }         }     }       if (Vector3.Distance(transform.position, DestinationPosition) > 1)     {         transform.rotation = Quaternion.Slerp(transform.rotation, DestinationRotation, RotationSpeed * Time.deltaTime);           transform.position += transform.forward * MovementSpeed * Time.deltaTime;           //transform.position = Vector3.MoveTowards(transform.position, DestinationPosition, MovementSpeed * Time.deltaTime);           animation.CrossFade("run");     }     else     {         animation.CrossFade("idle");     } }
  2. Good point. Although WM_KEYDOWN / WM_KEYUP approach (commented out) has no allocations and same results. Anyway in real game I need to determine which event happend (press or release) and then determine key, so I need to do this allocations.   Especially for you reupload and fixed - pastebin   Last test up to 65 ms delays, Vsync is only 16 ms.
  3.   GetTime() multiplies counter x 1 000 000 before division and that gives perfect microsecond accuracy ( frequency = 1 second = 1 000 000 microseconds). Anyway please also take a look at second source code which actually makes drawing without any time involved. Its not time releated problem at all.       Not true. Press-Up velocityY -=4, Release-Up velocityY +=4 (resulting velocityY == 0), Press-Up velocityY -=4, Press-Right velocityX += 4 (resulting velocityY == -4, velocityX == 4) etc. Please notice that on key release I call ProcessInput with negative velocity value (on key press positive value accordingly).   It would be great if you compile (it has no dependencies) and take a look it works perfectly fine except multiple key "simultaneous" press / release not always detected correctly becouse of delay between message (they are detected one by one, first one key and after slight delay second key which leads to unwanted results).
  4. Sorry, you are very wrong. I add velocity only once on key press and this has nothing to do with my problem.   if ((lParam & (1 << 30)) == 0)   ProcessInput(wParam, 4); if (!Keys[raw->data.keyboard.MakeCode]) {   Keys[raw->data.keyboard.MakeCode] = true;   ProcessInput(MapVirtualKey(raw->data.keyboard.MakeCode, MAPVK_VSC_TO_VK), 4); }
  5. Log from first program - pastebin It is rarely 100 milliseconds but often within 25-50 milliseconds, which is 1 or 2 frames (using VSync 60 fps, ~ 16 ms per frame) which already leads to unwanted result (game logics changes direction, animation frame (angle) etc).   So only solution I see so far is using raw input (which is subjectively a little bit faster) instead of wm_keydown / up and process input in game with periodic delay (once per 2-5 frames instead of every frame) to avoid unwanted results.   According to stackoverflow delays of the order of 50 ms or so are common in processing key presses through the normal Windows message queue.   Thanks for effort anyway. I am still looking for any better solutions.
  6. Actually cause of problem is that there no such thing as "simultaneous" in programming. For instance, I press and hold two keys (down & right) and move diagonally, then I "simultaneous" (as quickly as possible) release these both keys, but window message loop (pretty same with raw input) receives WM_KEYUP Down and then only after slightly delay (it can reach 50-100 ms according to tests!) it receives WM_KEYUP Up. Because game logic and rendering processes much faster (60 fps, vsync, 16 ms) it assumes Up key is still being pressed (changes direction and animation frame to Up instead of keeping Diagonal). You can compile given code and test yourself, it has no dependencies and fully working.   Question is - is such behaviour normal? Is there way to process input faster? Could it be hardware (keyboard) limit? Or how to workaround this to make simultaneous multiple key press / release more "smooth" for player (diagonal movement, combos etc) ?   More I delay input process in game logics more "smooth" it becomes for player (input messages get in time) but also less responsiveness it gets.
  7. I am developing 2D game and faced problem with simultaneous multiple key press / release detection needed, for instance, for character diagonal movement.   Problem is when I "simultaneous" (it has nothing to do with my reaction I press / release very quickly) press / release multiple (two) keys delay between messages often is much more than single frame (16ms with VSync), for instance, it can reach 50-100 millisecond, so character starts moving single direction and only after slight delay diagonal (as intended).   Is it normal for WinAPI messages or is it hardware limit? Is it possible to detect input faster or how games deal with it?   Only solution that kinda helps is process inputs in game logics with periodic delay (for instance every 100 ms), but this sacrifices control responsiveness very much.   I am dispatching WinAPI WM_KEYDOWN / WM_KEYUP messages in while loop.   I also tried to dispatch input in seperate from render thread with GetMessage and  also tried RawInput approach.   Delay measurement test project : pastebin   Actual OpenGL diagonal movement test project : pastebin