Interaction with datatransfer for game programmers
Moderator: MaxCoderz Staff
Interaction with datatransfer for game programmers
As announced in the CLAP topic, I plan to make a version of link software especially aimed at programming fast games for two calculators. Now I want to know from you which method of receiving data you'd prefer:
Method 1: In my game loop, I call a routine that waits for data to be sent and receive it when it comes. Because both calculators run at approximately the same speed, and they need to exchange data all the time, they will synchronize nicely.
Method 2: In my game loop, I check for activity on the link port and only start receiving data when there's something to receive. I don't want to exchange data on every iteration of the game loop, so this saves CPU time but it will make my game run at relatively unpredictable speeds.
Method 3: I set up an interrupt routine that interrupts my game loop and calls a predefined address when data is received. This makes writing my game more complex and makes it run slower, but I won't have to do anything boring in my game loop.
It's your call, let me know!
Method 1: In my game loop, I call a routine that waits for data to be sent and receive it when it comes. Because both calculators run at approximately the same speed, and they need to exchange data all the time, they will synchronize nicely.
Method 2: In my game loop, I check for activity on the link port and only start receiving data when there's something to receive. I don't want to exchange data on every iteration of the game loop, so this saves CPU time but it will make my game run at relatively unpredictable speeds.
Method 3: I set up an interrupt routine that interrupts my game loop and calls a predefined address when data is received. This makes writing my game more complex and makes it run slower, but I won't have to do anything boring in my game loop.
It's your call, let me know!
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
- kv83
- Maxcoderz Staff
- Posts: 2735
- Joined: Wed 15 Dec, 2004 7:26 pm
- Location: The Hague, Netherlands
- Contact:
I must disagree with ben. Games need to run constituatly, and lag must be handled by the game itself. (For example, when it not receives any data of the opponent in a racing game, your game just pretends the other car drives in a straight line)...
Soo.. Method 2!
(It would be nice to have option 1 too, though)
Soo.. Method 2!
(It would be nice to have option 1 too, though)
- kv83
- Maxcoderz Staff
- Posts: 2735
- Joined: Wed 15 Dec, 2004 7:26 pm
- Location: The Hague, Netherlands
- Contact:
I think it hugely depends on the game, but It wouldn't be to hard to dobenryves wrote:On our TIs? Maybe I'm just underestimating the power of these machines.kv83 wrote:...and lag must be handled by the game itself. (For example, when it not receives any data of the opponent in a racing game, your game just pretends the other car drives in a straight line)...
Code: Select all
if receive_data{
processData()
}else{
processPerviousDataAgain
}
So, it's three against one against zero. I guess I'll implement these routines then:
Send[whatever]
Receive[whatever]
Swap[whatever]
CheckActive
[whatever] = Byte, Datablock, String, ...
So you could implement method 2 yourself with a little help from CheckActive, and the standard send/receive/swap routines are all blocking. Everyone agrees?
The only question that remains is if the blocking routines should time out or not. I could either add a timeout and a flag that tells the program that it has timed out, or wait indefinately untill a key is pressed, like the CLAP does now. Clear is usually a good one; if the game loop checks for key input directely after the data swap the keypress will echo through and exit the program (if the game uses Clear to exit of course).
Send[whatever]
Receive[whatever]
Swap[whatever]
CheckActive
[whatever] = Byte, Datablock, String, ...
So you could implement method 2 yourself with a little help from CheckActive, and the standard send/receive/swap routines are all blocking. Everyone agrees?
The only question that remains is if the blocking routines should time out or not. I could either add a timeout and a flag that tells the program that it has timed out, or wait indefinately untill a key is pressed, like the CLAP does now. Clear is usually a good one; if the game loop checks for key input directely after the data swap the keypress will echo through and exit the program (if the game uses Clear to exit of course).
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
I agree with the part about optional use of method 2.
If a link timeout occoured and I were doing any kind of real-time game, I'd favor a timeout flag. For anything turn-based, I'd say some kind of an escape key.
If a link timeout occoured and I were doing any kind of real-time game, I'd favor a timeout flag. For anything turn-based, I'd say some kind of an escape key.
My diet consists of nails, code-stealers, and HP fans.
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
That is absolutely a requirementLiazon wrote:as long as it's well documented, making it easier to learn
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
Bubble Bobble calls the link routines every frame, and still manages to be fast enough. It uses the link routine to replace the keypress routine basically.
Then again, you only need to send at most 8 bytes.
VTI's speed while linking a calculator is not the same as real calcs.
Then again, you only need to send at most 8 bytes.
VTI's speed while linking a calculator is not the same as real calcs.
You know your hexadecimal output routine is broken when it displays the character 'G'.
@Dan: PTI rules at emulating linkcables, I especially requested a version with multiple calculators wired together so I could realisticly emulate a calculator network, and I'm telling you it's as good as the hardware
@Jim: You just want to see me screw up
@Vincent: "a version of link software especially aimed at programming fast games for two calculators"
@Jim: You just want to see me screw up
@Vincent: "a version of link software especially aimed at programming fast games for two calculators"
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS