Arcade Joust for 2600

[doctorclu]

All and all, Atari 2600 Joust was not bad from the start. The way the characters move is fairly spot on. Landing, running. The way you fight other birds. And the way the eggs fly around actually makes it a more difficult game.

 

 

I've looked around for arcade efforts for Joust for the 2600. So far I've tried the regular Joust and vector Joust.

 

Vector Joust at least gave some more definition to the characters and what I play on the Atari Flashback Portable.

 

I've noticed there is also Dueling Borg and I came across a Dragon Joust as well.

 

So here's the question: If we can't get the eggs to land , can we at least add a better background? More like this from the 5200:

 

 

This question is for KevinMos3 and those that are great at character and background hacks like we've seen, for example, with the Popeye hacks which inspired this thread.

 

And if there is already a Arcade Joust project already going on for the 2600 please let me know.

 

[roryjr]

I'd like to see this, too.

[Arenafoot]

I'd like to see this, too.

I'll second that!

[doctorclu]

We've had 115 views and I'm pretty sure the people I wanted to see this thread have seen this thread by now.

 

So I thought about this and I came to realize why the background enhancements that is being done for Popeye would not work here.

 

Simply put, Popeye has about what? Four screens? I count the hearts, musical notes, and then the ship level. I might be forgetting one.

 

And Joust has.... ???

 

You start off with all the islands and a few of them disappear and reappear. You'd need to have where the lines would disappear and the background to match.

 

I'll need to play both Jousts to see how much 2600 Joust actually followed the level progression for starters.

[doctorclu]

More thoughts and research as I played through all the types of Joust.

 

 

Here we have the release of Joust. I noticed the platforms are not on the screen quite right. This is really weird for what I'd find out later. But as you can see, where you should be able to fly from the bottom of the screen to the top on both sides of the middle platform, here you encounter obstacles. Blah.

 

 

Vector Joust is the same since it was hacked from the release version of Joust. The top middle platform is just too wide.

 

 

 

This is a prototype of Joust I found from somewhere. This actually has the platforms with a better ratio than the other two versions. I have this next to the Atari 800/5200 version screenshot to show the comparison. On this one you can fly to the right or left of the middle platform with no interruptions and that was the way it was in the arcade version too.

 

What's better, the assembly code came with the prototype!

 

Joust (07-05-1983) (Atari - GCC, Mike Feinstein, Kevin Osborn) (CX2691) (Prototype).zip

 

Now I'm just going to post this out of fun but also for what needs to happen:

 

 

This is Joust Neo, a hack of Sir Lancelot which is a fun game, but it has what the current Joust does not: a good backdrop. And not just one, but several depending on the level.

 

I'm going to play the prototype version, see if the levels change like the arcade does. From what I've seen for about seven levels it is fairly close.

 

After that, there seems to be several scenarios called into play:

1) A screen with all the platforms.

2) A screen with the upper middle platform missing

3) A screen with all the upper platforms missing.

4) A variant of number 1, but with no lava exposed at the bottom of the screen on the sides (early levels).

(There may be others but you get the idea)

 

So you create four backdrops to display in the background depending on the platform arrangement. These would be placed behind the active platforms making them look more like floating islands than just lines.

 

-ALSO-

 

Since the assembly code is there, and since there is gravity that effects all characters including your character, why not the eggs too? They should fall and come to a stop just like you do.

 

As I played the Prototype, the game is otherwise spot on with the hit engine, the flying, the sounds. A really well done 8K game. But we have 16K and 32K games now so some room for a few background screens.

 

What we need to do next:

 

Get screen shots of the levels of the prototype version. We got someone that can play about 99 levels? Or we can set about 20 levels and just have it loop.

 

Same for the Arcade version get level screen shots.

 

Then take a look at the assembly code and see how to insert some backdrops. And see what programs I need to draft some backdrops.

Edited February 10, 2017 by doctorclu

[doctorclu]

Research:

I asked some questions on bankswitching playfields.

 

Got some good answers but then I thought about it afterwards: adding a background that did not interact with the game would be a bit confusing here. If only the upper line would interact with the character, then the character could fly underneath the top of it, and it would look like the character was phasing into the lower part of the island.

 

So what might be better to do is just draw more lines below the existing lines or platforms to thicken them up and give them more of a island look.

 

Currently looking into DASM and see if I can get a version running on my Mac.

 

As for this prototype version, I did see that the platforms changed at the second level when they really change around the 6th level for the first time. But then I got to thinking this was probably a way to test the changing of the level without too much play time.

 

