How do i do this ?

[Retro Archaeologist]

I know that if i use the NUSIZ0 = $3 i can get three copies of the player0 and it's missile but how can i get them to be at Diffrent X and Y screen locations ?.

 

I am slowly studying the tutorials at the Mini Dig and the ones here that Andrew Davies has provided as well as the one that Kirk Isreal has done. but i am a little slow at diegesting this kind of info. so is there a way to do it in bBasic or do i have to keep studying Asm to obtain that ?.

 

RA

[+batari]

I know that if i use the NUSIZ0 = $3 i can get three copies of the player0 and it's missile but how can i get them to be at Diffrent X and Y screen locations ?.

 

I am slowly studying the tutorials at the Mini Dig and the ones here that Andrew Davies has provided as well as the one that Kirk Isreal has done. but i am a little slow at diegesting this kind of info. so is there a way to do it in bBasic or do i have to keep studying Asm to obtain that ?.

 

RA

981204[/snapback]

Whether you are using bB or asm, the triple copies are fixed in relation to one another, and must all have the same Y. This is a hardware limition that has no software workaround. NUSIZ=3 means they are close (each copy separated horizontally by exactly 8 pixels) and NUSIZ=6 means they are a medium distance apart (can't recall how many pixels exactly, but it's fixed anyway.)

[SeaGtGruff]

I know that if i use the NUSIZ0 = $3 i can get three copies of the player0 and it's missile but how can i get them to be at Diffrent X and Y screen locations ?.

 

I am slowly studying the tutorials at the Mini Dig and the ones here that Andrew Davies has provided as well as the one that Kirk Isreal has done. but i am a little slow at diegesting this kind of info. so is there a way to do it in bBasic or do i have to keep studying Asm to obtain that ?.

 

RA

981204[/snapback]

 

You can't do it with the existing "canned" kernel, unless you use flickering-- e.g., to draw two independent player0 shapes, draw the first player0 shape on the odd frames, and draw the second player0 shape on the even frames.

 

The ability to do that without flickering (well, except where the two shapes overlap on scan lines) is hoped for in the next version of bB, which may be released in January.

 

However, I'm not sure how that's going to affect the RAM variables. Right now, 5 bytes are needed just for 1 copy of player0 (player0x = 1 byte, player0y = 1 byte, player0pointer = 2 bytes, and player0height = 1 byte), so for, say, 6 independent copies of player0, 30 bytes will be needed. That's 25 bytes more than currently, which means the 26 user variables (A through Z) would be toast-- and that's not even allowing for multiple copies of player1!

 

Of course, you don't need to use the "canned" kernel. If you have very specific wants and needs (e.g., you won't be using the ball or missiles, just player0 and player1, and you aren't going to need an asymmetrical playfield), and if timing isn't a super-critical issue on each scan line, then you might be able to write your own game-specific kernel using all bB commands (i.e., for...next, if...then...else, goto, gosub, let). And if timing is an issue, you can always write your own kernel using inline assembly code.

 

For example, the attached program is an all-bB custom kernel that I wrote last night to display the 2600's 128-color palette using only the background. Clearly, that kernel won't do you any good for multi-player graphics, but at least it shows that you can write all-bB custom kernels instead of calling drawscreen.

 

