A tweaked version of Handy to test Comlynx homebrew and some code examples

[+karri]

Sure. I will spend some time on this tomorrow. As you are using cc65 I can just write a test suite for the library.

[Nop90]

On 12/31/2019 at 7:48 PM, karri said:

Sure. I will spend some time on this tomorrow. As you are using cc65 I can just write a test suite for the library.

Any update?

 

I found that when the prolem happens the UART sets the RXoverun error bit.

 

 

[+karri]

Sorry, I totally forgot about this. Currently I am trying to understand the algorithm how they managed to use 20% less space for title sprites than my sp65 algorithm.

[Nop90]

@karri I found another problem with the serial driver when used for making comlynx games: sending and receiving seems to be unbalanced and if the master sends almost all the game data to the slaves, the slaves gets a music slowdown (probably because the serial interrupt interferres with the HBL and VBL interrupts).

 

This is a pity because for every other aspects the driver works really fine.

 

 

[+karri]

I am not suprised.

 

We could remove all the "sei" and "cli" commands. I did in On Duty to get sampled screams to work without slowdown.

 

The good thing is that it speeds up everything... Until you run out of stack and get a crash.

 

[Nop90]

I found a trivial but effective workaround: if the slave sends some fake data so that received and transmitted data in a frame are the same amount, the music remains in sync. It's a waste of bandwidth, but as long as the game speed doesn't suffer for it, it's acceptable.

 

With this fix Biniax2 should be ready for the release. 

[42bs]

32 minutes ago, Nop90 said:

I found a trivial but effective workaround: if the slave sends some fake data so that received and transmitted data in a frame are the same amount, the music

I am pretty sure commercial ComLynx games do it like this. Always send the same amount of data. Makes it also easier to calculate WCET.

[Songbird]

I agree, and did not realize that was not happening in Biniax during my testing (sorry nop90!). All Lynx games should transmit a packet every cycle whether or not there is meaningful data.

 

This is the same way Doom networking was set up on the original source code: you establish the order at init time, then during a game everyone listens to the traffic until it is their turn to transmit. Very simple but effective for a closed network.

[Nop90]

54 minutes ago, Songbird said:

I agree, and did not realize that was not happening in Biniax during my testing (sorry nop90!). All Lynx games should transmit a packet every cycle whether or not there is meaningful data.

 

This is the same way Doom networking was set up on the original source code: you establish the order at init time, then during a game everyone listens to the traffic until it is their turn to transmit. Very simple but effective for a closed network.

My protocol works the same, but client and server packets was of different sizes (the server sends the whole game state every cycle, the client sends only the keyboard values).

 

Adding dummy data to the client packet solved the problem.

 

With more than 2 players this is a big waste of bandwidth, so a better approach could be that at every frame the game logic is computed by a different element of the chain. this way after a complete round every node has the same amount of transmitted and received data.

 

I'll implement this solution in Lawnmower, where I plan to make connect up to 4 players.

[42bs]

On Isolation (SIMIS) I send the key presses and each Lynx handles remote key presses as if they were local.

T-Tris only sends data if something happens since there was no direct interaction

 

[Songbird]

Most games could get by with just send key presses. Maybe in some games where random data appears (next row of blocks), you'd have to send either a seed or the actual data to the 2nd player, but I agree that keeping the packets the same size probably makes it all much smoother.

 

In general I'd suggest sending as few bytes as possible, and relying on both Lynxes to compute the same results, instead of one Lynx sending large amounts of data to the other Lynx(es) in the chain.

 

 

[sirlynxalot]

This is an awesome development! Would be fun to do some multiplayer lynx via emulation. Maybe one day, online matchmaking for Zarlor Mercenary anyone

[sage]

Is there any progress on this?

[Nop90]

No because I read months ago that there was a rewriting of the code for cleaning global variables from the classes of the emulator.

 

If there is no update on the emulator code I'll back on this in autumn.

[sage]

ah. who wanted to do that?

[Nop90]

Can't remember, I should search in the old pists

[sage]

a pity that it only supports to cores and is not working with the epyx comlynx code ?

i really would need some better way to test and make

promo video

Edited August 10, 2020 by sage