I also took screen prints of the first 21 levels of arcade Joust watching a Youtube video.

 

Edited February 12, 2017 by doctorclu

[doctorclu]

Currently getting to know DASM and thanks to Nukey we found that in the prototype Joust code there was one line out of place. I've added the assembleable code here:

 

JOUST5JU.asm

 

Now at the very least I am want to look at the code and see if we can apply the same rules of gravity to eggs as we do a bird when it is not flapping or falling.

 

A player in the game when no flapping happens falls to the nearest platforms. That is what we want to have happen here. So is it me or did they not add gravity to eggs? I looked through the source and the rules of gravity are not as obvious to eggs. Is it possible they ran out of room and just let the eggs float around when created?

[+SpiceWare]

I bet they let the eggs float around because once a number of them land on a platform the flicker would become unbearable.

[doctorclu]

I bet they let the eggs float around because once a number of them land on a platform the flicker would become unbearable.

 

Well with Joust, at least in the early levels, you get like a bird or two or three, you land on them, and the bird is replaced with an egg. So you still have the same amount of items on the screen.

 

And that said, I would like to see eggs fall like everything else in the game.

 

I tried to study an object that falls when a cliff is removed or dissolves:

 

GPSKP98A LDX #1 ;SETUP PLAYER INDEX

 

GPSKP98B LDA STATES,X

AND #$60 ;IF PLAYER FLYING

BEQ GPSKP98D ;SKIP CLIFF EXISTENCE CHECK

 

STX TEMP0

LDA GENERALS,X

AND #$7 ;GET CLIFF NUMER INTO X

CMP #1

BNE GPSKP98C

 

CPY #2

BNE GPSKP98D

 

LDA XPOS,X

CMP LEFTSM4

BCC FLYTRANS

CMP RIGHTSM1

BCS FLYTRANS

 

LDA #0

STA GENERALS,X

BEQ GPSKP98D

 

And apply that into what appears to be the EGGDROP speed:

EGGDROP LDA SPEED,Y

EOR #$4

STA SPEED,Y

RTS

 

But I broke stuff.

 

Doctors-Air:bin doctorclu$ dasm joust5jug.asm -f3

 

joust5jug.asm (2261): error: Branch out of range (-1842 bytes).

joust5jug.asm (2268): error: Branch out of range (-1842 bytes).

joust5jug.asm (2270): error: Branch out of range (-1847 bytes).

 

Fatal assembly error: Source is not resolvable.

Doctors-Air:bin doctorclu$ dasm joust5jug.asm -f3

 

joust5jug.asm (2261): error: Branch out of range (-1842 bytes).

joust5jug.asm (2268): error: Branch out of range (-1842 bytes).

joust5jug.asm (2270): error: Branch out of range (-1847 bytes).

 

Fatal assembly error: Source is not resolvable.

Doctors-Air:bin doctorclu$ dasm joust5jug.asm -f3

 

joust5jug.asm (2255): error: Branch out of range (-1803 bytes).

joust5jug.asm (2261): error: Branch out of range (-1842 bytes).

joust5jug.asm (2264): error: Branch out of range (-1817 bytes).

joust5jug.asm (2268): error: Branch out of range (-1842 bytes).

joust5jug.asm (2270): error: Branch out of range (-1847 bytes).

joust5jug.asm (2274): error: Branch out of range (-1835 bytes).

 

Yeh, trying to understand where they talk about how players fall and how eggs fall. Any pointers will be appreciated.

[doctorclu]

In the dissolving cliff example I didn't realize initially there was a GPSKP98A, GPSKP98B, GPSKP98C, and GPSKP98D. I pasted in the code for EGGDROP to see what would happen and changed GPSKP98B to EGGDROP. Unfortunately with my farsightedness I read the GPSKP98D and thought that was a B at the end. So GPSKP98D were also named EGGDROP. And well, no A or C were defined. And it broke naturally.

 

But I think the dissolving cliff example shows how something will drop when it suddenly appears (like an egg does) when there is no platform underneath it. So just need to see how GPSKP98A, GPSKP98B, GPSKP98C, and GPSKP98D all work.

 

GPSKP98A LDX #1 ;SETUP PLAYER INDEX

GPSKP98B LDA STATES,X
AND #$60 ;IF PLAYER FLYING
BEQ GPSKP98D ;SKIP CLIFF EXISTENCE CHECK

