Medieval Mayhem - 2600

[bomberpunk]

You can play with a mouse to try it out, controls just not as good as with a real paddle.

 

"Trick shots"?

 

you know, the trick curve shots that are in 2600 warlords.

 

also, my mouse won't do diddly squat. is it because i'm using z26?

[+SpiceWare]

the "ghost player" effect? Sorry, that's not one of the features.

 

I use Macs so I'm not familiar with z26, but the readme has this in it

If z26 doesn't automatically support a game as a paddle game you must specify the -)PC or -(PC command line switches to get paddle support on the left or right Atari port.

 

If that doesn't work then check out Stella.

Edited December 14, 2006 by SpiceWare

[Uzumaki]

The ghost shot was present in the Warlords because the player's sprite remained in the game even if the player loses. But since the ghost was removed in MM, nothing doing.

 

It is fairly easy to know out the 2 adjourning castles if you move faster than the other player can and aim straight. Trying to knock out the one diagonally from yours is tricky. I've chewed through the castle but could never score a direct hit

[+SpiceWare]

Think I fixed the jitter. Let me know if you see anything wrong.

 

forgot something - BINs removed

Edited December 14, 2006 by SpiceWare

[bomberpunk]

the ghost shield isn't what i'm referring to, gang. it's the angled ghost "shot" that allowed orange/purple to attack each other and green/blue (in 2600 warlords).

 

more specifically, it's like a curveball attack in which you had to be in an exact position to do.

Edited December 14, 2006 by bomberpunk

[Big Player]

The ghost shot was present in the Warlords because the player's sprite remained in the game even if the player loses. But since the ghost was removed in MM, nothing doing.

 

I don't want to speak for Spiceware here, but I believe the ghost or trick shots are not included in MM because they are not present in the arcade game.

[+SpiceWare]

I understood exactly what you meant. Warlords still draws the dead players, just with the color black. Carla Meninsky added logic so if the ghost shield was hit it would have an effect, but one that was different than the normal shield collision.

 

Medieval Mayhem does not draw the dead players' shields - that's why you don't see them when the screen flashes. With nothing to hit, there's no deflecting off the ghost shields.

 

I suspect a big part of why the ghost shield was done was due to the limited angles the fireball can move in Warlords -it can travel in 8 directions, but mostly only travels in 4. A released fireball can travel left/right/up/down or 1 of 4 diagonal directions depending upon who you aimed at. Once it hits something, it always travels in 1 of 4 diagonal directions.

 

In Medieval Mayhem there are 32 different directions the fireball can move, and there's up to 3 of them in the air at the same time. Also released fireballs don't travel straight - they work just like the arcade version.

[+Nathan Strum]

It is fairly easy to know out the 2 adjourning castles if you move faster than the other player can and aim straight. Trying to knock out the one diagonally from yours is tricky. I've chewed through the castle but could never score a direct hit

I can take out the diagonal castle pretty regularly. There's one place where you can launch a fireball from that will get past him every shot, but the shot doesn't always bounce right once you're through the wall in order to hit the king.

[+SpiceWare]

I forgot to fix a bug espire8 noticed in the easter egg. I'm hoping this is it

mm20061213bNTSC.bin

mm20061213bPAL.bin

[+SpiceWare]

The ghost shot was present in the Warlords because the player's sprite remained in the game even if the player loses. But since the ghost was removed in MM, nothing doing.

 

I don't want to speak for Spiceware here, but I believe the ghost or trick shots are not included in MM because they are not present in the arcade game.

Actually CPU time is the main constraint. I specifically don't show dead shields so there's no collision to process. There's barely enough time to process the collisions without having a special "ghost" condition. The game's actually written not move a fireball that hit something if there is insufficient time to process the collision. At least 1 fireball collision is processed per frame, so a deferred collision will be processed 1/60th or 2/60th of a second late, which isn't noticable. Not a problem with PAL as there's plenty of overscan time to process the collisions.

 

The AI player routines also take longer to process when multiple fireballs are in the air(having to decide which one to track). There's not enough time to make a dead player move like it does in Warlords.

Edited December 14, 2006 by SpiceWare

