Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualrip-off

Posted 16 September 2013 - 04:14 PM

ok, new update_all is coded.   but not hooked up yet.    one loop to rule them all.

 

here's what the new code looks like (CScript code).  i've added comments in red to make it easier to follow. i'll post the C++ translation output as well.

 

( since embedded code seems to clip messages of late, i'll just use font and color )

 

band member update all:

 


'   must call move_rafts first!       // i decided to store raft dx,dz and process them here with the rest of the updates
                                         //  so move_rafts must be called first to set raft dx,dz
fn v BMupdate_all
i a                                         // int a     loop counter     the band member number
4 a num_bandmembers                    // it now only iterates over active band members, not all band members (active or inactive).
    == cm[a].alive 0                       // here's the check for "is_alive".     if alive==0 continue.
        >>
        .
    '   do update stuff here - do global frame
    c BMdecrease_fatigue a                           // call BMdecrease_fatigue with "a" as a parameter.
    c BMmodel_attack a
    c BMmodel_surprise a
    c BMmodel_full_fatigue a
    c run_bandmember a
    c BMmodel_raft_movement a
    c BMmodel_paddling_fatigue a
    c BMmodel_falling a
    c BMmodel_sneak_detection a
    != frame 0                                        // if frame != 0 
        >>                                             // continue
        .                                               // end if code block
    ' do global second
    c BMmodel_fatigue_dueto_damage a
    c BMmodel_fatigue_dueto_encumbrance a
    c BMrun_quests a
    c BMclear_rockshelter_enccouter_flags a
    c BMcheck_rockshelter_encounters a
    c BMclear_cave_encounter_flags a
    c BMcheck_cave_encounters a
    c BMclear_hut_encouter_flags a
    c BMcheck_hut_encounters a
    c BMcheck_hut_takeover  a
    c BMcheck_climbing_animals a
    != second 0
        >>
        .
    '   do global minute
    c BMcheck_animal_encounters a
    c BMcheck_caveman_encounters a
    c BMmodel_intox a
    c BMextinguish_torches a
    == minute%7 0                                             // if (minute % 7) == 0
        c BMreduce_hygiene_dueto_movement a
        .
    == minute%10 0
        c BMreduce_water a
        c BMreduce_sleep a
        .
    == minute%15 0
        c BMreduce_food a
        c BMaffect_mood a
        .
    != minute 0
        >>
        .
    '   do global hour
    c BMmodel_dehydration a
    c BMmodel_food_spoilage a
    c BMmodel_exposure a
    c BMmodel_heatstroke a
    c BMmodel_drown_in_flood a
    c BMmodel_wearNtear a    
    c BMmodel_perm_shelter_raids a
    c BMmoodboost_nature_lover a
    == hour%2 0
        c BMmodel_damage_dueto_illness a
        .
    ? ((hour>7)&&(hour<19))                               // if hour > 7 and hour < 19
        c  BMcheck_quest_encounters a
        .
    != hour 0
        >>
        .
    '   do global day
    c BMmodel_starvation a
    c BMmodel_getting_sick a
    c BMmodel_background_radiation a
    c BMmodel_perm_shel_weathering a
    c BMzero_god_relations a
    c BMreduce_social a
    c BMmodel_traps a
    c BMmodel_skill_reduction a
    .                                                   // end for loop
.                                                     // end function definition
 

 

i'm thinking this gives me an opportunity to run side by side timing tests of the two loop layouts.      to see what the difference is.    results might be interesting.

 

so the next step is to make a version of run_simulation (whose code appears in a previous in this htread)  that does everything except the BMupdate_all stuff.

 

then hook the two versions of run_simulation up to a hotkey, add timers, and stir!  <g>.  

 

not sure how i'd call it.   the one big loop  eliminates a lot of iterator overhead.   but the loop bodies of the 99 little loops tend to be small and instruction cache friendly.

 

see what happens.....

 

 

i also implemented a "find first / find next" system for both active and alive band members, as a low overhead way to de-couple the iterator from the code being iterated.  that too has yet to be hooked up.    i should probably go back and see if some standard C++ data structure or template can do the same thing with no type check or other overhead.


#2Norman Barrows

Posted 16 September 2013 - 12:01 PM

ok, new update_all is coded.   but not hooked up yet.    one loop to rule them all.

 

here's what the new code looks like (CScript code).  i've added comments in red to make it easier to follow. i'll post the C++ translation output as well.

 

( since embedded code seems to clip messages of late, i'll just use font and color )

 

band member update all:

 

 

'   must call move_rafts first!       // i decided to store raft dx,dz and process them here with the rest of the updates
                                         //  so move_rafts must be called first to set raft dx,dz
fn v BMupdate_all
i a                                         // int a     loop counter     the band member number
4 a num_bandmembers                    // it now only iterates over active band members, not all band members (active or inactive).
    == cm[a].alive 0                       // here's the check for "is_alive".     if alive==0 continue.
        >>
        .
    '   do update stuff here - do global frame
    c BMdecrease_fatigue a                           // call BMdecrease_fatigue with "a" as a parameter.
    c BMmodel_attack a
    c BMmodel_surprise a
    c BMmodel_full_fatigue a
    c run_bandmember a
    c BMmodel_raft_movement a
    c BMmodel_paddling_fatigue a
    c BMmodel_falling a
    c BMmodel_sneak_detection a
    != frame 0                                        // if frame != 0 
        >>                                             // continue
        .                                               // end if code block
    ' do global second
    c BMmodel_fatigue_dueto_damage a
    c BMmodel_fatigue_dueto_encumbrance a
    c BMrun_quests a
    c BMclear_rockshelter_enccouter_flags a
    c BMcheck_rockshelter_encounters a
    c BMclear_cave_encounter_flags a
    c BMcheck_cave_encounters a
    c BMclear_hut_encouter_flags a
    c BMcheck_hut_encounters a
    c BMcheck_hut_takeover  a
    c BMcheck_climbing_animals a
    != second 0
        >>
        .
    '   do global minute
    c BMcheck_animal_encounters a
    c BMcheck_caveman_encounters a
    c BMmodel_intox a
    c BMextinguish_torches a
    == minute%7 0                                             // if (minute % 7) == 0
        c BMreduce_hygiene_dueto_movement a
        .
    == minute%10 0
        c BMreduce_water a
        c BMreduce_sleep a
        .
    == minute%15 0
        c BMreduce_food a
        c BMaffect_mood a
        .
    != minute 0
        >>
        .
    '   do global hour
    c BMmodel_dehydration a
    c BMmodel_food_spoilage a
    c BMmodel_exposure a
    c BMmodel_heatstroke a
    c BMmodel_drown_in_flood a
    c BMmodel_wearNtear a    
    c BMmodel_perm_shelter_raids a
    c BMmoodboost_nature_lover a
    == hour%2 0
        c BMmodel_damage_dueto_illness a
        .
    ? ((hour>7)&&(hour<19))                               // if hour > 7 and hour < 19
        c  BMcheck_quest_encounters a
        .
    != hour 0
        >>
        .
    '   do global day
    c BMmodel_starvation a
    c BMmodel_getting_sick a
    c BMmodel_background_radiation a
    c BMmodel_perm_shel_weathering a
    c BMzero_god_relations a
    c BMreduce_social a
    c BMmodel_traps a
    c BMmodel_skill_reduction a
    .                                                   // end for loop
.                                                     // end function definition
 

 

 

 

 

 

 

 

i'm thinking this gives me an opportunity to run side by side timing tests of the two loop layouts.      to see what the difference is.    results might be interesting.

 

so the next step is to make a version of run_simulation (whose code appears in a previous in this htread)  that does everything except the BMupdate_all stuff.

 

then hook the two versions of run_simulation up to a hotkey, add timers, and stir!  <g>.  

 

not sure how i'd call it.   the one big loop  eliminates a lot of iterator overhead.   but the loop bodies of the 99 little loops tend to be small and instruction cache friendly.

 

see what happens.....

 

 

i also implemented a "find first / find next" system for both active and alive band members, as a low overhead way to de-couple the iterator from the code being iterated.  that too has yet to be hooked up.    i should probably go back and see if some standard C++ data structure or template can do the same thing with no type check or other overhead.


#1Norman Barrows

Posted 16 September 2013 - 11:38 AM

ok, new update_all is coded.   but not hooked up yet.    one loop to rule them all.

 

here's what the new code looks like (CScript code):

 

( since embedded code seems to clip messages of late, i'll just use font and color )

 

band member update all:

 

 

'   must call move_rafts first!
fn v BMupdate_all
i a
4 a num_bandmembers
    == cm[a].alive 0
        >>
        .
    '   do update stuff here - do global frame
    c BMdecrease_fatigue a
    c BMmodel_attack a
    c BMmodel_surprise a
    c BMmodel_full_fatigue a
    c run_bandmember a
    c BMmodel_raft_movement a
    c BMmodel_paddling_fatigue a
    c BMmodel_falling a
    c BMmodel_sneak_detection a
    != frame 0
        >>
        .
    ' do global second
    c BMmodel_fatigue_dueto_damage a
    c BMmodel_fatigue_dueto_encumbrance a
    c BMrun_quests a
    c BMclear_rockshelter_enccouter_flags a
    c BMcheck_rockshelter_encounters a
    c BMclear_cave_encounter_flags a
    c BMcheck_cave_encounters a
    c BMclear_hut_encouter_flags a
    c BMcheck_hut_encounters a
    c BMcheck_hut_takeover  a
    c BMcheck_climbing_animals a
    != second 0
        >>
        .
    '   do global minute
    c BMcheck_animal_encounters a
    c BMcheck_caveman_encounters a
    c BMmodel_intox a
    c BMextinguish_torches a
    == minute%7 0
        c BMreduce_hygiene_dueto_movement a
        .
    == minute%10 0
        c BMreduce_water a
        c BMreduce_sleep a
        .
    == minute%15 0
        c BMreduce_food a
        c BMaffect_mood a
        .
    != minute 0
        >>
        .
    '   do global hour
    c BMmodel_dehydration a
    c BMmodel_food_spoilage a
    c BMmodel_exposure a
    c BMmodel_heatstroke a
    c BMmodel_drown_in_flood a
    c BMmodel_wearNtear a    
    c BMmodel_perm_shelter_raids a
    c BMmoodboost_nature_lover a
    == hour%2 0
        c BMmodel_damage_dueto_illness a
        .
    ? ((hour>7)&&(hour<19))
        c  BMcheck_quest_encounters a
        .
    != hour 0
        >>
        .
    '   do global day
    c BMmodel_starvation a
    c BMmodel_getting_sick a
    c BMmodel_background_radiation a
    c BMmodel_perm_shel_weathering a
    c BMzero_god_relations a
    c BMreduce_social a
    c BMmodel_traps a
    c BMmodel_skill_reduction a
    .
.
 

 

 

 

 

 

 

 

i'm thinking this gives me an opportunity to run side by side timing tests of the two loop layouts.      to see what the difference is.    results might be interesting.

 

so the next step is to make a version of run_simulation (whose code appears in previous a post)  that does everything except the BMupdate_all stuff.

 

then hook the two versions of run_simulation up to a hotkey, add timers, and stir!  <g>.  

 

not sure how i'd call it.   the one big loop  eliminates a lot of iterator overhead.   but the loop bodies of the 99 little loops tend to be small and instruction cache friendly.

 

see what happens.....

 

 

i also implemented a "find first / find next" system for both active and alive band members, as a low overhead way to de-couple the iterator from the code being iterated.  that too has yet to be hooked up.    i should probably go back and see if some standard C++ data structure or template can do the same thing with no type check or other overhead.


PARTNERS