Great Exploitations

I still want the car sprite to be a VW bug! Is it possible to make a recognizable VW bug sprite using just 8x8 pixels? (Nathan? Are you reading this?)

 

Are you using both players for anything? If not, why not go with a 16x16 or 16x14 'bug' instead?

I can give it a shot, but more pixels is always better.

 

Is this 2LK or 1LK? If 1LK, could I make it taller (14 - 16)?

 

How many rotational positions does it need to have?

Are you using both players for anything? If not, why not go with a 16x16 or 16x14 'bug' instead?

The thought has crossed my mind. However, I don't want to use it just yet - I can see myself wanting the other player for a powerup, or even literally another player. I have thought of the possibility of seeing if I can add a multiplayer option with two 2600's connected via a DB9 straight-thru cable. I think that I just need to communicate a few bytes per frame to make this possible.

 

I can give it a shot, but more pixels is always better.

 

Is this 2LK or 1LK? If 1LK, could I make it taller (14 - 16)?

 

How many rotational positions does it need to have?

It's a 2LK (written in bB, actually!) If it looks horrible in 8x8 and I can't think of a good use for the second player, maybe 16x16... no promises.

 

The car has 16 positions, but I really only need 3 (0, 22.5 and 45 degrees.) For all other positions, I'll just mirror the sprite or rotate by 90 degrees.

Out of curiousity, I opened up Paintshop Pro to see what I could do with the 8x8 restriction. This is the best I could muster. My attempts at rotating the graphic were even worse!

 

 

8x8 is pretty restrictive for a rotating graphic. Increasing the size would definitely allow for something much nicer. The bug in the arcade was rather large on screen, wasn't it?

Out of curiousity, I opened up Paintshop Pro to see what I could do with the 8x8 restriction.  This is the best I could muster.  My attempts at rotating the graphic were even worse!  

 

 

8x8 is pretty restrictive for a rotating graphic.  Increasing the size would definitely allow for something much nicer.  The bug in the arcade was rather large on screen, wasn't it?

That sprite looks reasonable to me... the rotated ones are bound to look worse, but I'm still curious as to what can be done (my artistic abilities are nonexistent... everything I've tried looks like hell.)

 

In the original game it was something like 20x20 pixels, I think. However, my intent here is not to make a direct port of the game (if that were my goal, I wouldn't have much more work to do at all!)

The thought has crossed my mind.  However, I don't want to use it just yet - I can see myself wanting the other player for a powerup, or even literally another player.  I have thought of the possibility of seeing if I can add a multiplayer option with two 2600's connected via a DB9 straight-thru cable.  I think that I just need to communicate a few bytes per frame to make this possible.

 

Interesting notion. Using both players for the car would allow the use of same-colored missiles, or else a missile and the Ball, for other things, so using both players together might not be too bad. And of course 30Hz flicker would be an option.

 

As for communication, a suitably-wired cable would give each 2600 three "output" wires that would connect to "input" wires on the other, in addition to one bidirectional wire. An assymmetric wiring pattern would allow one machine to be designated the "master" and the other the "slave" (alternatively, the extra pin could be wired always-high for one machine and always-low for the other).

 

Suggested protocol.

 

Reduce each frame's data to a multiple of four bits. Sample:

 

01 -- Directional change (straight, left, right, or SPECIAL)

23 -- Fire button state and ??

45 -- ??

67 -- ??

 

If the directional bits are SPECIAL, then the remaining bits are used to coordinate action following a loss of communication. Otherwise most of the remaining bits wouldn't be useful for SuperBug but might be useful for other games.

 

During most of the frame, the master device will output high on the output to the other machine's fire button. At line 255, it will assert that pin and put bits 0 and 1 on the other two pins (which drive the slave's paddles). It will then wait one scan line for the slave to do likewise. If the slave does not do so, the master will go into a holding pattern, freezing the game on the current screen outputting 259 scan lines/frame until the slave makes its proper line-255 response.

 

The slave, when it reaches line 251, will wait up to eight scan lines until it sees a pulse come in. If it does, it should hit RSYNC and output the first two bits of its data. If it does not get an input pulse, it should give up and end up clocking out a 265-line frame. Note that since the master will speed up and the slave will slow down, they should sync up with each other within about 45 frames.

 

Once the first "ack" has taken place, the master should drive its fire button high and low with each pair of bits to be output and wait for the slave to acknowledge by doing likewise. This should happen pretty quickly.

 

If the game is fully determinstic, it shouldn't be necessary for the consoles to send each other anything but controller inputs. Because things might get out of sync, however, it would be good to have a means for the two consoles to send more detailed game state to each other. Otherwise if anything slips up it will be impossible to resume play.

Here's how the rotation ended up. I'm sure that Nathan could do much better.

 

 

BTW, the game looks awesome! I'll be watching this one closely.

Don't bet on it.