[bomberpunk]

In Medieval Mayhem there are 32 different directions the fireball can move, and there's up to 3 of them in the air at the same time. Also released fireballs don't travel straight - they work just like the arcade version.

 

i'm sold.

[+SpiceWare]

Thanks!

 

made a couple animated gifs that cover the development history of Medieval Mayhem:

 

Main Menu

 

Game Screen

 

I fixed an out-of-sequence frame in the Game Screen animation. It was noticable because the scores shifted back to the top for a second.

[mos6507]

You can play with a mouse to try it out, controls just not as good as with a real paddle.

 

"Trick shots"?

 

you know, the trick curve shots that are in 2600 warlords.

 

also, my mouse won't do diddly squat. is it because i'm using z26?

 

If you study the coinop Warlords, the "trick shot" is actually a curve. The original 2600 version is just trying to simulate that, although it winds up looking like a bug. The reason the coinop is doing an arcing shot is because the fireball is supposed to be rotating, which generates "english". The fireball is rendered with a rotating tail on it. This doesn't translate to the 2600 that well because of the 2600's limited resolution.

[+SpiceWare]

The reason the coinop is doing an arcing shot is because the fireball is supposed to be rotating, which generates "english".

Hmm - never noticed that.

 

The fireball is rendered with a rotating tail on it. This doesn't translate to the 2600 that well because of the 2600's limited resolution.

The reason the fireball is not more detailed isn't the limited resolution but the limited number of sprites per scanline. I could have drawn the shields using the missiles and had really fancy looking fireballs, but then the shields would just be a square block.

 

If there were 2 things I could change on the Atari they would be adding 2 more sprites and 5 bytes for the playfield instead of 2 1/2.

[Cybergoth]

If there were 2 things I could change on the Atari they would be adding 2 more sprites and 5 bytes for the playfield instead of 2 1/2.

 

Same here. I always fantasized wether a 2600-on-a-chip could just double the TIA circuits; Copy&Paste, there you are. Heh, even 4 audio channels then!

 

No clue what efforts where required to *mix* the visuals though and obviously the (hardware) collission detection wouldn't work anymore...

[Mord]

If there were 2 things I could change on the Atari they would be adding 2 more sprites and 5 bytes for the playfield instead of 2 1/2.

 

Same here. I always fantasized wether a 2600-on-a-chip could just double the TIA circuits; Copy&Paste, there you are. Heh, even 4 audio channels then!

 

No clue what efforts where required to *mix* the visuals though and obviously the (hardware) collission detection wouldn't work anymore...

 

