missionctrl

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

192 Excellent

About missionctrl

  • Rank
    Newbie
  1. I think they are using the x/y ratio as a cheap way to do fake trigonometry. If the mouse is far away from the eyes, they should rotate slower. If the mouse is close to the eyes, it will rotate faster. That would happen naturally with sin/cos. So I think what they have is already pretty simple and clever.
  2. 3D rotation control with a mouse can be tricky. I wouldn't use quats. It looks like you are just using Euler angles derived from the mouse movement, which is probably the best way to do it actually. You just need some tweaks. Here is the simple 2-step rotation I use: Step 1: Use the X mouse movement to rotate the camera matrix around the WORLD Y axis. Step 2: Then use the Y mouse movement to rotate the camera matrix around its newly rotated LOCAL X axis. And that's it. As for your model matrix, maybe it's just me, but it seems odd that you are calculating each axis of the rotation matrix individually and then assembling them into a Voltron matrix, rather than just rotating the whole matrix. And I think you were over-complicating it with all of the matrix multiplication. Anyway, I'm not super familiar with GLM, but I think the camera code would look roughly like this: Matrix4f camera = glm::mat4(); m_flFrameYaw = 0.02f * g_pInput->GetMouseDeltaX() * g_pEngine->GetDeltaTime(); m_flFramePitch = 0.02f * g_pInput->GetMouseDeltaY() * g_pEngine->GetDeltaTime(); // do the Y rotation first, in world-space camera = glm::rotate( camera, m_flFrameYaw, Vector3f( 0.0f, 1.0f, 0.0f ) ); // next do the X rotation in local-space camera = glm::rotate( camera, m_flFramePitch, Vector3f( camera[0][0], camera[0][1], camera[0][2] ) ); // do translation last camera = glm::translate( camera, GetPosition() );
  3. If it were me, I wouldn't even bother with a "game engine." That's a lot of overhead with no benefit for a simple crossword game. I would use a hybrid app framework such as Xamarin or Nativescript. You can write one codebase, use basic native UI elements, and compile for both Android and iOS. Nativescript uses Javascript/Typescript and a basic HTML-like markup for the UI. Xamarin.Forms uses C#, .Net, and XAML for the UI. I would probably recommend Xamarin specifically. It is easier to get running right out of the box (setting up a Nativescript development environment will be a test of your patience) plus it is going to be more familiar to software developers (it uses Visual Studio, .Net, etc.) whereas Nativescript uses all web technologies (Javascript, Node, Angular, etc).
  4. OpenGL textures will show up under IOKit. With that in mind, here are a few things I noticed that might help - The iPhone5 is the only one that maintains a zero swapped size and is also the one with the smallest screen size. So maybe screen size is a factor? Especially if you're doing multiple render passes. Your iPhone6 is running iOS 9, so perhaps there was a memory management change for iOS 10 that effects what you're doing. Metal had some changes in iOS 10 with texture-handling, but I think that was mostly to support wide-range pixel formats. Still might be worth looking into.
  5. If I understand the problem correctly, you need to know which direction is "left and right" and "up and down" relative to your "focalDir" vector, correct? You could calculate this with a few cross products, but you need to throw in another point of reference, usually an "up" vector (in this case, i'm assuming the Y vector is "up") zAxis = vectorMinusVector(target, camPos); //this is your current focalDir zAxis.vectorNormalize(); xAxis = vectorCrossProduct(up, zAxis); xAxis.vectorNormalize(); yAxis = vectorCrossProduct(zAxis, xAxis); vectorNormalize(yAxis); //now you have you an xAxis and yAxis to move around on pos.addVector( vectorTimesFloat(xAxis, randomX) ); pos.addVector( vectorTimesFloat(yAxis, randomY) ); Another option would be to use the camera matrix instead of generating all new vectors. Then all of these vectors are sorta bundled together in a neat package, and you can just do local translations, but the results would be the same.