Anyone think Ballblazer is possible on the 2600?

[mos6507]

Any ideas on how to display 2 players and 2 missiles?

The goals are always going to be above the checkerboard when you're looking straight at them, though. So if you just don't display them when looking sideways, then can't you just use separate '2 player + 2 missile' and '2 player + checkerboard' kernels?

 

Why can't a couple color-coded squares indicate the goal zone? Maybe you wouldn't have posts when viewed from the side, but with the squares, that would be good enough.

Edited October 13, 2008 by mos6507

[roland p]

Why can't a couple color-coded squares indicate the goal zone? Maybe you wouldn't have posts when viewed from the side, but with the squares, that would be good enough.

 

But that would be quite different from the original ballblazer. The goal scrolls smoothly from side to side, and the game progresses, the goals are getting narrower too.

[LS_Dracon]

Hmm....

Ball?

Every time you hit RESBL another ball is created. But it's need another huge kernel to set all positions for the two parts.

 

Edit :

...

ldx BallPosA

ldy BallPosB

SetBallPosA

dex

bne SetBallPosA

sta RESBL

SetBallPosB

dey

Bne SetBallPosB

sta RESBL

 

Not a smooth solution, though...

Edited October 13, 2008 by LS_Dracon

[Ben_Larson]

I think that's an elegant solution. I'll try it.

 

Actually I think you'll need to do 2 players + ball + checkerboard...because you have to display the game ball too, right? There's a trick you can use with the stack pointer to display the ball which doesn't take many cycles though, although the one constraint is that the ball is a constant height. Here's an example which assumes that Y is being used as a line counter:

 

; before kernel
LDX #$1F
TXS

...

; in kernel
CPY BallYPosition
PHP
PLA

...

; after kernel
LDX #$FF
TXS

 