I'm sure clever use of sprites would probably allow sufficient hardware collision detection. For instance, just make sure P0 on both TIA's were drawing the player (or both Missile0's etc) then both TIA's would have the same thing to look for.

 

Of course this means you'd have twice the registers to update and we're all aware of how much time we have to update all the registers we currently have on time.

 

Myself I'd have added a register to HMOVE the playfield registers.

[mos6507]

If there were 2 things I could change on the Atari they would be adding 2 more sprites and 5 bytes for the playfield instead of 2 1/2.

 

Same here. I always fantasized wether a 2600-on-a-chip could just double the TIA circuits; Copy&Paste, there you are. Heh, even 4 audio channels then!

 

No clue what efforts where required to *mix* the visuals though and obviously the (hardware) collission detection wouldn't work anymore...

 

 

If you start enhancing the 2600 like this, you just wind up with the Atari 8-bit home computer. The only useful thing the 8-bit lacks is the sprite double/triple modes.

[mos6507]

The reason the coinop is doing an arcing shot is because the fireball is supposed to be rotating, which generates "english".

Hmm - never noticed that.

 

If you look closely you'll see the fireballs in the coinop look kind of like the firefoxes in Donkey Kong. They aren't circles. They have a tail on them.

[rjchamp3]

challenging game, harder then warloards

[supercat]

If there were 2 things I could change on the Atari they would be adding 2 more sprites and 5 bytes for the playfield instead of 2 1/2.

 

Having 40 bits of playfield data would be useful if and only if it were possible to write one or both halves simultaneously (easy to handle with address-decode logic). Otherwise it would as often be a hindrance as a help.

 

Had the designers sought to allow optimal use of the hardware, they could have included some fairly simple logic to allow for more effective access. In some cases, even dropping transistors could be helpful. For example, if they wanted to speed up code that wrote the same thing to COLUP0 and COLUP1, they could have set the mapping hardware so "0100x1" mapped to COLUP0 and "01001x" mapped to COLUP1. Address "010011" would write to both.

 

I would have liked to have seen two address each for many of the object enables; the LSB of the address would select whether to use bit 0 or 1. Bit 1 is good when PHP'ing the Z flag; bit 0 is good when PHP'ing or ROL'ing the C flag. One mux would handle all enable-related addresses.

 

As far as adding features, the biggest thing I would add would be some logic so that certain AUDCx values would only clock the audio once per scan line instead of twice. Right now many AUDCx values are duplicates of other ones and thus useless; adding four NAND gates would have greatly improved the 2600's sound capabilities, especially for music.

 

The other big thing I would add would be an extra bit on NUSIZx to disable cloning of the missiles.

 

The audio and missile cloning are things the designers might have foreseen as being future annoyances. Many other things that would have been nice were totally off the radar (no game had ever side-scrolled, so what would be the point of side-scrolling playfield bits?)

 

The feature I'm most curious about is why the designers put HMPx on bits 4-7 instead of 0-3? Does anyone have any idea?

[SeaGtGruff]

The feature I'm most curious about is why the designers put HMPx on bits 4-7 instead of 0-3? Does anyone have any idea?

The only thing that comes to mind is that it makes it easier to position a player/missile/ball using a lookup table, where the loop counter value for the coarse RESxx positioning is in the lo nybble, and the pixel shift value for the fine HMxx positioning is in the hi nybble:

  LDX player0_x_coord
  LDA position_table,X
  STA HMP0
  AND #$0F
  TAX
loop
  DEX
  BNE loop
  STA RESP0
  STA WSYNC
  STA HMOVE

But if that was what they'd had in mind, then you'd expect to see it done a lot in the old games-- and as far as I know, it wasn't used all that much.

 

Michael

[supercat]

But if that was what they'd had in mind, then you'd expect to see it done a lot in the old games-- and as far as I know, it wasn't used all that much.

 

And it's nowhere near as useful as the Battlezone technique (sbc #15), for which the HMPx high bits are a real nuisance.

 

I still think the HMOVE circuitry is a lot more complicated than it needs to be. I guess in those days the idea was to figure out something that seemed like it could work, rather than to keep fishing for the best design. There are many ways the HMOVE circuitry could have been simpler and better but there are also many logical things that could have been done (e.g. having a combined HMOVE/WSYNC address) that would have made it worse, so I suppose I shouldn't complain.

[SeaGtGruff]

But if that was what they'd had in mind, then you'd expect to see it done a lot in the old games-- and as far as I know, it wasn't used all that much.

 

And it's nowhere near as useful as the Battlezone technique (sbc #15), for which the HMPx high bits are a real nuisance.

One other thing that comes to mind is that the HMxx values are 4-bit signed values:

 

0000 = +0 = move left 0 color clocks
0001 = +1 = move left 1 color clock
0010 = +2 = move left 2 color clocks
0011 = +3 = move left 3 color clocks
0100 = +4 = move left 4 color clocks
0101 = +5 = move left 5 color clocks
0110 = +6 = move left 6 color clocks
0111 = +7 = move left 7 color clocks

1111 = -1 = move right 1 color clock
1110 = -2 = move right 2 color clocks
1101 = -3 = move right 3 color clocks
1100 = -4 = move right 4 color clocks
1011 = -5 = move right 5 color clocks
1010 = -6 = move right 6 color clocks
1001 = -7 = move right 7 color clocks
1000 = -8 = move right 8 color clocks

So with that in mind, maybe it just seemed more natural to put the sign bit in bit number 7?

 

Michael

[Zoyx]

Received my cartridge a couple days ago. Thanks!

[+SpiceWare]

Hope you enjoy it