During most of the frame, the master device will output high on the output to the other machine's fire button.  At line 255, it will assert that pin and put bits 0 and 1 on the other two pins (which drive the slave's paddles).

Can the 2600 assert its own fire button, or were you talking about connecting a different pin to this? I can't find the 2600 paddle pinout so I am not sure if you are talking about this or if you're suggesting a custom cable. I'd rather not require a custom cable - few are going to go through the trouble of building one. But if comms can be done with an off-the-shelf DB9 straight-through cable, it has a much greater chance of actually being used. The master/slave is necessary, but it could also be done in software or via a console switch.

 

A straight-thru cable (as I see it) would give 4 connections (up/down/left/right) and connect GND-GND, so this should be adequate. Though I could have missed something - there could be something bad like a Vcc that I didn't see (even a Vcc might still be OK, or if not, it's much easier to just break off a pin than to make a custom cable.)

If the game is fully determinstic, it shouldn't be necessary for the consoles to send each other anything but controller inputs.  Because things might get out of sync, however, it would be good to have a means for the two consoles to send more detailed game state to each other.  Otherwise if anything slips up it will be impossible to resume play.

The game (at least the multiplayer portion) can be totally deterministic if it needs to be. However, sending just controller data requres that I do the (somewhat complex) movement calculations for two cars. I can if I have to, but if all I need to send/receive are the car X, Y and possibly another byte for various game state flags, this would save on cycles and RAM usage. Plus, by sending game data, the game has a smaller chance of screwing up if sync is lost for a frame here and there.

 

Your protocol appears to be fairly robust. I agree that full acknowledgement is a good idea and the way you suggested doing this with the 4 available bits should work fine.

 

Though I'm not sure how I feel about sending less/more scanlines here and there - it will result in screen jitter. If this can be avoided somehow, I'd rather sacrifice a little reliability. Plus, I wonder if the cable could reliably send data faster than one byte per frame? If the speed of one 2600 to another is really close, like 1%, maybe we could send faster with a series of tight polling loops (with some way to timeout, of course.) If comms fail, instead of slowing down we could just skip a frame, assuming we are sending game data instead of controller data.

 

I wonder if there are working examples of 2600-to-2600 comms being done before?

Can the 2600 assert its own fire button, or were you talking about connecting a different pin to this?

 

Three of the joystick directions from each machine would go to paddle+paddle+fire on the other.

 

I can't find the 2600 paddle pinout so I am not sure if you are talking about this or if you're suggesting a custom cable.  I'd rather not require a custom cable - few are going to go through the trouble of building one.

 

Hmm... the only common DB9 male to male cables are null modems, and one of those would NOT be good since it would connect +5 to ground (oops).

 

The game (at least the multiplayer portion) can be totally deterministic if it needs to be.  However, sending just controller data requres that I do the (somewhat complex) movement calculations for two cars.  I can if I have to, but if all I need to send/receive are the car X, Y and possibly another byte for various game state flags, this would save on cycles and RAM usage.  Plus, by sending game data, the game has a smaller chance of screwing up if sync is lost for a frame here and there.

 

Well, sending and receiving takes time. Using an approach like I described I'd plan on almost a scan line per bidrectional exchange of two bits, or four scan lines/byte. Doesn't take much before it becomes cheaper to just do the computations.

 

Though I'm not sure how I feel about sending less/more scanlines here and there - it will result in screen jitter.  If this can be avoided somehow, I'd rather sacrifice a little reliability.  Plus, I wonder if the cable could reliably send data faster than one byte per frame?  If the speed of one 2600 to another is really close, like 1%, maybe we could send faster with a series of tight polling loops (with some way to timeout, of course.) If comms fail, instead of slowing down we could just skip a frame, assuming we are sending game data instead of controller data.

 

Unless you want to have your kernel laden with communications routines that are even more complicated and annoying than reading paddles, the two machines need to have their screens in sync. If the slave machine hits RSYNC at the same point each frame, this will cause one scan line to be slightly overlong or short, but if that occurs just before VSYNC a decent monitor should be able to recover by the time displayed data starts again. The screens should only jump noticeably if communication is lost, and if that occurs it's necessary to run the two machines at different speeds to allow them to get back in sync (the bigger the speed difference, the faster they'll resync).

 

I wonder if there are working examples of 2600-to-2600 comms being done before?

 

Never heard of such a thing.

Hmm... the only common DB9 male to male cables are null modems, and one of those would NOT be good since it would connect +5 to ground (oops).

I haven't had a hard time finding straight-thru cables with the same gender on each end. I needed some a year or so ago and Radio Shack had them.

 

Even such, male-female straight thru cables and gender changers are common enough, so it still won't require any special skill if the actual cable is hard to find, even if it might look a little clunky.

 

The way I see it, the best choice is make use of a cable that is readily available. If a custom cable is needed, I would want to supply it with the game, but the prospect of building a bunch of cables is not particularly appealing to me. The fact is that few are going to build their own cables. This is the same sort of problem that arises with custom controllers.

