Anyone think Ballblazer is possible on the 2600?

[+Andrew Davie]

I hope I'm clear.

 

Ever heard of "K.I.S.S"?

[roland p]

I hope I'm clear.

 

Ever heard of "K.I.S.S"?

Do you mean my way of exmplaning things, or my way of getting ballblazer on the 2600?

[Cybergoth]

I hope I'm clear.

 

If I got you, then all four objects would smoothly move up or down a scannline each frame?

 

They'd still have a 4 line resolution though and you'd plug sprite data into missille registers and vice-versa every 2 frames?

 

BTW: How many cycles for sprites do you have per line?

[roland p]

If I got you, then all four objects would constantly move up or down a scannline each frame?

 

They'd still have a 4 line resolution though and you'd plug sprite data into missille registers and vice-versa every 2 frames?

Yes, 4 line resolution. The data is zero-page memory and should be filled with the correct value. I precalculate everything.

 

BTW: How many cycles for sprites do you have per line?

 

It varies. about 5 to 10 cycles with the current method, very small, but the checkerboard is very cool with >2 colors so I want to keep it.

[Cybergoth]

BTW: Can you do something like:

 

Init: X = 0 or 1 or 2 or 3

Kernel:
LDA table,X
TAX
LDA somedata
STA GRP0,X

LDA table,X
TAX
LDA somedata
STA GRP0,X
...

table:
  .byte 1,2,3,0

[roland p]

BTW: Can you do something like:

 

Init: X = 0 or 1 or 2 or 3

Kernel:
LDA table,X
TAX
LDA somedata
STA GRP0,X

LDA table,X
TAX
LDA somedata
STA GRP0,X
...

table:
  .byte 1,2,3,0

Doesn't that take more cycles then:

LDX #0

LDA Data0

STA (POINTERA,X)

?

 

 

I've attached my source, so you can see what problems I am going through

 

At line 240 to 287 there are some precalulations of the checkerboard

 

At line 370 the first tile of the checkerboard is drawn, data is taken from ram (fastest)

At line 508 I have enough time to get the tile data from rom

 

Between every line you will see SLEEP ... for eating cycles, these can be replaced by sprite-code.

 

 

At line 1656 you will see PLAYFIELD_DATA for the tiles. The brown tiles will be stored here. (they are all green at this moment)

main_bitmapped.zip

Edited September 17, 2008 by roland p

[Cybergoth]

Doesn't that take more cycles then:

LDX #0

LDA Data0

STA (POINTERA,X)

?

 

True. I thought in comparison to the code passage you originally posted.

 

Even faster would be:

 

Entry1:
LDA Data
STA GRP0

Entry2:
LDA Data
STA GRP1
...

 

You would just enter the loop on 4 different entry points.

[vdub_bobby]

I use (zp,X) addressing in Elevators Amiss.

 

Let's see if I can dig up the code...

 

Okay, actually it was Squish 'Em, and I actually use LAX (zp,X)

MainKernelLoopInner;		15
lda PF1Temp
sta PF1
lda PF2Temp
sta PF2		;+12	27

lda (EnemyPtr,X)
sta GRP0	;+9		35		VDEL

lda PF4Temp
sta PF1
lda PF3Temp
sta PF2		;+12	48

dec EnemyPtr,X;+6		54

lda #BRICKHEIGHT
dcp BrickTemp
sbc #BRICKHEIGHT-2
sta ENAM1	;+12	66		VDEL



lda #PLAYERHEIGHT-1
dcp PlayerTemp
bcc DrawBlank1;+9		75
lda (PlayerGfxPtr1),Y
sta GRP1	;+8		 7
lda (PlayerClrPtr1),Y
sta COLUP1	;+8		15	
BackFromDrawBlank1

lda PF1Temp
sta PF1
lda PF2Temp
sta PF2		;+12	27

lax (EnemyPtr,X)
cmp #ENDMONSTERVALUE
beq MainKernelLoopOuter;+10	37

I'm pretty sure I posted the complete source somewhere, probably in the Squish 'Em thread, if you want to see the whole thing...

 

EDIT: (zp,X) addressing is useful when you need two separate indices and don't have time to switch Y around. Of course, having an addressing mode that worked like (),Y, except with X, would have been even better...

 

And, as supercat showed, it's a very useful addressing mode for 7800 development. The main limitation is that to use it as it was intended (i.e., with a big list, in zero page, of pointers) is that it eats up zero page memory in a hurry, which is generally a deal-killer on the 2600.

Edited September 17, 2008 by vdub_bobby

[mos6507]

