Bob width >16 pixels

DanielAllsopp · 21 May 2020, 01:10

Hi!

Having got used to sprites and multiplexing, I'm trying my hand at BOBs now as it seems pretty fundamental on the Amiga.

I have the following code:

Code:

BobWidth                      EQU 16
BobHeight                     EQU 46

BobByteWidth                  EQU BobWidth/8
BobVerticalSize               EQU BobHeight*DisplayDepth
BobHorizontalSize             EQU BobByteWidth/2
BobSourceModulo               EQU BobByteWidth-2
BobDestinationModulo          EQU BytesSingleBitplaneLine-2
BobByteWidthBlockRow          EQU (BytesAllBitplaneLines*BobHeight)/2

...

  move.l #$09f00000,BLTCON0(a6)	                ; A->D copy, no shifts, ascending mode
  move.l #-1,BLTAFWM(a6)	                      ; no masking of first/last word
  move.w #BobSourceModulo,BLTAMOD(a6)		        ; A modulo=bytes to skip between lines
  move.w #BobDestinationModulo,BLTDMOD(a6)	    ; D modulo
  move.l a0,BLTAPTH(a6)	                        ; source graphic top left corner
  move.l a1,BLTDPTH(a6)	                        ; destination top left corner
  move.w #BobVerticalSize,BLTSIZV(a6)
  move.w #BobHorizontalSize,BLTSIZH(a6)

This works and looks great when drawing my 16x16 pixel tiles onto the map, so no problem there. However, I also want to use it to display objects other than tiles, so for example a 32x46 sized object.

This is when things start to go wrong:

As far as I'm aware, all of the modulo's etc should remain the same? I'm obviously making sure I change the BobWidth EQU to 32 and the data is in fact a 32 pixel wide interleaved bitplane piece of data.

I'm missing something here though.

phx · 21 May 2020, 01:26

Quote:

Originally Posted by DanielAllsopp

As far as I'm aware, all of the modulo's etc should remain the same?

No. The destination modulo will be smaller of course. When your new BOB is two bytes wider, then the modulo, which is added to advance the D-pointer to the next bitmap-line, must be two bytes smaller.

You should do

BobDestinationModulo EQU BytesSingleBitplaneLine-BobByteWidth

DanielAllsopp · 21 May 2020, 09:55

Quote:

Originally Posted by phx

No. The destination modulo will be smaller of course. When your new BOB is two bytes wider, then the modulo, which is added to advance the D-pointer to the next bitmap-line, must be two bytes smaller.

You should do

BobDestinationModulo EQU BytesSingleBitplaneLine-BobByteWidth

Damn, of course it will be, longer width = less to add on to get to the next line. I was that concerned with the source numbers that I didn’t think to check the destination.

That’s my fault for using magic numbers too! I was doing so well not asking for help in my new stint at learning too!

Thanks mate.

thomas · 21 May 2020, 11:31

And BobByteWidth should be (BobWidth + 15)/16*2 to get proper alignment even if your bob's width is not divisible by 16.

DanielAllsopp · 22 May 2020, 01:30

Thanks for everyone's help. Got it working great, so that's good.

I have a question though; can you tell the blitter to only bit into a set number of bitplanes?

For example, my main bob is only 15 colours, but the display is 64. Can I position the 15 colours from my bob at the start of the palette, save my bob as 4 bitplanes and only blit those 4 bitplanes into my screen buffers instead of the full 6?

Just thinking of saving some CPU/Blitter time here.

Antiriad_UK · 22 May 2020, 08:38

Sure. Like you say you just blit to the first 4 bitplanes and setup the palette to match. If you are running an interleaved screen you will have to blit the 4 planes individually (and change modulos) so you lose the main advantage of interleaved - so same overhead as non-interleaved.

roondar · 22 May 2020, 11:01

You can do this, but keep in mind that blitting to fewer bitplanes will only work as expected if there is nothing on the bitplanes "behind" the bob. If there is something behind the bob, the colours will not end up as you expect because the colour index of the pixel will be determined across all bitplanes, not just the ones you blit to. It's quite possible this is not an issue for your game/demo (it all depends on the design). But if it is an issue, there are basically two ways around it:

The first is to set up the palette such that any combination of colour indexes that include the bitplanes you use for the bob will always result in the colours for the bobs. This works, but (significantly) limits your palette.

The second is to mask out & restore the pixels on the other planes. This also works, but limits the performance gain (in some cases this may even cost more than just blitting a regular bob).

DanielAllsopp · 22 May 2020, 17:13

Ah, thanks for the info. I did a few quick tests earlier and I think it's going to be more bother than it's worth from what I can see with my performance checks; the green copper lines don't move much at all from blitting 6 planes to 4.

Yeah, I've started from scratch with my ASM tinkering and chosen a new ripped sprites setup.