Michael Rideout

 

 

  rem * A simple NTSC display kernel written in bB.
  rem * "The Atari's 128-Color Palette" (:^p~
  rem =============================================

  rem * Initialize the 2600's audio and video.
  rem * (bB actually clears the 2600's registers for us,
  rem * but you need to do this sort of thing if you're
  rem * writing pure assembly programs outside of bB.)
  PF0 = 0 : rem * Turn off playfield 0.
  PF1 = 0 : rem * Turn off playfield 1.
  PF2 = 0 : rem * Turn off playfield 2.
  GRP0 = 0 : rem * Turn off graphics for player 0.
  GRP1 = 0 : rem * Turn off graphics for player 1.
  ENAM0 = 0 : rem * Turn off enable for missile 0.
  ENAM1 = 0 : rem * Turn off enable for missile 1.
  ENABL = 0 : rem * Turn off enable for ball.
  AUDV0 = 0 : rem * Turn off audio volume for sound 0.
  AUDV1 = 0 : rem * Turn off audio volume for sound 1.

loop

  rem * Draw 30 blanked scan lines.
  VBLANK = 2 : rem * Turn on video blanking.
  for x = 1 to 30 : rem * Do next part 30 times.
     WSYNC = 0 : rem * Wait for next horizontal sync.
  next

  rem * Send vertical sync signal for 3 scan lines.
  VSYNC = 2 : rem * Turn on vertical sync.
  for x = 1 to 3 : rem * Do next part 3 times.
     WSYNC = 0 : rem * Wait for next horizontal sync.
  next
  VSYNC = 0 : rem * Turn off vertical sync.

  rem * Draw 36 more blanked scan lines.
  for x = 1 to 36 : rem * Do next part 36 times.
     WSYNC = 0 : rem * Wait for next horizontal sync.
  next

  rem * Turn video back on.
  VBLANK = 0 : rem * Turn off video blanking.

  rem * Draw hue 0 and its luminances for 11 scan lines.
  x = 0
hue_0_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_1
  COLUBK = $00
  COLUBK = $00
  COLUBK = $02
  COLUBK = $04
  COLUBK = $06
  COLUBK = $08
  COLUBK = $0A
  COLUBK = $0C
  COLUBK = $0E
  COLUBK = $00
  goto hue_0_loop

  rem * Draw hue 1 and its luminances for 11 scan lines.
hue_1
  x = 0
hue_1_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_2
  COLUBK = $00
  COLUBK = $10
  COLUBK = $12
  COLUBK = $14
  COLUBK = $16
  COLUBK = $18
  COLUBK = $1A
  COLUBK = $1C
  COLUBK = $1E
  COLUBK = $00
  goto hue_1_loop

  rem * Draw hue 2 and its luminances for 11 scan lines.
hue_2
  x = 0
hue_2_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_3
  COLUBK = $00
  COLUBK = $20
  COLUBK = $22
  COLUBK = $24
  COLUBK = $26
  COLUBK = $28
  COLUBK = $2A
  COLUBK = $2C
  COLUBK = $2E
  COLUBK = $00
  goto hue_2_loop

  rem * Draw hue 3 and its luminances for 11 scan lines.
hue_3
  x = 0
hue_3_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_4
  COLUBK = $00
  COLUBK = $30
  COLUBK = $32
  COLUBK = $34
  COLUBK = $36
  COLUBK = $38
  COLUBK = $3A
  COLUBK = $3C
  COLUBK = $3E
  COLUBK = $00
  goto hue_3_loop

  rem * Draw hue 4 and its luminances for 11 scan lines.
hue_4
  x = 0
hue_4_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_5
  COLUBK = $00
  COLUBK = $40
  COLUBK = $42
  COLUBK = $44
  COLUBK = $46
  COLUBK = $48
  COLUBK = $4A
  COLUBK = $4C
  COLUBK = $4E
  COLUBK = $00
  goto hue_4_loop

  rem * Draw hue 5 and its luminances for 11 scan lines.
hue_5
  x = 0
hue_5_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_6
  COLUBK = $00
  COLUBK = $50
  COLUBK = $52
  COLUBK = $54
  COLUBK = $56
  COLUBK = $58
  COLUBK = $5A
  COLUBK = $5C
  COLUBK = $5E
  COLUBK = $00
  goto hue_5_loop

  rem * Draw hue 6 and its luminances for 11 scan lines.
hue_6
  x = 0
hue_6_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_7
  COLUBK = $00
  COLUBK = $60
  COLUBK = $62
  COLUBK = $64
  COLUBK = $66
  COLUBK = $68
  COLUBK = $6A
  COLUBK = $6C
  COLUBK = $6E
  COLUBK = $00
  goto hue_6_loop

  rem * Draw hue 7 and its luminances for 11 scan lines.
hue_7
  x = 0
hue_7_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_8
  COLUBK = $00
  COLUBK = $70
  COLUBK = $72
  COLUBK = $74
  COLUBK = $76
  COLUBK = $78
  COLUBK = $7A
  COLUBK = $7C
  COLUBK = $7E
  COLUBK = $00
  goto hue_7_loop

  rem * Draw hue 8 and its luminances for 11 scan lines.
hue_8
  x = 0
hue_8_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_9
  COLUBK = $00
  COLUBK = $80
  COLUBK = $82
  COLUBK = $84
  COLUBK = $86
  COLUBK = $88
  COLUBK = $8A
  COLUBK = $8C
  COLUBK = $8E
  COLUBK = $00
  goto hue_8_loop

  rem * Draw hue 9 and its luminances for 11 scan lines.
hue_9
  x = 0
hue_9_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_10
  COLUBK = $00
  COLUBK = $90
  COLUBK = $92
  COLUBK = $94
  COLUBK = $96
  COLUBK = $98
  COLUBK = $9A
  COLUBK = $9C
  COLUBK = $9E
  COLUBK = $00
  goto hue_9_loop

  rem * Draw hue 10 and its luminances for 11 scan lines.
hue_10
  x = 0
hue_10_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_11
  COLUBK = $00
  COLUBK = $A0
  COLUBK = $A2
  COLUBK = $A4
  COLUBK = $A6
  COLUBK = $A8
  COLUBK = $AA
  COLUBK = $AC
  COLUBK = $AE
  COLUBK = $00
  goto hue_10_loop

  rem * Draw hue 11 and its luminances for 11 scan lines.
hue_11
  x = 0
hue_11_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_12
  COLUBK = $00
  COLUBK = $B0
  COLUBK = $B2
  COLUBK = $B4
  COLUBK = $B6
  COLUBK = $B8
  COLUBK = $BA
  COLUBK = $BC
  COLUBK = $BE
  COLUBK = $00
  goto hue_11_loop

  rem * Draw hue 12 and its luminances for 11 scan lines.
hue_12
  x = 0
hue_12_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_13
  COLUBK = $00
  COLUBK = $C0
  COLUBK = $C2
  COLUBK = $C4
  COLUBK = $C6
  COLUBK = $C8
  COLUBK = $CA
  COLUBK = $CC
  COLUBK = $CE
  COLUBK = $00
  goto hue_12_loop

  rem * Draw hue 13 and its luminances for 11 scan lines.
hue_13
  x = 0
hue_13_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_14
  COLUBK = $00
  COLUBK = $D0
  COLUBK = $D2
  COLUBK = $D4
  COLUBK = $D6
  COLUBK = $D8
  COLUBK = $DA
  COLUBK = $DC
  COLUBK = $DE
  COLUBK = $00
  goto hue_13_loop

  rem * Draw hue 14 and its luminances for 11 scan lines.
hue_14
  x = 0
hue_14_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_15
  COLUBK = $00
  COLUBK = $E0
  COLUBK = $E2
  COLUBK = $E4
  COLUBK = $E6
  COLUBK = $E8
  COLUBK = $EA
  COLUBK = $EC
  COLUBK = $EE
  COLUBK = $00
  goto hue_14_loop

  rem * Draw hue 15 and its luminances for 11 scan lines.
hue_15
  x = 0
hue_15_loop
  WSYNC = 0 : rem * Wait for next horizontal sync.
  x = x + 1
  if x = 12 then goto hue_15_end
  COLUBK = $00
  COLUBK = $F0
  COLUBK = $F2
  COLUBK = $F4
  COLUBK = $F6
  COLUBK = $F8
  COLUBK = $FA
  COLUBK = $FC
  COLUBK = $FE
  COLUBK = $00
  goto hue_15_loop

  rem * Draw one more scan line.
hue_15_end
  WSYNC = 0 : rem * Wait for next horizontal sync.
  goto loop

palette.zip

[+batari]

Of course, you don't need to use the "canned" kernel. If you have very specific wants and needs (e.g., you won't be using the ball or missiles, just player0 and player1, and you aren't going to need an asymmetrical playfield), and if timing isn't a super-critical issue on each scan line, then you might be able to write your own game-specific kernel using all bB commands (i.e., for...next, if...then...else, goto, gosub, let). And if timing is an issue, you can always write your own kernel using inline assembly code.

 

For example, the attached program is an all-bB custom kernel that I wrote last night to display the 2600's 128-color palette using only the background. Clearly, that kernel won't do you any good for multi-player graphics, but at least it shows that you can write all-bB custom kernels instead of calling drawscreen.

981498[/snapback]

Interesting... I always suspected it was possible to write a kernel in bB - it just never occured to me that it would work that well.

[Retro Archaeologist]

thanks for the replies Batari and SeaGtGruff , it makes things a little easier to understand. the game i have in mind is fairly simple kinda like a Night Stalker Clone and i was just wondering how they got the three robots (monsters) ect to move independant of the player thats all.

 

People are always saying you can use missiles and such as fake players but i have not been able to do it yet, as there is no way to define thier shape as you would a normal player sprite in bBasic.

 

but i will keep learning until i get it , may take forever but i will learn it.

 

thanks again guys.

 

RA

[+batari]

thanks for the replies Batari and SeaGtGruff , it makes things a little easier to understand. the game i have in mind is fairly simple kinda like a Night Stalker Clone and  i was just wondering how they got the three robots (monsters) ect to move independant of the player thats all.

 

People are always saying you can use missiles and such as fake players but i have not been able to do it yet, as there is no way to define thier shape as you would a normal player sprite in bBasic.

 

but i will keep learning until i get it , may take forever but i will learn it.

 

thanks again guys.

 

RA

981584[/snapback]

I think that Night Stalker does both the fake player trick, and also repositions one of the player sprites during the visible screen.

 

The upcoming multisprite kernel for bB does repositioning. There are some vertical placement limitations, but careful programming can make it look like there aren't any.

[potatohead]

Of course, you don't need to use the "canned" kernel. If you have very specific wants and needs (e.g., you won't be using the ball or missiles, just player0 and player1, and you aren't going to need an asymmetrical playfield), and if timing isn't a super-critical issue on each scan line, then you might be able to write your own game-specific kernel using all bB commands (i.e., for...next, if...then...else, goto, gosub, let). And if timing is an issue, you can always write your own kernel using inline assembly code.

 

For example, the attached program is an all-bB custom kernel that I wrote last night to display the 2600's 128-color palette using only the background. Clearly, that kernel won't do you any good for multi-player graphics, but at least it shows that you can write all-bB custom kernels instead of calling drawscreen.

981498[/snapback]

Interesting... I always suspected it was possible to write a kernel in bB - it just never occured to me that it would work that well.

981521[/snapback]

 

Very cool!

 

Thanks a bunch for writing that.

 

Still thinking about supercats big memory cart and Bb...

[Retro Archaeologist]

thanks for the replies Batari and SeaGtGruff , it makes things a little easier to understand. the game i have in mind is fairly simple kinda like a Night Stalker Clone and  i was just wondering how they got the three robots (monsters) ect to move independant of the player thats all.

 

People are always saying you can use missiles and such as fake players but i have not been able to do it yet, as there is no way to define thier shape as you would a normal player sprite in bBasic.

 

but i will keep learning until i get it , may take forever but i will learn it.

 

thanks again guys.

 

RA

981584[/snapback]

I think that Night Stalker does both the fake player trick, and also repositions one of the player sprites during the visible screen.

 

The upcoming multisprite kernel for bB does repositioning. There are some vertical placement limitations, but careful programming can make it look like there aren't any.

981601[/snapback]

 

Oki Doki, i will keep that in mind while i study ASM listings form the DIG, if i can't figure it out then i will wait for the New bBasic Kernel/Compiler release.

 

Thanks again bBatari, this is the coolest thing i have seen yet

 

RA