Reply to Re: Dink Smallwood v1.08 Beta 3
If you don't have an account, just leave the password field blank.
January 7th 2006, 01:01 AM
toa
"I'm a network guy and not a programmer per se, but in the real world, flushing means to purge, but committing means to keep."
The first Rule of C Club: If you expect X, you're wrong.
Flushing, in the context of streams, refers to the buffering of output. Disk latency issues makes it faster to store the output in memory until it can all be written to disk. Hence, "flushing the output buffer (by committing it to disk)".
As for how input works, it depends. Some systems buffer the input, but some don't. If I remember correctly, DirectInput has an array that represents the keys and the keyboard has to be polled to check its current state. Thus, no actual buffering. The problem I was describing can be better explained as a doctor's office which admits everyone in the waiting room at the top of the hour and vaporizes everyone in the waiting room at half-past. What happens if you show up at 2:15? (Or, to put it more generally, a race-condition. It took me some thinking to realize that's what I was describing.)
"Is there not a way for an application to recognize when it is no longer the active application, i.e. when Alt-Tabbing to windows?"
Yes, windows will send the app a message. Dink tried to recognize this, and I think I might have fixed it in unDink. The problem might be caused by not checking the appropriate global variable when processing input. (I only think I fixed it because I rewrote the input handling before I knew there was a problem and subsequently didn't consider it a problem.)
The first Rule of C Club: If you expect X, you're wrong.
Flushing, in the context of streams, refers to the buffering of output. Disk latency issues makes it faster to store the output in memory until it can all be written to disk. Hence, "flushing the output buffer (by committing it to disk)".
As for how input works, it depends. Some systems buffer the input, but some don't. If I remember correctly, DirectInput has an array that represents the keys and the keyboard has to be polled to check its current state. Thus, no actual buffering. The problem I was describing can be better explained as a doctor's office which admits everyone in the waiting room at the top of the hour and vaporizes everyone in the waiting room at half-past. What happens if you show up at 2:15? (Or, to put it more generally, a race-condition. It took me some thinking to realize that's what I was describing.)
"Is there not a way for an application to recognize when it is no longer the active application, i.e. when Alt-Tabbing to windows?"
Yes, windows will send the app a message. Dink tried to recognize this, and I think I might have fixed it in unDink. The problem might be caused by not checking the appropriate global variable when processing input. (I only think I fixed it because I rewrote the input handling before I knew there was a problem and subsequently didn't consider it a problem.)
