Chicago Faire redux.....

[matthew180]

Parallel ports are not designed to be connected together. That's why network cards were invented. Trying to work out the electrical details would be difficult, and in the end a one-off custom circuit. Parallel cables are also very limited in length.

All true, however it is possible to work out. I'm not too worried about about generalization of the design because I frankly don't see a lot of people throwing a "LAN" party at someone's house too often with TI's

 

You under estimate me! I would have a mandatory TI LAN party with some local friends. LAN ToD!!

 

That's probably a great way to go but will likely require some pretty technical programming on modern machines which I am not up to. I think I have a hard enough time understanding the ins and outs of the PIO port as it is

 

You could use a TI as the "server". The serial to [uSB / Ethernet] works just like the serial port on the 99/4A side of things. Also, I'd be willing to kick in some Unix based server assistance if you wanted. Heck, with a serial to Ethernet adapter, the games could be Internet based!

 

Matthew

[GroovyBee]

Heck, with a serial to Ethernet adapter, the games could be Internet based!

 

And cross platform :o

[unhuman]

We should just get Tursi to make Classic99 Kaillera friendly - if anyone is still developing that... Then we could have online indoor soccer battles.

[Opry99er]

Online indoor soccer..... jeez... that sounds just about as fun as watching astroturf grow.... BUT I'M IN!!!

[+Vorticon]

Parallel ports are not designed to be connected together. That's why network cards were invented. Trying to work out the electrical details would be difficult, and in the end a one-off custom circuit. Parallel cables are also very limited in length.

All true, however it is possible to work out. I'm not too worried about about generalization of the design because I frankly don't see a lot of people throwing a "LAN" party at someone's house too often with TI's

 

You under estimate me! I would have a mandatory TI LAN party with some local friends. LAN ToD!!

 

That's probably a great way to go but will likely require some pretty technical programming on modern machines which I am not up to. I think I have a hard enough time understanding the ins and outs of the PIO port as it is

 

You could use a TI as the "server". The serial to [uSB / Ethernet] works just like the serial port on the 99/4A side of things. Also, I'd be willing to kick in some Unix based server assistance if you wanted. Heck, with a serial to Ethernet adapter, the games could be Internet based!

 

Matthew

 

That would be a hoot!

As for the serial to Ethernet aspect, I guess I need to understand better how that would work from a connectivity standpoint. How would the TI server process all the information being sent to it from the slave consoles? How would it know which one is talking to it and how would it selectively talk back? I wouldn't mind any assistance you can provide here at all

[+InsaneMultitasker]

All right so that looks like 3-4 commits for next year. I'll definitely be there and plan on staying at the BW again. I'll have a game that might just melt your consoles down Only need a step up from Owen, Tim and others and we will be there .

 

The "Destroyer"........

Hey, isn't this like the Star Trek movies-- skip the odd ones

 

Let's see... maybe I could pick ya up for a road trip to Evanston. I do still need to drop that old rustbucket of a blazer off at your house, but that requires you to be out of town so I'll have to plan TWO trips. When ya leaving for that next vacation. hmmm...??????

[marc.hull]

All right so that looks like 3-4 commits for next year. I'll definitely be there and plan on staying at the BW again. I'll have a game that might just melt your consoles down Only need a step up from Owen, Tim and others and we will be there .

 

The "Destroyer"........

Hey, isn't this like the Star Trek movies-- skip the odd ones

 

Let's see... maybe I could pick ya up for a road trip to Evanston. I do still need to drop that old rustbucket of a blazer off at your house, but that requires you to be out of town so I'll have to plan TWO trips. When ya leaving for that next vacation. hmmm...??????

 

Ha..... If you are dropping off old red then that is what we are driving to Chicago next year. 50 gallons of gas, 100 quarts of oil and a bag of chips (potato not silicone .)

[Opry99er]

A step up, eh? Well, I'll tell you this... Now that I am in control of my own destiny (i.e. I have my own band and I set my OWN schedule) chances are better than good I'll be there. Let's get into April when I have a clear view of the rest of the year and I will commit. =) Obviously acts of God happen, but I have a feeling that this is the year. =) I will of course be presenting... I'm a ham, and can't stay out of the spotlight and off a stage, so I'll just need SOMETHING to demo. =)

 

Thanks to some great help from Karsten, Matthew and others, it looks like my XB RPG should be rolling along nicely very VERY soon. =). It won't be as nice as Realms of Antiquity, but it might rival Legends (if I can stay focused.

Edited December 8, 2010 by Opry99er

[matthew180]

That would be a hoot!

As for the serial to Ethernet aspect, I guess I need to understand better how that would work from a connectivity standpoint. How would the TI server process all the information being sent to it from the slave consoles? How would it know which one is talking to it and how would it selectively talk back? I wouldn't mind any assistance you can provide here at all

 

Aany client could be identified by its IP address. However, that does not work very well when multiple people are behind a single NATd router. Thus, it would probably be good to just have a new client make an initial "I need and ID" request to the server. The server passes back a new unique ID that it uses to identify the client from that point forward. Then, all requests after that from the client need to include that ID.

 

