Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / DarkGDK - Unofficial Updates

Author
Message
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 30th Nov 2014 08:47 Edited at: 30th Nov 2014 08:47
Link
Hey - just thought I'd let you guys know. I discovered and fixed a bug with the mouse. Just to be clear, I'm not using r114, I'm still using my derivative of r113. I entered this as an "Issue" on the source code repository. I'll just copy to here what I wrote there:

What steps will reproduce the problem?


What is the expected output? What do you see instead?
As long as the mouse pointer is within the window, it should remain still and under normal user control. But what happens is that it tends to move in a straight line, on its own.

Please provide any additional information below.
I tracked down the cause. The mouse position calculations are scaled according to the current window size (i.e. if the window has been resized by the user, maximized, etc). And the scale is a floating point calculation. However the input and output position information is quantized to integers. So there is continuous truncation of essential precision needed to keep the mouse stable.

Thus, in my own copy of the source code, I changed those mouse position variables (including how they're used and recalculated in the various functions) from ints to floats. This solved the problem. The mouse is now stable whether it's in full-screen, windowed mode, or maximized window mode.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 30th Nov 2014 17:25
Link
I’m confused. What’s the purpose of positioning the mouse where it already is? Anyway, I changed the function to use integers and now my application crashes in windowed fullscreen.
Back to top
Profile PM Email
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 1st Dec 2014 00:23 Edited at: 1st Dec 2014 01:53
Link
No, the functions already use integer variables, and that's the problem The idea is to change them all to floats. For example, the globals:

int iWindowsMouseX becomes float fWindowsMouseX
int iWindowsMouseY becomes float fWindowsMouseY

... and every integer inbetween.

Repositioning the mouse to where it already is is the most direct test of how the positioning functions. Let's say in your 2D game that you want to prevent your mouse pointer from crossing a wall or boundary. You would then have to reposition the mouse to keep it bound. But because of the continuous truncation of internal calculation updates, the mouse pointer will tend to pull one way when repositioned. This fixes that.

This bug was actually reported a number of times in this forum, and like many reported bugs, it went unfixed. From looking at the source code of the positioning function, it looks like one of the authors tried to fix the bug (there's a commented-out compensation for it with the Y variable), but were at a loss for how to do it. Turns out there was nothing wrong with the math, just the variable types that were internally used. Sometimes it just takes a fresh pair of eyes

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 2nd Dec 2014 00:56
Link
I build a test project to see if I could duplicate the drifting problem. I have no drifting, but when I try to move the mouse above or to the left of the window the mouse jumps a distance back into the window. When I try to move the mouse to the right or bottom the mouse gets stuck on the bottom right of my desktop. I moved the code to store the values to the global structure to the beginning of the function before the iX and iY variables are altered. This has solved my issue. Since the function SetCursorPos() excepts parameters of type long, I’m a little reluctant to change the globals to float.


Back to top
Profile PM Email
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 2nd Dec 2014 01:18 Edited at: 2nd Dec 2014 01:25
Link
There were some screen modes where it worked fine, others where it pulled. That's why I mentioned this solved it for all the major screen mode types (full-screen, windowed, and maximized windowed).

As for the mouse getting stuck at the window borders, this is because the mouse position variables are relative to the window.

Perhaps you were thinking of long long which is 64 bits. That's not used here. An int ~is~ a long (32 bits) unless specified as a short (16 bits). BTW, 16 bits would be more than sufficient. So there's already conversion between long (int) and float anyway. Like I said, converting the storage and intermediate variables to float fixes the bug and gives me no problems. Single-precision floats can store integer values of up to 24 bits without degradation, which is far more than needed for the ranges involved here (as I pointed out, 16 bits is well more than sufficient). Your resolution size would have to be over 16 million pixels on a single axis before it would matter with 24 bits. ...Plenty of room.

But, to each his own...

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 2nd Dec 2014 02:54 Edited at: 2nd Dec 2014 03:01
Link
Looking at the Windows API for SetCursorPos() the parameters are integer. Remnant of Visual Basic still lingering. Just thought having the mouse move back into the screen by the offsets or getting stuck on the bottom left of the desktop would have been a bigger problem. I appreciate you raising this issue. I will look into it some more.

Thanks
Back to top
Profile PM Email
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 2nd Dec 2014 02:58
Link
np!

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 6th Dec 2014 00:41 Edited at: 6th Dec 2014 01:22
Link
So here's an additional, very odd bug I discovered yesterday that's related to the what I recently posted about the mouse position.

If you do a dbBox command to create a box for the section of the screen the mouse is in, then whenever you hit vertical screen (window) boundaries, the mouse pointer will bounce away from the vertical boundary and to the right - a fairly significant distance. But no dbBox in that section of the screen: No bounce! This occurs when the window is set to lower than the desktop resolution and is maximized. From briefly glancing at the code, it appears that the code for the two functions (dbBox and mouse position retrieval/setting) are unrelated, and yet they're producing this bug together - which leads me to believe it may be a Microsoft bug. But in hopes that it's not, one possible place to look would be in the setup of the WinProc callback function, since the mouse coordinates are retrieved from the right-most parameter which that function receives. I only glanced at the code though.

I decided to work around it - it's not a big deal for me to this time, so I'm not gonna try and fix this one myself.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 6th Dec 2014 02:18
Link
I have now been able to duplicate the mouse drifting. To me neither one would be an issue. I can understand the reason someone would use the mouse in this manner. However, I would not use the mouse position but the mouse movement to position a sprite or paste an image. I have rewritten the PositionMouse() function to use the Windows API ClientToScreen() function instead of GetWindowRect() with no difference in function. What makes no sense to me is mathematically since the API function SetCursorPos() excepts integers, it should work perfectly without changing the global mouse variables to float. Also, by setting the global mouse variables before iX and iY values are altered should really make no difference. But, by using dbPositionMouse(dbMouseX(), dbMouseY()) the mouse is now clipped in the window as it should be. I don’t think this is an issue with Microsoft or dbBox(). I think the issue may have to do with Dark GDK’s Windows message callback
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 6th Dec 2014 05:32
Link
This is my rewrite of the PositionMouse() function in CInputC.cpp. The only functional change is by moving the storing of the global mouse position variables to the beginning of the function to prevent the cursor from jumping back into the window by the offset or jumping to the bottom right of the desktop when the mouse is moved outside the window.



I have changed these lines in the WM_MOUSEMOVE event in the windows message callback in DBDLLCore.cpp. This seems to have solved all issues with the mouse.

From:


To:
Back to top
Profile PM Email
s_i
15
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 15th Dec 2014 19:23
Link
@ WickedX

I have found a few sqrt() in the source code files of the DarkGDK, such as CObjectManagerC.cpp, DBOFormat.cpp, CCameraC.cpp, etc.

Could you take some time and replace them with fast assembler version of the square root (in those cases when it is justified)? DarkGDK will be faster in those cases.

Thank you.
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 15th Dec 2014 23:32 Edited at: 15th Dec 2014 23:39
Link
Wow!!!!!!

I just stepped through the disassembly of the Microsoft sqrt() function, and it is absolutely atrocious!!!! Damn! I did that once 15 years ago (with their libraries) and they were just as horrible. I thought they'd improved them since then! Guess not in some areas!!

Here's a simple assembly macro to replace the sqrt() function (if you wanna use this)...



Note: It won't work with a Constant input, only with a variable.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 16th Dec 2014 01:40
Link
Sure thing. Will get on it ASAP.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-18 21:41:33
Your offset time is: 2024-11-18 21:41:33