.png "English"){kind=small}
Actually I don't hate AppTime() I just don't like using it in some instances. Its extremely useful and from what I can tell a more accurate mechanism to use than AppSpeed().
Whilst working on Furious Frank, one thing I noticed and it always caught my eye, was what I term “Chorus Line Syndrome” where using the basic AppTime() frame incrementing code for looping animations results in a regimented animation playback for like models/characters. I have ignored this issue thus far as it was not such a big deal in the early stages. However I decided it needed to be sorted, rather than just left as this issue will no doubt crop up again and its always handy when problems do arise again to have a basic template solution. First I took the lua entity script for the bug and removed all dependence on AppTime() completely using AppSpeed() to adjust for running speed variations. This worked fine but still broke down under high stress tests. The only way I can simulate high stress is to run some background applications and Fraps. Of course some breakdown would come about when the stress is heavy. I then switched to using a mechanism that relied on AppTime() as the base, but not in the same way that it was used for the basic AppTime() frame incrementing code for looping animations. There was still some breakdown under heavy load but not as much as the AppSpeed() based script.
Utilising this script with other aspects to add extra randomness to same type character animation playback I made a few tests. The results are in the video below, in the first part the “Red Bugs” are running the original script and the “Blue Bugs” the new one. In the second half of the video I applied the template to some “Fast Horde” zombie AI I had been working on previously:
Some synchronisation still occurs but that's just inevitable given the constraints of the character models used, that is, how many frames per loop are used in a cycle of animation and indeed how many animation types per action there are. Even slightly interrupting the “Chorus Line Syndrome” has much nicer results. I added some small mechanisms to the “Fast Horde” zombie script to continually mix things up over time. But all in all I am much happier with the results than not having addressed it. There is still some translational movement patterns, like the "flying V" the Zombies exhibit in the video now and again, but I already have a solution involving types of same entity types to add a few extra parameters to help limit the occurrence.
As for Furious Frank, I'd like to say a big thank you to Paul Thomas for his contribution to this little side project. Paul kindly integrated into Furious Franks source code one of his older basic cloud and ToD (Time of Day) systems. It will need tweaking for the project but it was most generous. Heres a little look at the current stage of integration:
When more time is permitting I will continue with working toward a release of Furious Frank V0.03
The current version of Furious Frank can be found here:
Furious Frank V0.03
Previous entries for this project:
MAGIA .. Monday
MAGIA .. Monday ... and a little bit.
MAGIA .. Monday .. a little bit .. and beyond
Whilst working on Furious Frank, one thing I noticed and it always caught my eye, was what I term “Chorus Line Syndrome” where using the basic AppTime() frame incrementing code for looping animations results in a regimented animation playback for like models/characters. I have ignored this issue thus far as it was not such a big deal in the early stages. However I decided it needed to be sorted, rather than just left as this issue will no doubt crop up again and its always handy when problems do arise again to have a basic template solution. First I took the lua entity script for the bug and removed all dependence on AppTime() completely using AppSpeed() to adjust for running speed variations. This worked fine but still broke down under high stress tests. The only way I can simulate high stress is to run some background applications and Fraps. Of course some breakdown would come about when the stress is heavy. I then switched to using a mechanism that relied on AppTime() as the base, but not in the same way that it was used for the basic AppTime() frame incrementing code for looping animations. There was still some breakdown under heavy load but not as much as the AppSpeed() based script.
Utilising this script with other aspects to add extra randomness to same type character animation playback I made a few tests. The results are in the video below, in the first part the “Red Bugs” are running the original script and the “Blue Bugs” the new one. In the second half of the video I applied the template to some “Fast Horde” zombie AI I had been working on previously:
Some synchronisation still occurs but that's just inevitable given the constraints of the character models used, that is, how many frames per loop are used in a cycle of animation and indeed how many animation types per action there are. Even slightly interrupting the “Chorus Line Syndrome” has much nicer results. I added some small mechanisms to the “Fast Horde” zombie script to continually mix things up over time. But all in all I am much happier with the results than not having addressed it. There is still some translational movement patterns, like the "flying V" the Zombies exhibit in the video now and again, but I already have a solution involving types of same entity types to add a few extra parameters to help limit the occurrence.
As for Furious Frank, I'd like to say a big thank you to Paul Thomas for his contribution to this little side project. Paul kindly integrated into Furious Franks source code one of his older basic cloud and ToD (Time of Day) systems. It will need tweaking for the project but it was most generous. Heres a little look at the current stage of integration:
When more time is permitting I will continue with working toward a release of Furious Frank V0.03
The current version of Furious Frank can be found here:
Furious Frank V0.03
Previous entries for this project:
MAGIA .. Monday
MAGIA .. Monday ... and a little bit.
MAGIA .. Monday .. a little bit .. and beyond