As for what gets sent to / from the client and server, that is totally up in the air. Your initial data protocol that you were thinking of for the parallel port would work. In the game loop, all clients send their *desired* location information. Once the server receives this information from all clients, it sends back *real* location information to all the clients.

 

This is not totally how online games work, but it is close, and this way everyone would stay in sync. But, a single client with high latency would cause everyone to suffer. So, each client could just send its desired location, then immediately receive real location that is as up to date as possible.

 

The desired vs. real location has to do with the server actually playing the game itself. When a client says "I'm at location x,y", the server sees if that location is valid before saying "ok" and sending your location to the other clients. This helps prevent cheating or illegal moves, but it also means the clients don't have to do location validity checking for all the other players in the game. The server is keeping track of where everyone is, bullets flying, who is shooting who, who is blowing up, where the monsters are, etc.

 

You will see this kind of thing in a modern MMORPG or FPS that is played online. You will be running, then all of a sudden you will be *back* a few steps. That's because you were running forward and your local client was rendering you running in the map, as well as sending your updated location information to the server. You local client always assumes its information is being received by the server. At some point there was probably some lag, and when it caught up the server said "no no no, *this* is where you really are", and your client updated your location based on what the server said. Thus you see a "jump" and all of a sudden you are back where you were 10 seconds ago.

 

It can all get very complicated no matter what physical network is used. For our retro systems, we want to keep the load on the machines as low as possible, so having a real server is probably a good idea (meaning don't use a retro computer for a server.) We also probably don't care as much about people modifying the code or network data to try and cheat (but we should always keep it in mind.) Maybe we can come up with a universal kind of game engine that does not restrict the kind of game being played, ie. you could use it to write just about any kind of game.

 

Lots to think about I guess. It *can* be simple, relatively speaking, since adding coordination and synchronization between even two computers adds a certain amount of complexity.

 

Matthew

[+Vorticon]

That would be a hoot!

As for the serial to Ethernet aspect, I guess I need to understand better how that would work from a connectivity standpoint. How would the TI server process all the information being sent to it from the slave consoles? How would it know which one is talking to it and how would it selectively talk back? I wouldn't mind any assistance you can provide here at all

 

Aany client could be identified by its IP address. However, that does not work very well when multiple people are behind a single NATd router. Thus, it would probably be good to just have a new client make an initial "I need and ID" request to the server. The server passes back a new unique ID that it uses to identify the client from that point forward. Then, all requests after that from the client need to include that ID.

 

As for what gets sent to / from the client and server, that is totally up in the air. Your initial data protocol that you were thinking of for the parallel port would work. In the game loop, all clients send their *desired* location information. Once the server receives this information from all clients, it sends back *real* location information to all the clients.

 

This is not totally how online games work, but it is close, and this way everyone would stay in sync. But, a single client with high latency would cause everyone to suffer. So, each client could just send its desired location, then immediately receive real location that is as up to date as possible.

 

The desired vs. real location has to do with the server actually playing the game itself. When a client says "I'm at location x,y", the server sees if that location is valid before saying "ok" and sending your location to the other clients. This helps prevent cheating or illegal moves, but it also means the clients don't have to do location validity checking for all the other players in the game. The server is keeping track of where everyone is, bullets flying, who is shooting who, who is blowing up, where the monsters are, etc.

 

You will see this kind of thing in a modern MMORPG or FPS that is played online. You will be running, then all of a sudden you will be *back* a few steps. That's because you were running forward and your local client was rendering you running in the map, as well as sending your updated location information to the server. You local client always assumes its information is being received by the server. At some point there was probably some lag, and when it caught up the server said "no no no, *this* is where you really are", and your client updated your location based on what the server said. Thus you see a "jump" and all of a sudden you are back where you were 10 seconds ago.

 

It can all get very complicated no matter what physical network is used. For our retro systems, we want to keep the load on the machines as low as possible, so having a real server is probably a good idea (meaning don't use a retro computer for a server.) We also probably don't care as much about people modifying the code or network data to try and cheat (but we should always keep it in mind.) Maybe we can come up with a universal kind of game engine that does not restrict the kind of game being played, ie. you could use it to write just about any kind of game.

 

Lots to think about I guess. It *can* be simple, relatively speaking, since adding coordination and synchronization between even two computers adds a certain amount of complexity.

 

Matthew

That's what I'm afraid of... I don't think we can realistically have a TI server do location checks and the like because it will slow things down quite a bit as it is doing work for 3 other consoles. I would prefer to have each individual console do its own checking locally in order to minimize the lag. What I'm going to do is code the protocol for a PIO network and test it out with just 2 consoles and see what issues come up for simplicity's sake. That way I can at least demonstrate a proof of concept. I'll add a third console if everything works out and go from there. If I hit major issues, then we'll look at the serial to ethernet option and I will definitely need your help here with the coding on the server side, likely a linux box. I have a PEB based system and another with a CF7, so I should be set. Does anyone here know if the CF7 parallel port is set up like the TI?

Edited December 8, 2010 by Vorticon

[Tursi]

If anyone becomes an expert at network gaming protocols, I do need an engine coded in XNA for the XBox I'll trade an OmniInterface when they come out.