CombatWombat

Members
  • Content count

    303
  • Joined

  • Last visited

Community Reputation

673 Good

About CombatWombat

  • Rank
    Member
  1. I don't know if you're still having problems, but what you are describing sounds like a Trapezoidal Motion Profile. Maybe that search term will help you.    
  2. Discombobulated input callbacks

    I don't know.  What happens when the camera dies?  How does the dispatcher know to unregister that dangly pointer?  Seems like this just moves that responsibility to the camera object, which then needs to be reimplemented for every game object that registers functions to the dispatcher.  Unless I am misunderstanding.     How do you handle storing the objects (like the camera) in a container (std::vector or similar).  Doesn't that require a copy?   What is the alternative?  Are you saying that the entire Input->MapToActionsWithAContext->ActOnThoseActions model doesn't work well? Or are you saying that the final step of resolving the action via callback does not work well? How else does the game object act upon the action event?   Thanks to both of you.    
  3. I have made an input system based kind of on this: http://www.gamedev.net/blog/355/entry-2250186-designing-a-robust-input-handling-system-for-games/   I have my raw input -> context map -> actions.   I have a dispatcher / subject / observerable (whatever) that will do the notifying when actions are triggered. Implemented very roughly as: vector<*listeners> I have a listener which registers to the dispatcher to handle certain actions. It is implemented roughly as vector<*dispatchers> /// to automatically unregister on destruction map<actions, std::functions> /// function to call given an action, bound to *this with std::bind I would like to place this listener as a member of any game object which should do something with input. class Camera { Camera(); InputListener m_listener; } Camera::Camera() { dispatcher.register(m_listener, event::CAM_MOVE_LEFT); /// probably occurs someplace else, really. m_listener.addCallback(event::CAM_MOVE_LEFT, std::function<void()>(std::bind(Camera::moveLeft, this))); } Problem #1 I had to use std::bind to bring along the *this so that the callback can call the member function.  This isn't a problem unto itself until... ...The parent object is copied. The callbacks which are stored in the listener are now pointing to the pre-copied-object.  This means that any object which decides to have an inputListener as a member must implement a non-trivial copy constructor to rebind all the callbacks with the proper *this.  Kinda stinks of poor design.   I could make the member static, but then wouldn't *all* cameras move left when this callback occurs?   I'm overcomplicating this somehow.        
  4. Yet Another Rendering Queue Thread

      Going to try this.  Might do an index instead of the pointer for round one.   Apparently I'm kinda stuck with something like this.  I tried creating my own texture inheriting from the sf::Texture to add the texID integer in there. Then I started inheriting a new RenderStates type from sf::RenderStates.  But then painted myself into a corner because it's implementation uses an sf::Texture and there isn't really a way I can see to override that to use my type without reimplementing the entire thing.  Kinda hokey.     Yeah, I've seen that one.  Also there's a few good ones on LSpiro's page.  Good explanation of the concept, but not enough ideas for implementation for my programming inept skill level.    
  5. I've read everything I could find on these things, and I'm starting to implement this and questions are arising.  Sometimes I find typing all this out helps get my head in order...A lot of this might be duplicates of prior threads asked in a different way and much of it will be just plain hypotheticals...  Without further ado...   I am using SFML and want to sort by texture, and then by depth (really layer, since this is a 2d game).    So.  I can store all the sf::Drawables in a vector (that gets filled by the scenegraph/culling/whatever system). std::vector<sf::Drawable> allOpaqueDrawables; std::vector<sf::Drawable> allAlphaDrawables; Should these be pointers to the drawable which is instead stored in the game objects themselves?  Should there be a master list of all drawables in the game that "owns" them, letting both the game object and these "sub-drawables-within-the-scene" use pointers to this master list? Some other third option?     Now, I need to sort this.  So I can make a render queue which is just indicies into the vector of all drawables. I'm not positive how to implement this... a first try might be something like: std::map<sortKey, int16_t> renderQOpaque; std::map<sortKey, int16_t> renderQAlpha; // with sortkey being a POD integer type built from the texureID and layer value of the drawable I guess the idea is that the small int16 keys are the only thing that needs to be copied around to sort the map?   1) Is this a sane way of doing this part? 2) Is std::map a reasonable choice for the implementation?   Then the map can be iterated through taking the int16_t as indicies into the vector allDrawables to call draw() on each one.   A few problems: 1) Where to store and generate the sortKey, if it needs to be stored at all?        a) I need an integer representation of a texture.        b) (At least part of) the sortKey needs to be updated if the objects layer (depth) changes.   My texture storage assigns a unique integer ID number and prevents duplicates from loading.  Does it make sense to actually store this value in the texture?  Right now it is only kept in the texture storage (as a std::map<texID, sf::Texture>). I could inheret from sf::Texture and create a version that contains the texID.  Unnecessary?   SFML uses an sf::Drawable which contains the geometry to be drawn as well as the "rules" to draw it (actual draw() call). It also uses an sf::RenderStates which holds... 1) *Texture 2) *Shader (if used) 3) *Transform 4) BlendType   Since this RenderState holds damn near everything I need to generate the sortKey, it almost sounds reasonable to create my own RenderStates which derives from sf::RenderStates so that I can contain the sortKey in it and regenerate the sortKey anytime one of those three items are changed.  Yea/Nay?   I realize most of this is just my thinking out-loud/rambling.  Any feedback is appreciated.      
  6. Drag equation

    I would be inclined to treat the wing and tail as two lifting surfaces and then apply some NACA Lift & Drag curves. You could do a similar thing for the fusalage (treat it as a long-chord wing section). 
  7. Calculating pressure transfer between pipes

    If it's for a game, it's got to be a pretty strange game where the incompressible assumption causes problems.   If it's for an engineering problem, there are off the shelf products both paid and open to solve fluid problems.  Computational Fluid Dynamics code.   If it's purely to learn and play: When you lose the incompressible assumption it becomes simultaneously a fluid dynamics and thermodynamics problem.  You will need to learn about: Bernoulli / Energy equation Thermodynamic Properties The basic laws of thermodynamics   It's a big subject and it's hard to advise you more specifically without knowing where you are starting from.
  8. Modeling some flight physics.

    I think you're having a hard time because you may not be clear what your end goal should look like.  A well described question is halfway answered.   You say it's on rails.  But then you want to account for angle of attack and wingspan while having a constant force driving you forwards.  You seem to be creating a hodgepodge of rails and physics based behavior.  I caution that such a hybrid may create strange edge-case behaviors and may tend to be unintuitive.   Let's break this down to the simplest forces you need to fly.  Airplane, dragon, whatever. Lift, thrust, drag, gravity.   You can use simple lift coefficient for lift force. Its sounds like you want thrust to be constant forward.  You can use simple drag coefficients to get a drag force. Gravity is gravity.   For your rotional control you have 3 axis. Pitch, roll, yaw.   Here is where you need to better define your control scheme.  Should the triggers roll you directly?  Should they be mapped to angle of attack of left and right wings?  Should they be mapped to give an aileron effect (left wing down, right wing up)?  How do you pitch?  You need a tail.  Ditto for yaw. 
  9. Whats a good mathematical model for heat transfer?

    Start by thinking about it as heat energy, not as temperature. You can get temperature from the internal energy by having the mass and thermal heat capacity of the objects. The difference in temperature drives a flow of heat energy between the objects. A thermal resistance slows this flow.   It works like Ohms law.  (E=IR) But with thermal-ness it would be (T = QR) where T is temperature delta, Q is heat flow, R is thermal resistance.   How you calculate R is the crux of how complicated your system is!  For a simple "looks good enough" you can just base it on surface area of the objects in contact with a scaling factor.  For a more accurate effect, you'd have to deal with things like arriving at a convection coefficient which is brilliantly convoluted to calculate.  For round objects there are some natural logs that show up in the calculation of R.  There are Nussault numbers and Prandl numbers.  You can go nuts here.   Your specific example of heat transfer from oil->water is an example of a heat exchanger.   If you can be more specific about what you need to accomplish, we can advise you better.
  10. A Rose by Any Other Name...

      Hey, it's not entirely useless if you want to play with microcontrollers.     (Ok, most of them have C compilers these days...ahem...)
  11. Cars differentials, open, locked and preload

    First you need a more general description for the velocities.   A differential is a bevel gear implementation of a planetary gear train.  For an automotive type differential where the bevel gear ratio is 1:1, the velocities must satisfy: (VL - VH)/(VR - VH) = -1 where VL = left drive shaft velocity VR = right drive shaft velocity VH = housing & ring gear velocity   You can see the derivation of this here: http://books.google.com/books?id=QNj87rJZIpUC&pg=PA373&lpg=PA373&dq=KINEMATIC+EPICYCLIC+GEARING+DIAGRAMS&source=bl&ots=w9OLebHeMw&sig=1Ut2U15xCnXa53MPhdU8bEHbI_A&hl=en&sa=X&ei=RYZzU7HyHc6zsAT9-4H4DA&ved=0CDsQ6AEwAzgK#v=onepage&q=KINEMATIC%20EPICYCLIC%20GEARING%20DIAGRAMS&f=false (Or refer to any kinematics of machinery text)   Add up net moments on the components: The ringgear/housing has a moment on it from the pinion gear.  (This comes from your engine/transmission model). A reaction moment comes from the pin which mounts the center bevel gear. The center bevel gear in turn applies moments to each output shaft. The output shafts have reaction moments from the tire & brake models. The output shafts have reaction moments between them to enforce the velocity rule from earlier.   The various locking & lsd differentials add more forces/moments to these components.  Exactly which components are effected depends on the specific type. Simple example would be viscous style which has a locking effect as a function of velocity difference between the shafts. Add another moment to each axle.  Essentially (leftAxle Velocity - rightAxleVelocity) * someConstant.   To directly answer your question on "preload". Certain types of lsd utilize friction clutches to couple between the two output shafts.  Usually these are angled to be sensitive to the torque input to the differential.  "Preload" means that even with zero torque transmitted, there is still some coupling torque between the output shafts.    A good search term would be "torque in epicyclic gear trains".          
  12. Calculating arrival with soft turn (help!)

    I think this is similar to the "Piano Movers Problem".  It is motion planning / pathfinding with lot's of degrees of freedom.    This article touches on some of the methods (See configuration space part). http://www.gamasutra.com/blogs/MattKlingensmith/20130907/199787/Overview_of_Motion_Planning.php?print=1   Beyond giving you some search terms and links, I can't be much more help as this is kind of over my head, though...   Good luck.
  13. Anybody left from the 2003 crowd?

    Apparently I've been reading here on and off since... 2000?    And I still have no idea how to program myself out of a wet paper bag...
  14. How to solve oscillating spring

      The point P(t+dt) is your prediction of where you will be at the next time step.  If you draw a line from P(t+dt) to the track, making the line end up perpendicular (normal) to the track surface, that is essentially your "predicted" elevation. For example, you find this line and it's length is 5 units.  You want to maintain an elevation of 10 units.  You can now extend that line to make it 10 units long.  The new endpoint of that line becomes P(goal).  Now you just need to rotate your velocity vector to intersect with P(goal). This is very similar to what Lorenzo Gatti said with: "If the current velocity would cause penetration (downwards into the road), you can project the computed velocity along the tangent plane of the road."  Except that projecting the velocity vector will shorten it (slowing you down). Rotating the velocity vector will maintain it's length.  Both are valid options depending on what you want.   If you allow rotating your velocity vector both TOWARDS and AWAY from the track, you will get the "spline following" behavior. If you allow rotating your velocity vector only AWAY from the track, you will not crash into the track, but you will float over jumps normally.   If it were my game, I would go the extra step and compute forces needed to actually create this change in velocity and feed them to the physics engine just like any other force.  This isn't absolutely necessary, but I think it can help to avoid weird edge cases in behavior.