The screens should only jump noticeably if communication is lost, and if that occurs it's necessary to run the two machines at different speeds to allow them to get back in sync (the bigger the speed difference, the faster they'll resync).

I see what you're saying. The utility here will depend on how frequently there are sync problems. Probably best for me to just implement it and see how it works in practice. I do not have a lot of free time with the playfield scrolling, but 4 scanlines might be doable.

Cool Project!

That 8x8 rotational stuff is nasty.

 

Here's my shot at it though:

 

 

Ick. It looks like a rotating blob of gum.

 

16 x 16 would look tons better.

 

Incidentally, you have to have 4 images for 16 positions: 0°, 22.5°, 45° and 67.5°. (You can use rotation to get 90° without problems, but you can't get 67.5° that way.)

Your rotation is smooth!

 

I was going to put my graphics into the ROM to see how it looked when I realized my first rotation didn't have enough frames. I added more in and sped up my animation to see if that helped much. It still looks like it's jerking back and forth a bit - not unlike static on a television set.

16 x 16 would look tons better.

 

Would be cool if it did that. The Arcade has that big sprite as well and after all it's not called "Bug" but "Super Bug"

16 x 16 would look tons better.

 

Would be cool if it did that. The Arcade has that big sprite as well and after all it's not called "Bug" but "Super Bug"

It's a question of aesthetics - what's better: A big, detailed bug with occasional flicker or a small, ugly bug with no flicker?

 

I'd be willing to at least make a binary with the large bug sprite if someone's willing to design one... But I don't want to waste anyone's time, so keep in mind that it may not make it to the final release.

I tinkered a bit with a 16x16 sprite. Unfortunately, I'm not a very good pixel artist, so I didn't bother to rotate the thing.

 

 

I wondered if there might be a way to make the bug more recognizable. Instead of drawing the car from directly overhead, I drew up a couple of sprites showing a sideview of the car, the front, and the back. The sideview isn't great, but it might look a little better stretched - if that is even possible to do while keeping the other angles at their regular size? Maybe the different view would make the 8x8 sprite easier to work with? I might give it a shot later.

 

 

Anyways, I'll throw this here for kicks. Yesterday I opened Hack-O-Matic and pasted my first set of sprites into the game. The result is laughable; It looks more like a bell than a car. (I hope you don't mind that I posted this. If you'd like me to remove it, let me know and I'll take it down pronto).

 

hacked

It's a question of aesthetics - what's better: A big, detailed bug with occasional flicker or a small, ugly bug with no flicker?

 

Big bug! Big bug! (Not to be confused with Dig Dug.)

 

I'd be willing to at least make a binary with the large bug sprite if someone's willing to design one... But I don't want to waste anyone's time, so keep in mind that it may not make it to the final release.

 

I've got one half-done. (I actually did the 8x8 one at 16x16 so I could work out the rotation.) I'll finish it up later tonight.

Added some rotation. There's still some jump... maybe I'll mess with it more later. If they aren't used in this project, perhaps someone would be interested in attempting a City Connect/CarVup type of game?

 

I vote for the big bug too

 

Would it make sense to have the car always flicker? Might be less annoying than "sometimes flicker sometimes not".

With a straight through cable you'd have to somehow designate one 2600 as the master and one as the slave. Hmm... maybe some kind of auto-detect based one which one powers up first? If P2joy=center, then I'm the the master, so set Up & Down to outputs and drive both low. If P2joy=not centre, then set left & right to outputs and drive both low. Then the master sees the slave and the two can start synchronizing.

 

My only worry would be possible consequences of tying the power and ground lines together and possible current loops due to voltage differences. Maybe a series resistor on pins 7 & 8?

Do you really have to do stuff like master/slave or a special protocol? Can't you just pass through the joystick movements and agree on a reset sequence?

 

Like when you press reset on one machine, it sends up/down/left/right on the next four frames and then both machines would start into a new game?

 

...have other 4 frame sequences for Variant select and stuff...

I'm just trying to avoid having both RIOTs set to output on the same pin.

Well, I have not much clue about hardware, but can't you just cross the wire-pin connections for both sides?

I'm just trying to avoid having both RIOTs set to output on the same pin.

Maybe to avoid this, after setting one as master, the other instantly would auto-detect its slave status (by polling the port) and disallow both being set as master. TO avoid setting both as master with the cable unplugged and then plugging it in, output mode would only be set for a fraction of a second, then if the master fails to receive an ack from the slave, it would revert to input mode.

 

As for the +5v being tied together, that does concern me too. Maybe instead of requiring resistors, I specify a straight-thru male-female cable with a gender changer. Then the end user can easily break off pin 7 from the cable with needle-nose plyers, or from the gender changer or both. Still much easier than making a custom cable.

 

Though I will do experiments at home with a few different 2600's to see how much current is sunk or sourced from a straight-thru. My guess is not much, as long as the 2600's 7805 and filter cap are working correctly.