I used this in 'Incoming' after someone on the stella list (don't remember who) pointed it out to me.

 

Ben

Edited October 13, 2008 by Ben_Larson

[roland p]

@LS_Dracon,

I think I'm going to use the ball just for the ball and the missiles for the goals.

 

@Ben_Larson,

That's a nice trick. The compare sets the bit (pushed) needed in the ENABL ($1F) register if I understand correctly.

 

 

There are now 3 kernels:

1. Sky, Ball, 2 Missiles (only sets them) and 2 players

2. Variable height brown border, displaying 2 players, resets missiles when finished (the goals are aligned at the top of the checkerboard)

3. checkerboard, displaying 2 players

 

Kernel 2 is really nice. If it is displayed for 3 rows, it has to jump to row 4 of the checkerboard. It also has to scroll like the rest since the whole thing is based on cycles. I have it working right now, I only have to add some sprite code.

Edited October 13, 2008 by roland p

[Crazyace]

If you only want to change one how about this...

 

ldx enable+n

ldy which+n

stx enam0,y

 

enable can be n entry table with values for turning on/off missile - which is table with values 0/1 selecting which to turn on/off

[+SpiceWare]

@Ben_Larson,

That's a nice trick. The compare sets the bit (pushed) needed in the ENABL ($1F) register if I understand correctly.

I use that in Medieval Mayhem to set the ball and missiles.

 

		ldx #ENABL	   ; 2 75  need to reset stack
	txs			  ; 2 77
	cpy BLyOddRow	; 3  4
	php			  ; 3  7
	cpy M1yOddRow	; 3 10
	php			  ; 3 13
	cpy M0yOddRow	; 3 16
	php			  ; 3 19

 

I have an EvenRow and OddRow for each object so they appear over 2 scan lines instead of just 1.

[mos6507]

Remember that worst case scenario you CAN use flicker or interlacing the sprites. I think that would be a fair compromise.

[cd-w]

I think you should be able to use the stack/missile trick in your kernel. The first few lines of the screen are quite tight, so you probably won't be able to draw the missiles there, but after that you have plenty of NOPs spacing things out. For two missiles you can use the following code (assumes Y holds the line counter) - the trick will be to space things out into the available cycles.

 

ldx #ENAM1
; Any instructions that do not affect X
txs
; Any instructions here
cpy M1_POS
; Any instructions that do not affect the zero flag here (e.g. store instructions - see http://www.qotile.net/minidig/docs/6502.txt for details)
php
; Any instructions here
cpy M0_POS
; Any instructions that do not affect the zero flag
php

 

Chris

Edited October 15, 2008 by cd-w

[roland p]

I think you should be able to use the stack/missile trick in your kernel. The first few lines of the screen are quite tight, so you probably won't be able to draw the missiles there, but after that you have plenty of NOPs spacing things out. For two missiles you can use the following code (assumes Y holds the line counter) - the trick will be to space things out into the available cycles.

 

ldx #ENAM1
; Any instructions that do not affect X
txs
; Any instructions here
cpy M1_POS
; Any instructions that do not affect the zero flag here (e.g. store instructions - see http://www.qotile.net/minidig/docs/6502.txt for details)
php
; Any instructions here
cpy M0_POS
; Any instructions that do not affect the zero flag
php

 

Chris

 

Hi Chris,

 

Does this code enables the missiles until M0_POS/M1_POS is reached?

 

Roland.

[Thomas Jentzsch]

Does this code enables the missiles until M0_POS/M1_POS is reached?

No, it only enables the missiles in exactly one single line, when M0/M1_POS are reached.

 

To get vertical lines of missiles, more complicated code (not mine!) is required:

; M0Adjust = M0Height - 2

 lda M0Height
 dcp M0Y		 ; temporary variable, containing the top position
 sbc M0Adjust
 sta ENAM0	 ;14 cycles

 

http://www.atariage.com/forums/index.php?s...mp;#entry804737

[roland p]

Well I just need code to disable the missile, as it is enabled in the sky and disabled below the sky.

The current idea is:

- sky kernel, enable missiles

- border kernel disable missiles at end

- checker board kernel

 

This will work pretty well. But missile-disable code in the kernel would be very nice and I would have less kernels, and goals at the sides.

[Thomas Jentzsch]

You don't have a scanline counter, do you?

 

Else you could do:

; assuming Y is the scanline counter, counting down
 cpy M0end
 rol
 rol		 ; as long as Y is >= M0end, this results into bit 1 set.
 sta ENAM0   ; 10 cycles

Edited October 15, 2008 by Thomas Jentzsch

[roland p]

You don't have a scanline counter, do you?

 

Else you could do:

; assuming Y is the scanline counter, counting down
 cpy M0end
 rol
 rol	; as long as Y is >= M0end, this results into bit 1 set.
 sta ENAM0 ; 10 cycles

 

I could change my Kernel so that A is used for data, Y as linecounter, X as pointer for what tiles to display (Chris already sent me some sample code).

But do ENAM0 and ENAM1 also make use of the vertical-delay just like player1 and player2?

 

btw, some improvements I've done:

- checkerboard dimensions in the view is now parameterized, so I can make 21x51 and 51x21 checkerboards (for rotation)

- moved the tile-setup-code to the sky-kernel (was before sky-kernel) so title/score can be displayed between player1 and player2 checkerboards.

- vblank is now free again so all game logic can be put there.

Edited October 16, 2008 by roland p

[vdub_bobby]

No - missiles are not VDELed.

 

EDIT: And a question...

Are you going to translate the Ballblazer "riffology" algorithmic music generator to the 2600?

http://www.langston.com/LFGames/

http://www.langston.com/Papers/amc.pdf

Edited October 16, 2008 by vdub_bobby

[Godzilla]

'atari refuses to let videogame fad die' (paraphrase,) that article is priceless. Guess whoever wrote that article is eating their feet. Fad indeed.

[roland p]

No - missiles are not VDELed.

 

EDIT: And a question...

Are you going to translate the Ballblazer "riffology" algorithmic music generator to the 2600?

 

I don't know. Is it important?

[roland p]

I did some expririmenting on the goals. The goals are now fixed, but will grow if you move towards them, only in height.

 

Right now I calculate the checkerboard in reversed order in the sky, and just hit ENAM0, ENAM1 whenever I see a border. It doesn't look real enough yet, will work on that.

 

I have 351 bytes left, so I'm thinking of using bankswitching using the following scheme:

 

bank 1: framework for vertical blanking etc. + game logic + music + sound effects.

bank 2: sky-kernel, small code so lots of space left for sprites. fetches sprite data needed in checkerboard kernel into ram

bank 3: brown border + checkerboard kernel, 3kb so dedicated bank for this one. displays the sprite which was stored in ram by bank 2.

ballblazer.bin

[mos6507]

A couple things. I noticed your timing is sometimes off and it's pushing the bottom display down by a scanline now and then. Also, why don't you implement border collision detection so that you can't fly off into no-man's land anymore?

[Cybergoth]

Are you going to translate the Ballblazer "riffology" algorithmic music generator to the 2600?

 

I'll have to look into this

 

Here's a rough TA conversion for the start.

ballblazer.zip

[Segataritensoftii]

Are you going to translate the Ballblazer "riffology" algorithmic music generator to the 2600?

 

I'll have to look into this

 

Here's a rough TA conversion for the start.

That's soundin' pretty good, so far! You guys have done an amazing job with all of this. I can't wait to see the finished product.

[+TrekMD]

That's amazing. Great job!

[roland p]

Are you going to translate the Ballblazer "riffology" algorithmic music generator to the 2600?

 

I'll have to look into this

 

Here's a rough TA conversion for the start.

Nice!

 

 

A couple things. I noticed your timing is sometimes off and it's pushing the bottom display down by a scanline now and then. Also, why don't you implement border collision detection so that you can't fly off into no-man's land anymore?

I guess that extra line is caused by some decision logic taking up just a little more than one scanline at that moment. I'll have to use one of the atari 2600 timers to stay in sync.

I'll do some border detection too.

 

The speed of the drones is now stored in velocityX and velocityY variables. This will have to change too. It should be a direction (vector angle) and a speed (vector length). If I have that, I can add de-acceleration and speed-limits.

[ZylonBane]

Are you going to translate the Ballblazer "riffology" algorithmic music generator to the 2600?

I'll have to look into this

 

Here's a rough TA conversion for the start.

Dude... ouch. Rough indeed!

 

Attached is the result of a couple days experimentation on my part. I gave up trying to get the last few notes in tune. Anyone is welcome to run with this.

ballblazer_start.bas.bin

ballblazer_start.bas

[Albert]

Are you going to translate the Ballblazer "riffology" algorithmic music generator to the 2600?

I'll have to look into this

 

Here's a rough TA conversion for the start.

Dude... ouch. Rough indeed!

 

Attached is the result of a couple days experimentation on my part. I gave up trying to get the last few notes in tune. Anyone is welcome to run with this.

Sounds pretty good, even with the notes that are not quite in tune.

 

..Al