Jump to content
  • Advertisement

JoeJ

Member
  • Content Count

    1643
  • Joined

  • Last visited

  • Days Won

    11

JoeJ last won the day on October 20

JoeJ had the most liked content!

Community Reputation

3135 Excellent

7 Followers

About JoeJ

  • Rank
    Contributor

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sounds interesting. But i guess you still have to use SetCursorPos, and a useless message is generated? This sounds like you have some logic bug, because if you calculate the delta from the center it should be zero and the camerea should not ratate back. Sounds your mistake is that you calculate camera orientation directly from the delta, but instead you want to calculate it's rotation (or angular velocity). So it sould be like: camera.angleY += mouseDelta.x * someScalingFactor
  2. The thing is - OS is written wor GUI applications, not for games So hacks like this are often unavoidable. But maybe someone else knows a trick...
  3. How do you mean this? What would be an example? Capturing the mouse does not help, the additional WM_MOSEMOVE is still geneareted on SetCursorPos. EDIT: In fact i do what i think you mean with capturing. So if the mouse pointer goes out the window on the right, it comes in at the left. But at this point i have to use SetCursorPos to make that jump happen, so the 'problem' presists. I do this so i can drag gizmos as long as i want without getting stopped if mouse cursor hits the edges of the screen. (code below - the comments indicate that i stumbled over the same problem ) if (uMsg == WM_MOUSEMOVE) { if (globalApplication->MouseCaptured()) { RECT winRect; GetClientRect (hWnd, &winRect); ClientToScreen (hWnd, (LPPOINT)&winRect.left); ClientToScreen (hWnd, (LPPOINT)&winRect.right); ClipCursor (&winRect); POINT curpos; GetCursorPos(&curpos); int width = max (3, winRect.right - winRect.left); int height = max (3, winRect.bottom - winRect.top); bool moved = false; if (curpos.x <= winRect.left) {curpos.x += (width-2); globalApplication->mouseMulX++; moved = true;} else if (curpos.x >= winRect.left + width - 1) {curpos.x -= (width-2); globalApplication->mouseMulX--; moved = true;} if (curpos.y <= winRect.top) {curpos.y += (height-2); globalApplication->mouseMulY++; moved = true;} else if (curpos.y >= winRect.top + height - 1) {curpos.y -= (height-2); globalApplication->mouseMulY--; moved = true;} globalApplication->SetMousePosition ( curpos.x - winRect.left - globalApplication->mouseMulX * (width-2), curpos.y - winRect.top - globalApplication->mouseMulY * (height-2) ); if (moved) { SetCursorPos (curpos.x,curpos.y); // creates a new WM_MOUSEMOVE message //UpdateWindow(hWnd); // force WM_PAINT over WM_MOUSEMOVE } } else { ClipCursor (0); globalApplication->mouseMulX = 0; globalApplication->mouseMulY = 0; globalApplication->SetMousePosition (LOWORD (lParam), HIWORD (lParam)); } }
  4. In this case also your delta is zero, so nothing happens as intended with the camera, even without any hack?
  5. JoeJ

    Capsule-Capsule Detection

    And this is the same as particle1.get_p2_position() - particle1.get_p1_position()? I guess yes, but just to be sure. And changing the last lines to: if (close_d < (2*S_RADIUS)) return true else return false ... not using an epsilon, is likley what you had initially (before introducing the 'touching'-bug with the epsilon, which is not necessary). That said just to confirm i do not see any other thing that could be wrong with your code. Maybe the users of your code use a broad phase to detect potential colliding pairs? Some acceleration structure? I'd bet the bug is on their side then, or their visualization is off.
  6. JoeJ

    Capsule-Capsule Detection

    Can it be this returns the center of the capsule, while the algorithm assumes it to be one of its end points?
  7. JoeJ

    Capsule-Capsule Detection

    Because D is already a result of squares, i think this should be just: if D < small_num But htat's unlikely the reason or a big problem at all. In your picture the intersecting capsules seem more normal than parallel to each other and the test should not fail in any case (except the scale of the scene is super tiny). So i would try to get data from the guys who detect the issue - maybe they can log capsule positions instead making a screenshot. Otherwise it's helpful to have some visualization yourself, and the ability to set up capsule positions intercatively from some GUI. This way it becomes easy to detect failure cases yourself and to debug them.
  8. JoeJ

    Capsule-Capsule Detection

    Ah, sorry - i did only quickly read over your post and did not notice your snippet is a small section from the inital post. Accidently i though you would propose to check bounding spheres of both capsules for a quick seperation test and leave it at this. So i totally missed your point. My bad - i was in a rush. Looking more closely i see you have answered the question already and my reply was just noise. I was wrong with this too. Also he OP code seems an exact copy of Eberlys code that i have linked to, just for Python.
  9. JoeJ

    Capsule-Capsule Detection

    This should be helpful: https://www.geometrictools.com/Samples/Geometrics.html#DistanceSegments3 IIRC, it uses an epsilon only once to tell if the lines are parallel. (But i see the code has been updated and there is nmore efford on precision issues now.) A simple test like this can only safely tell there is no intersection because the capsules are too far apart. It can not tell if there is intersection if they are close to each other.
  10. JoeJ

    Fractals in games

    Reminds me about kkrieger - all procedural, entire game in 96 kb:
  11. JoeJ

    Github and Viruses

    Yeah, people mostly avoid uploading executables or dlls. So no virueses, but a lot of fun to build all those dependencies yourself.
  12. This. Still no feedback - ist your jump working now or not? And... well, you have a hard time learning programming, but you don't give up. Because you really want to create the game of your dreams. Fine. And now you ask others what to add to this game?
  13. Here is Prototypes solution (page 2): Here is mine (page 3 - not using GLUT but easy for you to do so): Both should work, but it was you who gave no feedback on this. Did you try? Did it work? (I had to zoom out a lot to see the jump working - you may need to tweak velocity and gravity until it behaves like you want.)
  14. Ther is some option in Visual Studio, and enabling it lists how inclusion dependencies are resolved, so while compiling it prints all header files in order, and from that you can see unnecessary cycles or something. Helps to fix it. I think it's this option: A helpful work around is to make certain files compile faster by using debug build, even if release build is selected. snippet from @Hodgman #if defined _MSC_VER #define MAKE_DEBUGGABLE __pragma(optimize("", off)) #elif defined __clang__ #define MAKE_DEBUGGABLE _Pragma ("clang optimize off") #else #define MAKE_DEBUGGABLE #endif With this included, just add MAKE_DEBUGGABLE on top of your slowly compiling files (before or after the includes matters ofc.) Very helpful also in case debug builds run too slow to be useful.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!