[gameprogrammer] Re: Level triggered data synchronization
- From: Julien Pauty <jpauty@xxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Wed, 21 Apr 2004 09:46:48 +0200
Kevin Jenkins wrote:
>While working on my game I (now) consistently use a programming design
>that makes it easier to write and maintain code.
>
>I call it level triggered data synchronization. By level triggered I mean
>as opposed to edge triggered - data changes during processing rather than
>when the event to change the data occurs.
>
>The concept is quite simple. When you have a variable that you can set
>based on the current program state you should recreate the value for that
>data every cycle rather than setting that data on the conditions that
>directly modify it.
>
>For example, lets say you have a program where the user clicks on one of 3
>filenames and a bitmap shows up to display the filename chosen.
>
>To program this using edge triggered data synchronization, you would put
>code in the MousePress function. Depending on which filename was clicked,
>you immediately load that file and unload the older image if necessary.
>
>To program this using level triggered data synchronization, you would put
>code in the Render function. The render function would check the variable
>containing the index of which filename was picked. It would then compare
>this filename what Bitmap::Name() returns. If they are different, or if the
>bitmap is NULL, then load the new image.
>
>The second way is slightly less efficient because you are doing a comparison
>every frame. However, it is far more maintainable because if at a later
>point you add another place to show another image it will show the correct
>image for free. In the first case, you would either cut and paste the code
>to load the image or at best call a function, assuming (in the unlikely
>case) that you made this a function to begin with or put it in a function to
>avoid code duplication.
>
>Another benefit of the second way is you sometimes avoid processing. For
>example, lets say there were two places you could pick the same bitmap. If
>you picked the new bitmap that had the exact same path/filename as the old
>one,
>it would avoid an unnecessary load.
>
>In trivial cases both ways works fine. But in large classes with many
>variables this can cut down on a lot of code and maintenance. It also makes
>the program more maintainable if someone else has to work on it because they
>can change one section of the code and it just works - as opposed to working
>in some cases and not others. Of course when it takes a lot of processing
>to determine the state then stay with edge triggered. But in most cases
>it's as simple as checking a few pointers.
>
>I'm sure a lot of people know this. The reason I point it out is because I
>didn't strictly follow it before and now I do and have really seen the
>benefit.
>I think it's important enough to point out.
>
>
>
>
Interesting. As you point in your example, I think this is especially
useful in GUI programming. I will think about it and see if it can
improve the code of my current game project.
Thanks !
Julien
Other related posts:
