Jump to content
IGNORED

Custom player graphics for multisprite kernel


Al_Nafuur

Recommended Posts

I am trying to do something similar to a trick @Karl G did with the standard kernel:

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#easy_way_to_set_player_graphic_to_number

 

I want to use the same definition for multiple sprites of the multisprite kernel, but it doesn't fully work.

test.bas.bin

 

 

bB code:

   includesfile multisprite_bankswitch.inc
   set kernel multisprite
   set romsize 16k


   const _Small_Plane_down_high = >Small_Plane_down
   const _Small_Plane_down_low  = <Small_Plane_down


   bank 1

   player1x = 75
   player1y = 75
   _COLUP1 = $D6
   COLUBK = $96

   ; bB player graphics hack
   player1pointerlo = _Small_Plane_down_low
   player1pointerhi = _Small_Plane_down_high
   player1height = 6

   ; assembler version
/*
   asm
   LDX	#<Small_Plane_down
   STX	player1pointerlo
   LDA	#>Small_Plane_down
   STA	player1pointerhi
   LDA	#6
   STA	player1height
end
*/

Mainloop

   player1y = player1y - 1
   if player1y = 255 then player1y = 88

   drawscreen
   goto Mainloop

   bank 2
   bank 3
   bank 4

   asm
;   align 256
end

  data Small_Plane_down
   %00011000
   %01111110
   %01111110
   %10011001
   %00111100
end

 

Link to comment
Share on other sites

I'm really not sure what's going on. You can get rid of the garbage on the left of the screen by defining player0 and getting it out of the way. The issue with the graphic not working towards the top of the screen is a mystery to me, though. Oddly, it only happens with a bankswitched ROM. I can "fix" it by making it 4k:

 

;   includesfile multisprite_bankswitch.inc
   set kernel multisprite
;   set romsize 16k


   const _Small_Plane_down_high = >Small_Plane_down
   const _Small_Plane_down_low  = <Small_Plane_down


;   bank 1

   player1x = 75
   player1y = 75
   _COLUP1 = $D6
   COLUBK = $96

   ; bB player graphics hack
   player1pointerlo = _Small_Plane_down_low
   player1pointerhi = _Small_Plane_down_high
   player1height = 5

   ; assembler version
/*
   asm
   LDX	#<Small_Plane_down
   STX	player1pointerlo
   LDA	#>Small_Plane_down
   STA	player1pointerhi
   LDA	#6
   STA	player1height
end
*/

    player0:
end

    player0y = 100 ; offscreen

Mainloop

   player1y = player1y - 1
   if player1y = 255 then player1y = 88

   drawscreen
   goto Mainloop

;   bank 2
;   bank 3
;   bank 4

   /* asm
   align 256
end */

  data Small_Plane_down
   %00011000
   %01111110
   %01111110
   %10011001
   %00111100
end

 

  • Like 1
Link to comment
Share on other sites

27 minutes ago, Karl G said:

I'm really not sure what's going on. You can get rid of the garbage on the left of the screen by defining player0 and getting it out of the way. The issue with the graphic not working towards the top of the screen is a mystery to me, though. Oddly, it only happens with a bankswitched ROM. I can "fix" it by making it 4k:

 

I fumbled around with it in the 1942 project and somehow it works now with 16K. I am not sure what "fixed" it, if you like you can have a look at the code here:

 

https://github.com/Al-Nafuur/PlusROM-Hacks/blob/main/bBasic/1942/1942 HSC.bas

 

Link to comment
Share on other sites

  • 2 weeks later...

I'm going to start my own investigation as to what works and doesn't in your sweet new sprite data technique.  My hunch is that when it doesn't work somehow the label for sprite data isn't available in the bank your sprite pointer assignment code is run.  But, I am a pretty clueless programmer.

 

I don't know if this is related but I have to ask:  what does this code near your sprite data do?

 

 
   asm
   if	(<*) > (<(*+8))
   repeat	($100-<*)
   .byte	0
   repend
   endif
end

 

Link to comment
Share on other sites

6 hours ago, Gemintronic said:

I'm going to start my own investigation as to what works and doesn't in your sweet new sprite data technique.  My hunch is that when it doesn't work somehow the label for sprite data isn't available in the bank your sprite pointer assignment code is run.  But, I am a pretty clueless programmer.

The player data have to be in the same bank than the bB kernel.

 

 

6 hours ago, Gemintronic said:

I don't know if this is related but I have to ask:  what does this code near your sprite data do?

 

   asm
   if	(<*) > (<(*+8))
   repeat	($100-<*)
   .byte	0
   repend
   endif
end

 

This asm code (or dasm macro) checks if there is enough space in the current page for the sprite data, if not it fills the rest of the page with zeros and the sprite data begins in the next page. So the kernel will not have the extra cpu cycle when reading the sprite data across a page boundary.

 

  • Thanks 1
Link to comment
Share on other sites

I have investigated this a little bit further and it looks like the kernel don't likes sprite definitions within the first "90" (decimal) bytes of the page. So the this macro is placed before every sprite:

 if (<*) > (<(*+(SpriteDataLength-1)))
	repeat ($100-<*)
	.byte 0
	repend
	endif
 if (<*) < 90
	repeat (90-<*)
	.byte 0
	repend
	endif

If I do the same it seems to work in my 1942 code now

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...