Interaction with datatransfer for game programmers

[Timendus]

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!

[benryves]

For the sake of the platform, I'd have to pick method 1. Adding decent timing to a game is going to be tricky, so forcing each game to run at the speed of the slowest connected calculator to keep things in synch is probably the best way to do it.

[kv83]

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)

[benryves]

...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)...

On our TIs? Maybe I'm just underestimating the power of these machines.

[kv83]

...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)...

On our TIs? Maybe I'm just underestimating the power of these machines.

I think it hugely depends on the game, but It wouldn't be to hard to do

Code: Select all

if receive_data{
   processData()
}else{
   processPerviousDataAgain
}

Of course that's really something for fast-paced games. More "strategic" or "turnbased" games would obviously wait, that's why both methods are required...

[tr1p1ea]

I think it depends on the type of game as to what method should be used.

[Timendus]

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).

[DigiTan]

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.

[Liazon]

which ever's faster. I don't mind what as long as it's well documented, making it easier to learn.

[Timendus]

as long as it's well documented, making it easier to learn

That is absolutely a requirement

[Jim e]

I go with number 3, If you do it right it will be fast easy. Do it wrong and it would be slow and painfull.

[Dwedit]

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.

[kv83]

Yeah, but CLAP is for multiple calculators IIRC

On a sidenote: Gah it's Dwedit

[Timendus]

@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"

[kv83]

why not more than two?