Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


#ActualNorman Barrows

Posted 15 September 2013 - 03:29 PM


typedef std::function< bool ( Caveman& ) > Filter_t;
typedef std::function< void ( Caveman& ) > CavemanUpdate_t;
IteratateCavemen( Cavemen& cm, Filter_t filter, CavemanUpdate_t update ) {
for( Caveman& c : cm ) if( filter( c ) ) update( c );
}So, the benefit of this is to get rid of that "if( active ) etc" stuff and move it to a helper class. So you can write something as follows:

struct UpdateFilters
{
static bool IsLiving( Caveman& cm ) {return cm.alive && cm.active;}
};

IterateCavemen( cavemenList, std::bind( &UpdateFilters::IsLiving, std::placeholders::_1 ), []( Caveman& c )
{
// Do your update code here.
} );
};

 

 

well that will nicely encapsulate the "filerting test" in a generic manner. however, "is_active && is_alive" is the only filter used, except in the render call where its just "is _active".

 

99 little for loops is probably inefficient, and is the root cause of so many changes being required.

 

but its fast enough for the moment, so maintainability and modifiability are the only reasons to refactor at this point.  

 

OTOH, it will probably need to go faster before its all over.   so i think i need to take a little time out, read up on code cache behavior, then decide how to refactor the loop layout (if at all), and THEN do the changes for "is_alive".

 

worst case, i know 99 little loops is the most cache friendly, and i just add "if (! cm[a].alive) continue;" everywhere.

 

best case, one big loop or "whatever is easiest to code and maintain" is sufficiently cache friendly, i refactor, then make my "is_alive" change in just three places (update, init, and render).


#1Norman Barrows

Posted 15 September 2013 - 02:57 PM


typedef std::function< bool ( Caveman& ) > Filter_t;
typedef std::function< void ( Caveman& ) > CavemanUpdate_t;
IteratateCavemen( Cavemen& cm, Filter_t filter, CavemanUpdate_t update ) {
for( Caveman& c : cm ) if( filter( c ) ) update( c );
}So, the benefit of this is to get rid of that "if( active ) etc" stuff and move it to a helper class. So you can write something as follows:

struct UpdateFilters
{
static bool IsLiving( Caveman& cm ) {return cm.alive && cm.active;}
};

IterateCavemen( cavemenList, std::bind( &UpdateFilters::IsLiving, std::placeholders::_1 ), []( Caveman& c )
{
// Do your update code here.
} );
};

 

 

well that will nicely encapsulate the "filerting test" in a generic manner. however, "is_active && is_alive" is the only filter used, except in the render call where its just "is _active".

 

99 little for loops is probably inefficient, and is the root cause of so many changes being required.

 

but its fast enough for the moment, so maintainability and modifiability are the only reasons to refactor at this point.  

 

OTOH, it will probably need to go faster before its all over.   so i think i need to take a little time out, read up on code cache behavior, then decide how to refactor the loop layout (if at all), and THEN do the changes for "is_alive".

 

worst case, i know 99 little loops is the most cache friendly, and i just add "if (! cm[a].alive) continue;" everywhere.

 

best case, one big loop or whatever is easiest to code and maintain is ssufficiently cache freindly, i refacotr, then make ny "is_alive" change in just htree places, (update, init, and render).


PARTNERS