Looking over all of the suggestions people made about the other project, it was better start again and adhere to those with a clean slate.

What we have here is:
- a 320x256 screen, with a 288 pixel display window
- 4 attached sprites to build the background mountains which loops and scrolls at a 1 pixel resolution, and is horizontally reused using SSCAN2
- a copper rainbow for the sky
- a 16 colour blitter object using a mask

Just taking it slowly at the minute and not moving onto anything before figuring out what I'm currently working on. The last time I think I just crammed as much in, and left unfinished work all over the place.

Issues I can across was trying to keep 320x256 display window with scrolling, and multiplexing those mountains into two strips so I could move them at different rates, but I must have ran out of DMA as sprite 7 disappeared in the second pointer re-assignment for the sand dunes, which I thought was a shame. Still I'm happy with my latest progress.

My latest problem is moving that blitter object 1 pixel at a time... it only seems to move in 32 pixels blocks right now.

roondar · 22 May 2020, 17:41

Here's my usual BlitBob routine for reference, maybe it can help you figure out why the positioning isn't working. It does contain some stuff you may not care about (and assumes an interleaved bitmap), but the address/shift calculation definitely works

Code:

		; Blitwait macro
		; Waits on the blitter, using blitter nasty mode
		; to reduce CPU usage of chipmemory during wait.
		; \1: adress register containing pointer to custombase
BlitWait	MACRO
			move.w	#$8400,dmacon(\1)
.bltwait_\@	btst	#6,dmaconr(\1)
			bne		.bltwait_\@
			move.w	#$0400,dmacon(\1)
			ENDM

		; Routine BlitBob
		; This routine copies a given bitmap to a destination bitmap (using cookiecut mode)
		; D2 = X
		; D3 = Y
		; D4 = ADMOD value
		; D5 = BLTSIZE value
		; A1 = restore pointers
		; A2 = Source bitmap
		; A4 = Mask bitmap
		; A5 = Destination bitmap
BlitBob	
		move.w	d2,-(sp)		; Stack
		mulu	#fg_mod,d3		; Y offset
		
		; X-shift
		lea.l	bl_bob,a0
		moveq	#15,d6
		and.w	d2,d6
		add.w	d6,d6
		add.w	d6,d6			; D6 = offset into bltcon table
		move.l	0(a0,d6),d6		; D6 = BLTCON0/1

		; Offset
		asr.w	#3,d2			; D2 = X offset
		add.l	d2,d3			; D3 = offset
		
		move.l	fg_buf3,a3
		move.w	fg_offset,d2
		lea.l	0(a3,d2),a3
		lea.l	0(a3,d3.l),a3
		move.l	a3,(a1)+		; Store restore pointer 1
		
		lea.l	0(a5,d3.l),a3
		move.l	a3,(a1)+		; Store restore pointer 2
		
		BlitWait a6
		move.l	d6,bltcon0(a6)
		move.l	d4,bltamod(a6)
		swap	d4
		move.l	d4,bltcmod(a6)
		swap	d4
		move.l	a4,bltapt(a6)
		move.l	a2,bltbpt(a6)
		move.l	a3,bltcpt(a6)
		move.l	a3,bltdpt(a6)
		move.w	d5,bltsize(a6)
		move.w	(sp)+,d2		; Stack
		rts

		; Bltcon tables for bob minterms/shifts (base tables)
bl_bob		dc.l	$0fca0000,$1fca1000,$2fca2000,$3fca3000
			dc.l	$4fca4000,$5fca5000,$6fca6000,$7fca7000
			dc.l	$8fca8000,$9fca9000,$afcaa000,$bfcab000
			dc.l	$cfcac000,$dfcad000,$efcae000,$ffcaf000

DanielAllsopp · 22 May 2020, 17:54

Quote:

Originally Posted by roondar

Here's my usual BlitBob routine for reference, maybe it can help you figure out why the positioning isn't working. It does contain some stuff you may not care about (and assumes an interleaved bitmap), but the address/shift calculation definitely works

Thanks roondar, that's perfect. I'd rather look through something and figure it out than just put code in there that I have no idea why it works.

Great stuff!

roondar · 22 May 2020, 18:02

Happy to help

22 May 2020, 17:13	#8
DanielAllsopp Registered User Join Date: Feb 2018 Location: Northumberland, UK Posts: 272	Ah, thanks for the info. I did a few quick tests earlier and I think it's going to be more bother than it's worth from what I can see with my performance checks; the green copper lines don't move much at all from blitting 6 planes to 4. Yeah, I've started from scratch with my ASM tinkering and chosen a new ripped sprites setup. Looking over all of the suggestions people made about the other project, it was better start again and adhere to those with a clean slate. What we have here is: - a 320x256 screen, with a 288 pixel display window - 4 attached sprites to build the background mountains which loops and scrolls at a 1 pixel resolution, and is horizontally reused using SSCAN2 - a copper rainbow for the sky - a 16 colour blitter object using a mask Just taking it slowly at the minute and not moving onto anything before figuring out what I'm currently working on. The last time I think I just crammed as much in, and left unfinished work all over the place. Issues I can across was trying to keep 320x256 display window with scrolling, and multiplexing those mountains into two strips so I could move them at different rates, but I must have ran out of DMA as sprite 7 disappeared in the second pointer re-assignment for the sand dunes, which I thought was a shame. Still I'm happy with my latest progress. My latest problem is moving that blitter object 1 pixel at a time... it only seems to move in 32 pixels blocks right now. Last edited by DanielAllsopp; 22 May 2020 at 17:53.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Get current CLI window width	sg00	Coders. C/C++	5	18 June 2019 09:09
ListBrowser column width	mritter0	Coders. C/C++	1	08 August 2017 07:03
Object width	mritter0	Coders. C/C++	2	19 September 2014 23:06
Get Gadget Width	mritter0	Coders. C/C++	2	11 June 2014 02:27
Bob's Bad Day - ... no Bob.	AB Positive	support.Games	5	16 May 2009 01:45

21 May 2020, 01:10	#1
DanielAllsopp Registered User Join Date: Feb 2018 Location: Northumberland, UK Posts: 272	Bob width >16 pixels Hi! Having got used to sprites and multiplexing, I'm trying my hand at BOBs now as it seems pretty fundamental on the Amiga. I have the following code: Code: BobWidth EQU 16 BobHeight EQU 46 BobByteWidth EQU BobWidth/8 BobVerticalSize EQU BobHeightDisplayDepth BobHorizontalSize EQU BobByteWidth/2 BobSourceModulo EQU BobByteWidth-2 BobDestinationModulo EQU BytesSingleBitplaneLine-2 BobByteWidthBlockRow EQU (BytesAllBitplaneLinesBobHeight)/2 ... move.l #$09f00000,BLTCON0(a6) ; A->D copy, no shifts, ascending mode move.l #-1,BLTAFWM(a6) ; no masking of first/last word move.w #BobSourceModulo,BLTAMOD(a6) ; A modulo=bytes to skip between lines move.w #BobDestinationModulo,BLTDMOD(a6) ; D modulo move.l a0,BLTAPTH(a6) ; source graphic top left corner move.l a1,BLTDPTH(a6) ; destination top left corner move.w #BobVerticalSize,BLTSIZV(a6) move.w #BobHorizontalSize,BLTSIZH(a6) This works and looks great when drawing my 16x16 pixel tiles onto the map, so no problem there. However, I also want to use it to display objects other than tiles, so for example a 32x46 sized object. This is when things start to go wrong: As far as I'm aware, all of the modulo's etc should remain the same? I'm obviously making sure I change the BobWidth EQU to 32 and the data is in fact a 32 pixel wide interleaved bitplane piece of data. I'm missing something here though.

21 May 2020, 11:31	#4
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 6,985	And BobByteWidth should be (BobWidth + 15)/16*2 to get proper alignment even if your bob's width is not divisible by 16.

22 May 2020, 01:30	#5
DanielAllsopp Registered User Join Date: Feb 2018 Location: Northumberland, UK Posts: 272	Thanks for everyone's help. Got it working great, so that's good. I have a question though; can you tell the blitter to only bit into a set number of bitplanes? For example, my main bob is only 15 colours, but the display is 64. Can I position the 15 colours from my bob at the start of the palette, save my bob as 4 bitplanes and only blit those 4 bitplanes into my screen buffers instead of the full 6? Just thinking of saving some CPU/Blitter time here.

22 May 2020, 08:38	#6
Antiriad_UK OCS forever! Join Date: Mar 2019 Location: Birmingham, UK Posts: 418	Sure. Like you say you just blit to the first 4 bitplanes and setup the palette to match. If you are running an interleaved screen you will have to blit the 4 planes individually (and change modulos) so you lose the main advantage of interleaved - so same overhead as non-interleaved.

22 May 2020, 11:01	#7
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,409	You can do this, but keep in mind that blitting to fewer bitplanes will only work as expected if there is nothing on the bitplanes "behind" the bob. If there is something behind the bob, the colours will not end up as you expect because the colour index of the pixel will be determined across all bitplanes, not just the ones you blit to. It's quite possible this is not an issue for your game/demo (it all depends on the design). But if it is an issue, there are basically two ways around it: The first is to set up the palette such that any combination of colour indexes that include the bitplanes you use for the bob will always result in the colours for the bobs. This works, but (significantly) limits your palette. The second is to mask out & restore the pixels on the other planes. This also works, but limits the performance gain (in some cases this may even cost more than just blitting a regular bob).

22 May 2020, 18:02	#11
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,409	Happy to help

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)