Wow, this is some really exciting stuff. I can't wait to see if you can do the checkerboard. This looks really good even though it's just playfield because most of the diagonal borders are running horizontally. If you can spare the sprites you can selectively "fill in" one or two of the boundary lines that are running more vertically, but even if you don't do it, it's still more than acceptable.

[roland p]

Wow, this is some really exciting stuff. I can't wait to see if you can do the checkerboard. This looks really good even though it's just playfield because most of the diagonal borders are running horizontally. If you can spare the sprites you can selectively "fill in" one or two of the boundary lines that are running more vertically, but even if you don't do it, it's still more than acceptable.

Thanx,

 

The checkerboard that I posted a few posts ago, is not the one I'm going to use (Edit, I ment the bin, not the source). It's not possible to create the brown boundaries with that one. The one I use now can do create the boundaries, at the expense of a slightly smaller screen (black borders left/right).

 

I'm now working on the checkerboard and calculations for odd/even tiles. The checkerboard isn't really a playfield but just a routine that alters the backgroundcolor, when scrolling is needed, the routine just waits for one cycle at that line and the rest that follows is scrolled 1 cycle (3 colorclocks). It's even possible to create multicolored tiles, but I won't do that since the original ballblazer hasn't.

 

Using sprites is not possible, because moving sprites requires a WSYNC which makes my method unusable, unfornunatly.

 

I've just discovered that only one sprite at the time is displayed over the checkerboard in the original version. This sort of solves my sprite problem.

Edited September 17, 2008 by roland p

[roland p]

Small update, there are brown borders left and right! Scroll to the right and you will see.

The checkerboard is now 21 tiles wide, just like real ballblazer. I still have to work on complete tiles.

ballblazer.bin

[+Nathan Strum]

Excellent work! This really shows a lot of potential.

 

(I also like the unintentional "features" where if you scroll too far to the left you end up on a beach, and if you scroll too far to the right, you find a "second" playfield. )

[mos6507]

Excellent work! This really shows a lot of potential.

 

(I also like the unintentional "features" where if you scroll too far to the left you end up on a beach, and if you scroll too far to the right, you find a "second" playfield. )

 

I also wonder what other types of game engines you could use this for besides just trying to clone Ballblazer. We've got kind of the start of a SNES Mode 7 sort of thing going on. The trick is finding ways to overlay enough graphics on this playfield to do interesting things.

[+Random Terrain]

I also wonder what other types of game engines you could use this for besides just trying to clone Ballblazer. We've got kind of the start of a SNES Mode 7 sort of thing going on. The trick is finding ways to overlay enough graphics on this playfield to do interesting things.

Can I kind of go off topic for a second and ask if you've seen this semi-related thing made with batari Basic:

 

thing4.bin

 

It's from this post by SeaGtGruff:

http://www.atariage.com/forums/index.php?s...t&p=1580403

 

The original was made by atari2600land, but SeaGtGruff fixed it. So now batari Basic users will get to make some 3D scrolling games too, but they just won't look as cool as this Ballblazer stuff.

[Thomas Jentzsch]

A bit OT: I just downloaded some Ballblazer ROMs for the 5200 and C64.

 

The 1st ROM for the C64 I found was really disappointing (flickering lines), while the 2nd one looked pretty good (though not as good as the 5200 version). Any idea what's wrong with the 1st one? Maybe a homebrew attempt?

 

BTW: The Atari version does some kind of anti-aliasing between the squares. Clever!

[+Cafeman]

I remember reading a review with the developers back in the 80's, it might have been Electronic Games magazine, and they were proud of their anti-aliasing idea. Basically a 3rd color between 2 colors, right?

 

The 2600 version is impressive, although quite slow for actual gameplay. Never thought I'd see it look so authentic.

[Thomas Jentzsch]

I remember reading a review with the developers back in the 80's, it might have been Electronic Games magazine, and they were proud of their anti-aliasing idea. Basically a 3rd color between 2 colors, right?

Yup. They draw a thin line between squares with an intermediate color.

 

The 2600 version is impressive, although quite slow for actual gameplay. Never thought I'd see it look so authentic.

The speed is just defined by the programmer. You can have it as fast or slow as you want it.

 

As soon as Roland adds acceleration and inertia you will get the speed you want.

[roland p]

Noone mentioned the blackborders yet . They where needed because the engine got a bit more complicated in order to do something else than just creating a infinite checkerboard.

 

I also wonder what other types of game engines you could use this for besides just trying to clone Ballblazer. We've got kind of the start of a SNES Mode 7 sort of thing going on. The trick is finding ways to overlay enough graphics on this playfield to do interesting things.

