Jump to content
  • Advertisement

JoeJ

Member
  • Content Count

    1401
  • Joined

  • Last visited

  • Days Won

    4

JoeJ last won the day on August 20

JoeJ had the most liked content!

Community Reputation

2979 Excellent

4 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. JoeJ

    Why Gaming in the Browser is Inevitable

    Maybe, but wouldn't this just accelerate the 'downfall of gaming'? We have franchises throwing out the same game again every year, more HD remakes than new innovations, exploding costs just to put more sugar on top, growing number of unsatisfied customers. I don't think we can afford the technical fallback caused by a total move to browser games at the time. Much more likely cloud gaming is the better alternative. It makes the same promises as you list on the upsides, but is backed by capable hardware and OS at least. It is however not clear if you include cloud gaming services to your vision of browser games, if you talk about gaming in general or just casual games, if you think browsers will replace consoles and PC. So it's hard to discuss that. For example, comparing a Nintendo console targeting families vs. PS4 with a very different audience can not be argument for an acceptable loss of performance when moving everything to browsers. As long as we can make progress in tech, i do not think that's the case. Because people still want graphics, physics, etc. to improve over time (which gives new options about gameplay too!) So there will be always something you can't compete against with browser games, and likely browser will not become the one and only gaming platform anytime soon.
  2. JoeJ

    make everything an object??

    I would say it goes much too far within the context you give. Likely oil has no functionality and is just data. The lamp has the functionality to burn oil so likely you implement it there (which brings us to the question: Do i need a lamp class at all or can i use a data driven approach configurable so stuff can emit light and consume oil?) Designing data coupled to functionality as OOP seems to intend only works if you already know how the end result should look like. And often you know this only from experience, guessing, or not yet at all. Some rules of the thumb that mostly work for me: If you are not sure if something deserves its own class, then likely it does not or not yet. If you can implement something just by data it is usually preferable. If the functionality processing the data turns out to be too complex or partially reusable, you can still divide it into multiple classes later on.
  3. This line already gives the angle, so no need to calculate magnitude later. But that's just an optimization. Pretty sure the NaN happens here if angle is zero: So you would need to return identity quaternion if angle is close to zero before that.
  4. One way to do it: If the user input is a quaternion, convert it to axis and angle. Convert axis and angle to a rotation vector: vec3 rv = axis * angle Project this vector to your constraint axis unit vector: vec3 constrained_rv = constraintAxis * constraintAxis.Dot(rv); Then convert result back to axis / angle: float angle = constrained_rv.Length(); vec3 axis = constrained_rv / angle; Then convert to quat or matrix or whatever you need: quat q; q.FromaxisAndAngle(axis, angle); So that's quite simple. I assume everything is given in global space, otherwise perform the operations in the local space of the joint for example. Ask if there's something unclear...
  5. JoeJ

    Angular velocity and water physics

    Yes, because the boat is more longer than wide, the clipped volume center can move forth and back more than sideways, so the torque can be larger accordingly. You could multiply the sideways dimension of your angular velocity in local ship space by 3 to fake this.
  6. JoeJ

    Angular velocity and water physics

    I hear you, but real boats get upwards automatically because their com is low under the water plane, so buoyancy would result in the expected behaviour without any hacking. But you might need the functionality to offset the COM form the geometrical center, which any physics engine provides. Or you model the boat using a compound of two bodies, a lightweight for the mast and a heavy for the bottom. What you want to do sounds like a good opportunity to do this correctly. It's quite simple and physics is so much more fun than graphics, also gameplay should benefit a lot. (The only lame thing here seems the need to clip a polyhedron, but you could use a bunch of spheres instead.)
  7. JoeJ

    Angular velocity and water physics

    The magnitude is angle per time unit (seconds, usually). Note that with this representation you can simply add multiple angular velocities (or torques) together, so no non-commutative rotation multiplication issues here(!). You might want to take a look on how buoyancy works: https://en.wikipedia.org/wiki/Buoyancy I assume a typical implementation is like so: Approximate the ship with a low poly convex hull (box would do); clip this box with the water plane; calculate COM and volume of lower half and add an upwards force at the clipped COM relative to volume. So the upforce would be this: vec upforce = volume * someConstant * vec(0,1,0); To apply an external force to a rigid body you calculate force and torque: vec lever = clippedCOM - body.centerOfMassPosition; // clippedCOM is the point of application of the force vec torque = lever.Cross(upforce); // because this point has some offset to the body COM, it causes some torque too body.AddForce (upforce); bodyAddTorque (torque); Usually you should not change velocities when using a physics engine. Imagine a box resting close to a wall and you add velocity that makes it pushing against the wall - the engine might not be able to calculate reaction forces to prevent penetration. It is better to add forces and torques instead altering velocities directly. But if you still want to control velocities in a simple manner without caring about physics, e.g. you want to make a PacMan game, this tool functions are very handy: vec ConvertLinVelToForce ( vec targetVel, vec currentVel, float timestep, float mass) { vec3 force ((targetVel - currentVel) * (mass / timestep)); return force; } So if you have a constant target velocity, this function calculates the necessary adjustment force to keep the bodies velocity constant too. To use it you would do this: body.AddForce( 0.3f * ConvertLinVelToForce ( pacman.targetVel, body.linearVelocity, 1/60, body.mass)); The damping factor of 0.3f is important to prevent oscillation / huge forces and the behavior depends of the value of your fixed timestep. For the angular part the math is a bit more involved because unlike mass inertia is not uniform relative to direction: vec ConvertAngVelToTorque (vec targetAngVel, vec currentAngVel, matrix4x4 &matrix, float timestep, float Ixx, float Iyy, float Izz) { vec torque = (targetAngVel - currentAngVel) / timestep; torque = matrix.Unrotate (torque); // rotate to local body space torque[0] *= Ixx; torque[1] *= Iyy; // apply nonuniform scale caused by inertia torque[2] *= Izz; torque = matrix.Rotate (torque); // rotate back to global space return torque; } If your engine stores inverse inertia matrix, the above could be compacted to a single matrix multiplication mostly, but this way it makes more sense i hope. So all this is not so specific to your question, but i guess it helps a lot with :) Edit: Using the 'add external force' math, you can easily model real boat motors or spaceship thrusters etc.
  8. JoeJ

    Do We Really Need Quaternions?

    If your actual problem is only to get original euler angle numbers back after turning them to a representation of rotation, then this can't be an argument against quaternions or for euler angles. Orientation has little (quats) or no information (matrices) about the rotation(s) which caused it, so what you want can only work within conventions and restrictions you define for yourself (e.g. limiting angles to 0-360, euler rotation order, assuming zero as initial state as you do). This puts your whole post into personal experience with some assumptions and impressions, which is not helpful for anyone (mostly beginners) to choose the right tool for the current job. Matrices, quaternions, axis and angle, rotation vector, euler angles - all of them are useful for 3D rotations, and nobody should shy away from any of them. Even if some are harder to understand than others, they are all useful and necessary at some point. Full understanding is optional anyways, otherwise quats would not be so popular
  9. There are some vertex shader 'decorations'? that make the math exactly following your code, so it's not possible the compiler reverses multiplication and adds for example. I do not remember details, but if you would use different vertex shaders you could try this.
  10. JoeJ

    DirectX 12 command queues

    I use timestamps before and after each dispatch, and it was not necessary to change anything here when using multiple queues (using VK not DX). You can use a really large number of timestamps and they still do not affect performance, so you can do it much more fine grained than just at the level of fences without worries. (Of course making it all optional with #ifdef)
  11. Ok, my mistake was the wrong '=' here: _ITERATOR_DEBUG_LEVEL=0, haha So i got it working, but it does not help (tried it years ago, as i remember now.) In release build my test takes 114ms, and with debug build still 5600ms. Unlike OP i almost never push but resize the vectors to known requirements before filling it with data, so memory alloc probably is not the problem either. It remains a mystery why MSVC STL is unusable with debug builds.
  12. Where do you set this option? I've tried to add '_ITERATOR_DEBUG_LEVEL=0' to the preprocessor definitions of my project, but i only get compile errors. ... could save me so much time i hope...
  13. JoeJ

    DirectX 12 command queues

    I talk about Vulkan here, but i assume it's the same for DX12... Yes. I have used 3 queues to test async compute, and all 3 of them process in parallel. I've tested this only with compute shaders (no rendering) and with AMD GPU. It seems while one queue is stalled when processing a memory barrier, the others keep working as expected. Also if the workloads are small, this is a good way to keep the GPU saturated. Downside is the need to do expensive sync across queues, and splitting to multiple command lists so all queues can be fed with work. Both have a recognizable cost. Keep in mind the case of 'automatic async compute', which happens even with a single queue if you have multiple dispatches but no barriers (so dependencies) in between. This is the preferred way, if possible (but it also gives confusing profiling results!). Be sure to check performance differencies across queues! (On AMD the graphics queue has best compute performance, the compute queues are likely thought for async stuff and for me they were two times slower. Not sure if that's similar in DX too.) No, but it depends on the hardware. I think Intel recommends to use only one queue at all and NV is traditionally limited with async compute too, but i don't know details. I'd be curious how RTX cards behave here. (If anyone knows...?) In any case you have to do manual sync across the queues to handle dependencies.
  14. JoeJ

    How to program smarter??

    Yes. But eventually since now both classes have an Enemy, there might be a more elegant way to handle this using the ECS system Unity is built upon. But i have no experience here... anyone? What seems wrong to me is the Attack function now being unaware if being a boss or a minion. There likely is a better way, probably obvious to people more familiar with Unity, ECS and gameplay code than me...
  15. JoeJ

    How to program smarter??

    If you want to avoid this completely the only way is to have one array for small minions and a second for large minions. So you have two Update functions too, each looping only over the appropriate enemy type and no others.
  • 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!