Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 May 2000
Offline Last Active Feb 24 2016 11:32 AM

Posts I've Made

In Topic: Discombobulated input callbacks

18 November 2015 - 09:26 AM


Is there a reason you can't register the camera function as a listener directly? I.e.

dispatcher.register(std::function<void()>(std::bind(Camera::moveLeft, this)), event::CAM_MOVE_LEFT);

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.




Don't allow the object to be copied or moved. These kinds of delegate-like callback systems kind of rely on having immovable objects.

How do you handle storing the objects (like the camera) in a container (std::vector or similar).  Doesn't that require a copy?


The other option is to just not use the delegate-like callback model. I find they work especially poorly for input anyway once you get to non-trivial games and game UIs (e.g., layering of menus, interrupted inputs, loss of window focus, etc.) as gameplay often has to deal with interaction models that are very very different from the traditional desktop models where delegates work well.

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.



In Topic: Yet Another Rendering Queue Thread

14 July 2014 - 07:02 PM

Personally, I would have something like
struct DrawableKey { u32 sortKey; Drawable* item; }; vector<DrawableKey> renderQ;
and then use std::sort to sort the vector using the key. If the vector contains thousands of items, then a radix sort / counting sort might be faster.


Going to try this.  Might do an index instead of the pointer for round one.



You just need different textures to have different integers. Different textures already have different pointers, so you can use some ugly code to convert a pointer to an integer:
Texture* texturePtr = ...;
ptrdiff_t texturePtrAsInteger = *(ptrdiff_t*)&texturePtr;

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.



If you haven't already seen it, I found this to be very useful for queuing and sorting draw calls: http://realtimecollisiondetection.net/blog/?p=86.  As he draws the scene, he fills an array with key value pairs where the key is the sort key and the value is a pointer to the draw call data like described by Hodgman above

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.



In Topic: Drag equation

13 June 2014 - 08:35 AM

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). 

In Topic: Calculating pressure transfer between pipes

30 May 2014 - 12:27 PM

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.

In Topic: Modeling some flight physics.

16 May 2014 - 07:08 AM

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.