I thought about games like trailblazer. A friend of mine made a spinoff in java:http://www.gagaplay.com/hypblazer/index.html This is indeed a sort of Mode 7 thing. all the tiles can have a unique colors, so it is texture mapped in a rough kind of way. I might add the antialias afterwards.

 

Can I kind of go off topic for a second and ask if you've seen this semi-related thing made with batari Basic:

That's looks cool. I did not know basic could be that clever. I want to do the same thing, but first I want to figure out how the math is, so I can do it 'right'. cd-w posted something similar to0.

 

I remember reading a review with the developers back in the 80's, it might have been Electronic Games magazine, and they were proud of their anti-aliasing idea. Basically a 3rd color between 2 colors, right?

That's what it looks like. I also saw antialiassing between green and brown tiles when you move forward to the border ahead of you. It looks really clever!

 

I've also found a Ballblazer page: http://www.langston.com/LFGames/

 

The 2600 version is impressive, although quite slow for actual gameplay. Never thought I'd see it look so authentic.

Thanks! The speed can be adjusted as Thomas mentioned. The screenupdating is now 60 fps, but it moves in small steps right now.

[Thomas Jentzsch]

That's what it looks like. I also saw antialiassing between green and brown tiles when you move forward to the border ahead of you. It looks really clever!

Because the horizontal "antialiasing" lines are simplier to process, they could be used to do some setup code for the next block.

[Thomas Jentzsch]

I think Ballblazer only has two sprites that overlap the board (the other player, and the goalposts)?

It think it is ok to draw the goalpost outside the board. So only the other player is left. This should make the sprite code pretty simple.

 

Thinking about it, if we could get away with using the ball for the other player (might become ugly), we could use the sprites and missiles for drawing a really smooth board. And the background color changes for filling the gaps.

[Thomas Jentzsch]

Further kernel brainstorming:

 

1. For the board, either use

a) PF graphics (slightly lower resolution, but easier to handle)

b) Repeated BK color writes (better resolution, but hard to handle)

2. Use all 5 or just 3 (BL, P1, M1) objects for smoothing the vertical lines. Use 3 in the vertical area where the other player's ship is visible. For the lines, you just have to calculate one vertical line. The other ones are moving at a fixed, relative speed.

3. Between the board rows, use a horizontal, "antialiasing" line with intermediate color. Since this one requires litte processing time, we could put some timeconsuming code (e.g. color switches) in here.

4. Use P1 (and maybe M1) for drawing the other players ship

5. Goalposts and the Plasmorb all drawn above the board so we don't have to care about them.

 

Here is a coarse example of point 2 (using 5 objects for smoothing, but even using just 3 objects should look still good). All 5 objects are 8 pixels wide. The 2nd picture gives a better impression after filling some gaps.

 

As you can see, most lines (except the most centered ones, which we will try to smooth) will become pretty much horizontally drawn, so a lower horizontal resolution should work well here.

Ballblazer001.bin

Edited September 21, 2008 by Thomas Jentzsch

[roland p]

Hi Thomas,

 

I think that using 2 missles and 1 ball would make things really smooth.

 

a) PF graphics (slightly lower resolution, but easier to handle)

Hi Thomas, how would you do the ceckerboard when using PF graphics? and are the brown borders still possible?

[Garak]

A bit OT: I just downloaded some Ballblazer ROMs for the 5200 and C64.

 

The 1st ROM for the C64 I found was really disappointing (flickering lines), while the 2nd one looked pretty good (though not as good as the 5200 version). Any idea what's wrong with the 1st one? Maybe a homebrew attempt?

 

The flickering was probably due to timing issues depending on if you were running NTSC Ballblazer on PAL C64 or PAL Ballblazer on NTSC C64.

 

Garak

Edited September 21, 2008 by Garak

[Thomas Jentzsch]

I think that using 2 missles and 1 ball would make things really smooth.

Then we would not have any color left for the other player's ship. So 1 player, its missile and the ball are the way to go here.

 

a) PF graphics (slightly lower resolution, but easier to handle)

Hi Thomas, how would you do the ceckerboard when using PF graphics?

I thought about a reflected PF, maybe using PF1 and PF2 only. Though I am not sure which solution will be better combinable with smoothing.

 

and are the brown borders still possible?

Not sure here too. Maybe a combined solution (2 color writes and 4-6 PF writes per scanline).

[Thomas Jentzsch]

The flickering was probably due to timing issues depending on if you were running NTSC Ballblazer on PAL C64 or PAL Ballblazer on NTSC C64.

I found out by now. The other version was done by some people called Crackman Crew.

 

http://noname.c64.org/csdb/release/?id=66670

Edited September 21, 2008 by Thomas Jentzsch