missionctrl

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

206 Neutral

About missionctrl

  • Rank
    Member

Personal Information

  • Interests
    Art
    Design
    Programming

Recent Profile Visitors

715 profile views
  1. DX11 trying with ssao

    I don't see this very important bit of math to transform/scale your normals: vec3 normal = normalVS.xyz * 2.0 - 1.0; normal = normalize(normal); I pulled this from the tutorial you referenced (although, if you arent using Normal Maps, you might not need this)
  2. Really well-said Gian-Reto. Great breakdown. I feel that Macs' value comes from their convenience - a kind of easy-to-use black box computer (an appliance, as I believe Steve Jobs once called it). Conversely, PCs are generally more versatile and powerful. Based on that reasoning, I actually dislike Mac desktop computers and strongly prefer PC desktops. But for a laptop, where convenience is the main driving factor, I really prefer Mac. But you bring up a couple other really good points. Do you want to play games on this machine as well? If so, then obviously a PC will be better suited. Also, what platforms are you developing for? Mac and/or iOS? Then you will need a Mac. Windows? Then you will need a PC. Android/web/etc? Then either would work.
  3. Unless you're planning on making beefy AAA-quality 3D assets (which I assume you aren't), I think a strong 3D card is over-rated. If you are planning on using Unity or Unreal or something similar with a big, complicated 3D editor application, then you probably want to stay away from real low-end hardware. Otherwise, most modern GPUs (even low-end ones) are powerful enough for your needs. I use a Late-2013 MacBookPro for all of my work (I do web and mobile 3D development) and I love it. It is surprisingly powerful and lightweight. For whatever reason, Apple computers are generally looked-down upon in game-developer communities, but I would strongly recommend a MacBook as a laptop. You can probably get a refurb MacBookPro for around $1000. Or a new MacBookAir for the same price. I have a MacBookAir at home that I use for freelance/personal work and it works great for most stuff (although, I've never tried running the Unity editor or any heavy-duty 3D games). It's super-lightweight and portable. The only downside with the Air is cooling. It does well most of the time, but a long 8-hour work day involving significant GPU load is going to be a problem.
  4. Rotation matrix multiplication causes Gimbal lock

    Thanks for the link! Some interesting stuff. I think I see what's going on... it looks like changing the order performs the rotation around a locally-centered origin, but not in a local orientation. Maybe that's my fault for mis-using terminology a bit. When I say "local rotation" I mean "rotation around a local axis." Also, notice that he is using an "AngleAxis" function which should be exactly the same math as I just posted. In theory, I think if you are doing rotations in local space like this, order shouldn't matter. You don't NEED to do the Y rotation around the world's up vector, but it helps a lot if you want to maintain an up/down direction as a point of reference for the player (the best example of this is gravity which is in almost every game.) It makes it a lot easier for the player to maintain a sense of orientation.
  5. Rotation matrix multiplication causes Gimbal lock

    I've never heard of this. I guess it could work that way. I'm going to look into this because it sounds intriguing and would save a lot of computation in my code for local rotations. But rotation about an arbitrary axis is pretty complex. Maybe it simplifies way down if the axis isn't arbitrary? But anyway here's my C code for axis rotation: matrix rotationAboutAxis(float angle, vector axis) { float x2 = axis.x*axis.x; float y2 = axis.y*axis.y; float z2 = axis.z*axis.z; float a = (degToRad(angle))/2.0; float s = sinf(a); float c = cosf(a); float s2 = s*s; float sc = s*c; matrix rot = matrixIdentity(); rot[0][0] = 1-2*(y2+z2)*s2; rot[0][1] = 2*(axis.x*axis.y*s2+axis.z*sc); rot[0][2] = 2*(axis.x*axis.z*s2-axis.y*sc); rot[1][0] = 2*(axis.y*axis.x*s2-axis.z*sc); rot[1][1] = 1-2*(z2+x2)*s2; rot[1][2] = 2*(axis.y*axis.z*s2+axis.x*sc); rot[2][0] = 2*(axis.z*axis.x*s2+axis.y*sc); rot[2][1] = 2*(axis.z*axis.y*s2-axis.x*sc); rot[2][2] = 1-2*(x2+y2)*s2; return rot; }
  6. Rotation matrix multiplication causes Gimbal lock

    This is simply how a transform or rotation matrix works. The first row is the x (right) vector, the second row is the y (up) vector, and the third row is the z (forward) vector. At anytime, you can fetch these axes to perform local rotations. This is what I was referring to in my post. If I understand what the OP is trying to do, the issue here has nothing to do with Quaternions or Eulers or Gimbal or whatever. The issue is the axis around which rotations are performed. Perform y rotations as a regular world-space rotation. This will allow you to maintain a constant up direction. Perform the rest of the rotations in local space. Do these with a "rotationAboutAxis"-type function, where your axis parameter is the right or forward vector from your matrix. Something like this: //Y Rotation is a regular rotation yRotation = rotation(0, yAngle, 0); myMatrix = myMatrix * yRotation; //X and Z Rotations are done using the newly-transformed x and z axis from the matrix xRotation = axisAngleRotation(myMatrix[0], xAngle); myMatrix = myMatrix * xRotation; zRotation = axisAngleRotation(myMatrix[2], zAngle); myMatrix = myMatrix * zRotation;
  7. Rotation matrix multiplication causes Gimbal lock

    If you want to keep a constant up/down direction (ie gravity) then here's a simple trick I use: First, be sure to reset your rotation every frame. Then perform pitch (x) rotation first. Then do your roll (z) rotation in local space. And then perform the yaw (y-rotation) in world space.
  8. Computer Setup

    If I were building a new rig, I would focus on lots of RAM and a big HDD first and foremost. You want a decent GPU, but it doesn't need to be top of the line. I don't think the CPU should be much of a concern. My experience is skewed toward content creation as opposed to programming, hence my differing hardware concerns. Which brings up a good point - are you focusing on programming, game design, or game art? I think it would change your priorities.
  9. one man vs many men on a single tile

    I tend to agree with you. Lots of things on a single tile will likely become cumbersome and might require its own new interface to manage. I'd rather keep it simple and use adjacent tile combat.
  10. Turn-Based, SP, Combat-System Idea

    In general, I think it's a great start. The counter-switch mechanic sounds fun and the melee weapon range is a cool variation. I don't like the blood system because it's just another name for hit points and you said you don't want hit points. This does sound like it could be a very involved, tactical, and somewhat slow system, which means it should really be the central focus of the game rather than a secondary feature. It could almost be a purely turn based arena fighting game without any other game play.
  11. 3D Billboarding between two points

    OpenGL has built in functionality to draw points and lines as "billboards". Use glDrawElements with the GL_POINTS and GL_LINES mode
  12. Your thoughts on a Game Dev Podcast

    I would listen to this. I think it's a good idea. Have you done anything like this before?
  13. Help with Quaternion Based Mouse Movement (FPS Camera)

    No, Gimbal lock isn't an issue here. Gimbal lock is really only an issue when you are interpolating between keyframes. But you are explicitly setting a rotation every frame, so Gimbal lock never happens.
  14. Help with Quaternion Based Mouse Movement (FPS Camera)

    Glad it works now! No, this isn't silly at all. I do it all the time. But there are a couple other options that might work better for different situations (although I think your current method is the best for most situations). First, you could just stop clamping it. A rotation of 20,000 degrees is still valid and should still work. The only downside is that it's less readable (i have no idea what direction 20,000 is pointing). Eventually, in a really long session, numbers might also accumulate to the point where you start losing floating-point precision. The other option is to stop accumulating the rotation and only incrementally rotate the matrix. Right now your function resets the matrix every frame and then re-rotates it back to the desired rotation. Instead, you could stop resetting it and only rotate it by the delta yaw and pitch. Then you don't need to track the rotation separately at all. The only problem is that it now becomes more difficult if you need to reference the player's heading for some other purpose (like an overhead map view for example)
  15. Help with Quaternion Based Mouse Movement (FPS Camera)

    This sounds like the X rotation isn't happening in local space. Again, I'm not real familiar with GLM. It looks like GLM uses column-major ordering, so you need to swap the array indices for the vector in the X rotation part. Like this : m_mat4ViewMatrix = glm::rotate( m_mat4ViewMatrix, m_flFramePitch, Vector3f( m_mat4ViewMatrix[ 0 ][ 0 ] , m_mat4ViewMatrix[ 1 ][ 0 ], m_mat4ViewMatrix[ 2 ][ 0 ] ) ); The camera's forward direction is already baked into the matrix. The top left 3x3 set of numbers in the matrix is the rotation part. Which isn't nearly as complicated as it sounds. It just defines the X-Y-Z directions. The first row is the X-axis (left-right), the second row is the Y-axis (up-down), and the third row is the Z-axis (forward-backward). So at any time, you can just grab the third row of a transform matrix to get its "forward" direction. Something like : vec3( mat[0][2], mat[1][2], mat[2][2] )