I uploaded a bunch of pics from the VCF East XI event here
I uploaded a bunch of pics from the VCF East XI event here
I added a new media page to keep track of the photos, videos and t-shirts that I make while at different events
This is a new update
[best viewed in 1080p]
Hello, I promised some of you that I would give an update about this network game. The player screens are small cause the screenshot video extends over 2 monitors. I’ll have to make another video nex time with my tablet so I can zoom in closer. I turned off the soundfx and the collision detection for the explosion animation for now.
This is a new test of the Multi-Screen feature on this Multi-Player network game. After a few months of glitches and brain-farts, this is working. This is basically one step above Multi-Player. This allows you to interact with any player in this virtual world. The virtual world is 8x screens wide on the C64 = 2560 pixels.
One of the biggest glitches I came across was using Broadcast packets. The problem slowed me down for many months. That’s why it was only 90% done. All of the network communication is done with UDP. I found out eventually, that you can’t use a consumer grade network switch. Because they don’t let you provision the server port to prevent loopbacks. So the server was getting inundated with it’s own broadcast packets. Almost as if there was a DDoS on the server. So much so, the network lag in the game from the Server to the Players, it was as long as 2min – we had to time this to believe it smile emoticon So I switched backed to using unicast packets for now. Later in the year, I plan to return to using Broadcast packets when I change it over to a Peer-Peer network and use a pro grade network switch.
I still have another glitch with Players 6,7,8. The missile can only fly on 5 screens at the moment. There’s an issue with receiving packets on those players. And there’s some anomaly on the Y axis when the missile flies in each screen. There’s some jitter as if it’s dropping the LSB bit somewhere.
Just wanted to say that new updates are coming soon
I’ve been really busy the past year working on this new game
The game is about 90% complete.
The network code was the biggest chunk of work, with some big bumps along the way
It’s now running smoothly, with a more compact UDP communication scheme,
eg. no buffer copying
I just have to finish a few more things in the game code
It’s been too long since writing an update on Space Command.
But I’m getting closer. I have all of the networking issues straightened out except for one. There is some game code which needs to get finished still. I’m converting the Server network code to use Broadcast packets. Because this is using a C64 with a SuperCPU as the Server. It’s more efficient this way. This will be the first time for this.
Also this version will only work as a LAN game. This is one of the restrictions when using broadcast packets. Also I like to first see this network game work without any of the Network Lag issues when players are across the country, or ocean :)
And I’m compacting the networking libraries in NetLib64 to save space in memory. I save so much memory left over now that I will document the new Memory Map in the game’s design file. This is so to make room for bigger game code in the future. Such as adding more sprites, screens, etc. Before I have to swap files on the drive [uIEC/SD]. I’m hoping to get it running in time for the Vintage Computer Festival East in April.
It’s been along time since posting on here. This game has gone thru a complete rewrite of the code since last year. I took a cue from Leif’s 2nd network game made on the C64, NetRacer, after his 1st C64 network game Artillery Duel. Also, I made it so it runs with a C64 Server with with the SuperCPU cart plugin this time to get the extra horsepower to manage the server tasks.
Basically, I switched everything over to using Raster Interrupt Service code. As done with a lot of other computer games. But this time built into a Network Game. This is still using the TCP/IP stack from NetLib64 Library as in Artillery Duel and NetRacer. So all of the tasks used in the game are scheduled with different priorities using a round-robin technique. I managed to get 8 players to connect now [screenshot below]. But It seems its not 100% reliable yet — not sure why at the moment. Whether it’s because I’m using the VICE emulator or not running on actual hardware yet, still not sure why. This phase of the game still needs some more debugging.
BTW, the guys who developed NetLib64, have just released a new beta version of the current release. I haven’t used this one yet, mainly because the software interface is a little different form their previous version. Also the code was built using their new assembler, TMPx, Turbo Macro Pro cross-assembler. I’m still using the DASM macro assembler. So there’s going to be some conversion necessary to get this new TCP/IP stack plugged into my code.
The network connection is determined by a status byte in the packet message sent from each Player to the Server. I tried to have the players connect to the server in diff ways. The new server code will allow players to connect in any order now. So I tried with player 1 to connect first, another time with player 6 to connect first, etc. You can see the ‘X’s beside the ‘READY’ message for players 3 to 8. That’s the ‘No-Connect’ message. That wouldn’t go away even after those players connected to the server. As if it would lose connection for a split second and then connect again That’s why you see both the ‘X’ and the ‘READY’ message. Some of the ‘X’s on the screen would actually blink. This is from the action of printing the ‘READY’ message after a successful connection to the Server. That same Print message would erase the ‘X’ No-Connect message.
The extra columns of white characters in the far right of the screen are my debug codes. I use this to help debug the game-code together with the network library in real-time. I can view all of the functions called by the game and network library. This is used to supplement the VICE debugger.
This is a screenshot with the player’s game screen updated with the various sprites. And also on the screen, it shows the updated status information at the bottom. This has 8 sprites being used for each player’s screen. There are 6 city sprites, one Command Center sprite, and the Missile sprite. the missile sprite is shared with the Explosion sprites whenever one of the objects get hit. There are 2 types of explosion sprites used in this game. One is for typical hits on any object. then when an object is fully destroyed, there is the Nuke Explosion sprite to signify that the City is completely wiped out – or the command Center.
Here’s a first look at a screenshot of Space Command with 8 players connected to the C64 server. The game screen shows the command center in the middle with the cities beside it, with 3 on the left and another 3 on the right. similar to the ol’ arcade game from 1980, Missile Command. But now with multiplayer networking. This is still shown running a simulation for 9x C64 computers on my desktop. Each screen will be a separate C64 computer that each player will control. With the 9th being the C64 Server which manages the multiplayer networking.
The screen is in Multi-Color Char mode, and so I haven’t the optimum choice in colors at this point – versus Multi-color Bitmap Mode, but this consumes more memory. This is something to work on later once all the kinks are worked out of the game. Jeff Brace <Arkaxow72> helped work on the additional sprites and sound effects, So we will have sprites showing the damage, explosions, even a Mushroom cloud from a Nuke strike. And the sound effects will include things such as Red alert sirens when a missile is inbound, missile launch, and a cruising missile. There will be more sprites that will get added for gameplay. I plan to add the additional support for the players to take turns at the controls.
Getting to this point was an arduous process. With getting acquainted with the TCP/IP network code running on a 6502 CPU from 35yrs ago. And also getting the game code to fit together in only 64KB of memory. Now I have to make sure the missile they will launch can fly across all 8 computer screens without getting lost. And hope the radar screen in there helps to keep them on track too.
been a long while for an update,
Trying to get this project ready in time for the next event. So busy with updating the game code to add network support for 8 player. Here’s a screenshot of the latest[click below]. I have 9x instances of VICE running here, This shows all 8 players connecting to the C64server. Now that this is stable, I have to finish updating the rest of the game code. Still have 12 days left till VCF East 9.1
Tonight, I managed to get a test program running to check the functionality of the Multicolor Character mode. Using the export files from CharPad where I created the background screen, I was able to get the program to load these files properly and display the background screen perfectly. It took some extra work to finally convert that multicolor bitmap screen. But that’s because there isn’t really a clean or smooth method for converting between these two formats because of the color limitations. the current color scheme will get us going for now so we can finish the game code.
CharPad actually has you export several files from your design. But the documentation provided is a little ambiguous. It spends effort describing these extra features within the tools while the existing method is already what’s possible using the available export files. I had already made a test program using the original method for loading a screen using Character graphics mode. And I found out, after all, that the same method can be used with the export files from CharPad — besides what’s described in their docs. As you’ll see the test program, it’s using the same method as before – nothing fancy going on.
When exporting files from CharPad, there is a Character Set file which contains the Custom Characters and Tiles – which you can also create inside this tool. I used only 1×1 Tiles in this design. I have the test program load this data at addr $D800. Then a Map file which contains the Screen codes for the Screen Memory at addr $400. Also a Tiles Map and Attributes Map. At the moment, there is no need for these last two files. I’m trying to find more information as to what advantages there are to using these lookup tables. From what I see so far, you can make use of these to change the screen codes within the screen memory during runtime. Now back to the game code……