Ragooman

my corner of cyberspace =Dan Roganti

SpaceCommand – Wrap Around Missiles, Virtual World, 8x screens Wide —

Another quick update.

The one glitch is fixed allowing the missile to fly around the entire virtual world in either direction now. There’s enough power in the missile parameter to let you launch a missile and fly across 8 screens and land back on your screen. You might get dizzy looking at the video as I had to scroll the video recorder quickly from one edge of the virtual world to the other across the 8x screens. This way you can see the missile can fly continuously without any hiccups.

There is one minor glitch which seems to be random. I can’t seem to reproduce this glitch on demand. This one involves the collision detection. The missile sprite is shared with the explosion animation. So once a collision is detected, the code switches into the explosion animation. However, near the end of the video @2:20 there is a little hiccup. Once the collision is detected, the code is supposed to retain the current x/y coords to allow the explosion animation to center on the collision and begin. For a brief moment, The x/y coords for the missile are shifted upwards several pixels prior to the explosion animation. I’m not sure yet why this happens.

Several of the options coming next in the code include adding an offset to the power for the missile parameters. This allows you to avoid hitting your own cities if you attempt to launch a missile with a very low power input.

Another option is to shuffle the Missile sprite to make this sprite priority higher than the city sprites. As the Sprite-to-Sprite priority levels are fixed in the C64. Sprite# 1 is always higher than Sprite# 7. And the missile/explosion is share on Sprite# 7. This way the explosion animation will stay in front of the city letting you see the complete effect.

There’s one more option regarding the explosion animation. There will be different explosion animation for each direction of the missile. One for the left direction and right direction. So the animation will show the debris from the damage fly off in the same direction as the missile hits the city.

After this, I will start work on adding 8x missiles to fly in the virtual world. This may take some time before I add the next post.

This shows all 8x screens working in the virtual world now. There was a typo in the network code before and only the first 5x screens would receive packets. This is fixed. As you can see at the end I still have to turn on the wrap around code, just as in Asteroids. I left it disabled for now.

I linked the sprite damage code and the explosion animation code together in the virtual world. So now whichever city your missile will hit on any of the player screens, the damage is shown for that city. This is done by coordinating between the missile code from the player’s attacker screen and the collision code on the player’s target screen over the network.

And this is shown by changing the city sprite with a sprite having the incremental structural damage of the city building. There are 4 levels of structural damage for the cities. This is not counting the beginning sprite which has no structural damage. The same applies to any damage for the Command Center.

Also the explosion animation code is coordinated together with the collision code via the network. So now the explosion animation will run on any player’s screen in the virtual world.
At the moment there is no soundfx for the explosion. Please excuse the sound quality, the free version of Screencast doesn’t let me use the built-in soundcard – only the mic.


SpaceCommand – Missiles in Virtual World, 8x screens total —

Another quick update.
This shows all 8x screens working in the virtual world now. There was a typo in the network code before and only the first 5x screens would receive packets. This is fixed. As you can see at the end I still have to turn on the wrap around code, just as in Asteroids. I left it disabled for now.

I linked the sprite damage code and the explosion animation code together in the virtual world. So now whichever city your missile will hit on any of the player screens, the damage is shown for that city. This is done by coordinating between the missile code from the player’s attacker screen and the collision code on the player’s target screen over the network.

And this is shown by changing the city sprite with a sprite having the incremental structural damage of the city building. There are 4 levels of structural damage for the cities. This is not counting the beginning sprite which has no structural damage. The same applies to any damage for the Command Center.

Also the explosion animation code is coordinated together with the collision code via the network. So now the explosion animation will run on any player’s screen in the virtual world.
At the moment there is no soundfx for the explosion. Please excuse the sound quality, the free version of Screencast doesn’t let me use a microphone.


SpaceCommand Update – linked sprite damage and explosion animation to the virtual world —

Here’s another update.
I linked the sprite damage code and the explosion animation code together in the virtual world. So now whichever city your missile will hit on any of the player screens, the damage is shown for that city. This is done by coordinating between the missile code from the player’s attacker screen and the collision code on the player’s target screen over the network.

And this is shown by changing the city sprite with a sprite having the incremental structural damage of the city building. There are 4 levels of structural damage for the cities. This is not counting the beginning sprite which has no structural damage. The same applies to any damage for the Command Center.

Also the explosion animation code is coordinated together with the collision code via the network. So now the explosion animation will run on any player’s screen in the virtual world.

At the moment there is no soundfx for the explosion. Please excuse the sound quality, the free version of Screencast doesn’t let me use a microphone.


SpaceCommand – Multi-Screen feature added —

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.


SpaceCommand – new updates coming soon —

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


Space Command update —

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.


SpaceCommand – code rewrite – Screenshot with 8 players connected – C64 Multiplayer Network Gaming, cont’d… —

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.

SpaceCommand - 8 players connected to server - VICE

SpaceCommand – 8 players connected to server – VICE


SpaceCommand – Screenshot with Sprites– C64 Multiplayer Network Gaming, cont’d… —

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.
player1-sprites-background-v1