STX TEMP0
LDA GENERALS,X
AND #$7 ;GET CLIFF NUMER INTO X
CMP #1
BNE GPSKP98C

CPY #2
BNE GPSKP98D

[+SpiceWare]

So you still have the same amount of items on the screen.

It's not the # of items that matters for the flicker so much as the vertical separation. You can see that in my 50 sprite demo for Space Rocks. Worse case flicker for full-screen was 12 Hz, which is 5 objects drawn using same player. That's the same as the worse case scenario for Ms. & Jr. Pac-Man (all 4 ghosts and special object in same vertical zone).

 

If I restricted vertical range (to simulate the convergence of the robots in Robotron) the worse case was 5.5 Hz - 11 objects drawn using the same player.

 

Same would happen with the eggs - they'd converge onto a small number of platforms (especially later in the game).

[xybot67]

Personally, the floating eggs never bothered me. I always thought that it added to the challenge. Better platforms would be a welcome change though.

[doctorclu]

It's not the # of items that matters for the flicker so much as the vertical separation. You can see that in my 50 sprite demo for Space Rocks. Worse case flicker for full-screen was 12 Hz, which is 5 objects drawn using same player. That's the same as the worse case scenario for Ms. & Jr. Pac-Man (all 4 ghosts and special object in same vertical zone).

 

If I restricted vertical range (to simulate the convergence of the robots in Robotron) the worse case was 5.5 Hz - 11 objects drawn using the same player.

 

Same would happen with the eggs - they'd converge onto a small number of platforms (especially later in the game).

 

Makes sense. So how did they make Space Invaders non-flickery?

[ZackAttack]

Space invaders uses triplicated players to generate 6 sprites without flicker. That's why each row of aliens is the same exact graphic.

 

In stella simply press alt+, to enabled fixed debug colors. Then you can see which object is used to draw what. alt+z and alt+x can be used to enable/disable P0 and P1 respectively. That also makes it easy to tell what came from where.

[doctorclu]

Space invaders uses triplicated players to generate 6 sprites without flicker. That's why each row of aliens is the same exact graphic.

 

In stella simply press alt+, to enabled fixed debug colors. Then you can see which object is used to draw what. alt+z and alt+x can be used to enable/disable P0 and P1 respectively. That also makes it easy to tell what came from where.

 

Certainly makes you appreciate how "easy" they made it look to have columns and columns of invaders what seemed like so effortlessly.

[+SpiceWare]

Using NUSIZx to duplicate and triplicate the players like in Space Invaders is one way to make more eggs appear with less flicker. There's limits to where those copies can appear though, see slides 13 & 14 in my presentation and note the spacing between the copies.

 

In order to use this technique you'll need RAM to hold the NUSIZx values and time in the kernel to read that RAM and update NUSIZx.

 

johnnywc used this to significantly reduce flicker in Scramble. On the fly it determines if duplicate or triplicate mode can be used. In this screenshot the 4 rockets still on the ground are drawn flicker-free by using both players set for duplicate mode.

 

The layout of objects on each level was slightly altered from the original arcade layout in order to take advantage of this reduction in flicker - ie: a pattern like this:

RRFF

---

where R = rocket and F = fuel, would flicker as the objects are right next to each other while copies must be spaced apart. One altered layout to reduce flicker would be this:

R R F F

---

Another alternative layout would be to do this:

RFRF

---

 

[keebz]

I would LOVE to see an Arcade Joust for the 2600... Regular Joust is my favorite 2600 game, seeing an arcade hack would be amazing.

[Nukey Shay]

Space invaders uses triplicated players to generate 6 sprites without flicker. That's why each row of aliens is the same exact graphic.

The first sentence is correct. The second, not so much. Most games use some variation of triplicated sprites to display 6-digit scores (each sprite can be unique)...and the timing is loose enough in Space Invaders itself that they can all be different shapes (Coke Wins! demonstrates this). For multiple identical shapes, a program could hit a horizontal position register a number of times within a scanline to produce more than 6 (like the 7 bug formation in Galaxian). Both examples are not without their own limitations, tho...which may be a worse compromise than the existing flickered and floating eggs.

[LeChuck]

Regarding Space Invaders - it does indeed update GRPx on the fly for each individual invader in a row (it must do this, since any one could be shot or showing a death animation frame). It also interweaves P0 and P1 to give more time for the updates - i.e. P0 P1 P0 P1 P0 P1, hitting GRP0/GRP1 alternately. I haven't seen the Coke Win! demo, but given enough code/data/time between rows you could certainly have individual bitmaps.