Blitter shift eats 1px away - Page 2

Photon · 03 February 2020, 18:49

About the original problem, Antiriad got it first time. Just scrolling an area forever will "eat up" the contents after a while - because pixel rows wrap. This is what Tut15.S demonstrates. In the following episodes, new content (characters from the scrolltext) is supplied in the right margin.

Regarding the center logo I'm not sure what's going on, but if you've found a missing BlitWait that could probably make it look like that.

KONEY · 03 February 2020, 18:59

Oh no the logo is glitched on purpose with LSLs and LSRs

I love glitch FXs

So I just need to watch more of the tutorial, again I focused on what was in front of me and missed the big picture.

thanks to everyone!

KONEY · 17 October 2020, 19:10

Well months after I'm still banging my head in the wall with blitter scrolling

I'm now scrolling a full 320*256 image in a pointed bitmap and as usual some pixels are eaten away

At this point I have (quite) understood there's no fix for this at a blitter settings level only: the bitmap needs also some zeroed margins every line.

But how am I supposed to add those margin to an image? Like make it 1px wider or something?

KONEY · 18 October 2020, 13:17

So I answered by myself finding on PicCon an option to insert this 16px margin on right and I increased my buffer accordingly.

Problem is now this buffer is bigger than the screen so when I point it to the copperlist a big mess happens.

I'm wondering if it is even possible to scroll and entire screen this way..

ross · 18 October 2020, 14:03

Quote:

Originally Posted by KONEY

Problem is now this buffer is bigger than the screen so when I point it to the copperlist a big mess happens.

Just use modulo registers

(BPLxMOD)

KONEY · 18 October 2020, 19:33

Thanks! Followed the advice and successfully blitted a 336px padded image into a 320px buffer:

Code:

__SCROLL_BG:
	MOVEM.L	D0-D7/A0-A6,-(SP)	; SAVE TO STACK
	MOVE.L	KONEYBG,A3
	MOVE.L	ScrollBuffer,A4
	BTST.B	#6,DMACONR		
	bsr	WaitBlitter

	MOVE.L	A3,BLTAPTH		
	MOVE.L	A4,BLTDPTH
	MOVE.W	#$FFFF,BLTAFWM		
	MOVE.W	#$FFFF,BLTALWM		
	MOVE.W	#%1111100111110000,BLTCON0	
	MOVE.W	#%0000000000000000,BLTCON1
	MOVE.W	#2,BLTAMOD		; 2bytes, because one extra word to skip
	MOVE.W	#0,BLTDMOD		

	MOVE.W	#blitsize,BLTSIZE		
	bsr	WaitBlitter
	MOVE.W	#blitsize,BLTSIZE		
	bsr	WaitBlitter
	MOVE.W	#blitsize,BLTSIZE		
	bsr	WaitBlitter
	MOVE.W	#blitsize,BLTSIZE		

	MOVEM.L	(SP)+,D0-A6	; FETCH FROM STACK
	RTS

BUT ironically when shifting the 1line is still again eaten away

What is not clear to me is if BLTSIZE value should be affected by the extra word or not? Now it's h*64+w/16= 16404 - the size for a single bitplane.

Quote:

Originally Posted by ross

Just use modulo registers

(BPLxMOD)

ross · 18 October 2020, 20:31

I actually talked about BPLxMOD so you hide areas of the video buffer outside the displayed part.
So you can blit for x=336 (BLTxMOD=0)

[I hope I understood what you want to do

]

KONEY · 18 October 2020, 23:35

When I point a bitmap to the copper there's no blitter involved and if the size doesn't match corruption will occur. So no BLTxMOD involved also.

So what now I wanted to do was blit a 336px large image (320px + 1 zeroed word) into a 320 buffer, which is pointed to the copperlist (sorry for the bad language, anyway I mean this buffer is actually displayed). So with BLT0MOD=2 I'm taking a 320px portion from the 336px source with shifting. This should prevent the first line to go into second but it doesn't work, display is now fine but that line is still my nightmare

Any hint is welcome!

ross · 18 October 2020, 23:42

Quote:

Originally Posted by KONEY

When I point a bitmap to the copper there's no blitter involved and if the size doesn't match corruption will occur. So no BLTxMOD involved also.

So what now I wanted to do was blit a 336px large image (320px + 1 zeroed word) into a 320 buffer, which is pointed to the copperlist (sorry for the bad language, anyway I mean this buffer is actually displayed). So with BLT0MOD=2 I'm taking a 320px portion from the 336px source with shifting. This should prevent the first line to go into second but it doesn't work, display is now fine but that line is still my nightmare

Any hint is welcome!

Enlarge the video buffer and use BPLxMOD=2 (not BLTxMOD!

)

KONEY · 19 October 2020, 13:13

oh another register, I didn't notice

Then looks like there's a whole new section I need to study, thanks!

KONEY · 22 October 2020, 21:29

And I'm lost again

Really I've spent night trying to figure out this and tried all the possible combinations

Now I changed the screen to 336px and BPLxMOD to 2 and the picture is displayed correctly, and shifting x=336 works but the extra word is visible:

AND the pixel line is still missing

Actually blitting with BLTxMOD=2 and X=320 the parts are attached but it doesn't make much of a sense since it's like 'canceling' the BPLxMOD (and the line is missing, as usual) or maybe I'm missing something else.

BLT*FWM masks dont help, I tried but they only introduce a vertical black band and/or erase the screen after some scroll il performed.

This is the code, if someone still has patience with me

Any hint would help, also just a working example could be cool.

Quote:

Originally Posted by ross

I actually talked about BPLxMOD so you hide areas of the video buffer outside the displayed part.
So you can blit for x=336 (BLTxMOD=0)

[I hope I understood what you want to do

]

ross · 22 October 2020, 22:38

Now I'm sure I don't understand what you want to do

Maybe a screen transition where a full screen scrolls within the visible area?
(like a big bob that appers from the edge?)
If that were the case there are better ways to do it and not with the blitter.

If you insist on blitter way you have to modify the blitter registers properly, in the specific modulo and x dimension (and of course shift and memory start position).
Or if you really want to blit a gigantic bob the video buffer must be much larger than 336, at least 320*2; and you can use the modulo, both of the bitplanes and of the blitter to prevent subsequent lines from wrapping and being visible.

You really need to explain in detail what is the final effect you want to achieve

.

mcgeezer · 22 October 2020, 23:01

Quote:

Originally Posted by KONEY

And I'm lost again

Really I've spent night trying to figure out this and tried all the possible combinations

Now I changed the screen to 336px and BPLxMOD to 2 and the picture is displayed correctly, and shifting x=336 works but the extra word is visible:

AND the pixel line is still missing

Actually blitting with BLTxMOD=2 and X=320 the parts are attached but it doesn't make much of a sense since it's like 'canceling' the BPLxMOD (and the line is missing, as usual) or maybe I'm missing something else.

BLT*FWM masks dont help, I tried but they only introduce a vertical black band and/or erase the screen after some scroll il performed.

This is the code, if someone still has patience with me

Any hint would help, also just a working example could be cool.

Without your includes I can't help you Koney - I'll try and help all the same though.

kamelito · 22 October 2020, 23:14

@mcgeezer
The includes are from Photon website copper shade
http://coppershade.org/asmskool/PhotonsMiniStartup/

mcgeezer · 22 October 2020, 23:25

Quote:

Originally Posted by kamelito

@mcgeezer
The includes are from Photon website copper shade
http://coppershade.org/asmskool/PhotonsMiniStartup/

Ahhh! Thanks buddy.

KONEY · 23 October 2020, 01:46

Quote:

Originally Posted by mcgeezer

Without your includes I can't help you Koney - I'll try and help all the same though.

thanks! They're also on the repository: https://github.com/KONEY/asm68k-tests

KONEY · 23 October 2020, 01:48

Quote:

Originally Posted by kamelito

@mcgeezer
The includes are from Photon website copper shade
http://coppershade.org/asmskool/PhotonsMiniStartup/

I'm pretty sure I've done some changes, better use files from github!

KONEY · 23 October 2020, 02:03

Well in general I'd like to understand how to avoid blitter eating 1 px when shifting

But in this example specifically I'd want to scroll the entire image endlessly, from L-R or R-L and of course without losing lines. I know it's too big but after everything works each bitplane will scroll separately.

Yes I insist with the blitter

So doubling the buffer is the only workaround to prevent lines to wrap?

Quote:

Originally Posted by ross

Now I'm sure I don't understand what you want to do

Maybe a screen transition where a full screen scrolls within the visible area?
(like a big bob that appers from the edge?)
If that were the case there are better ways to do it and not with the blitter.

If you insist on blitter way you have to modify the blitter registers properly, in the specific modulo and x dimension (and of course shift and memory start position).
Or if you really want to blit a gigantic bob the video buffer must be much larger than 336, at least 320*2; and you can use the modulo, both of the bitplanes and of the blitter to prevent subsequent lines from wrapping and being visible.

You really need to explain in detail what is the final effect you want to achieve

.

morbid · 23 October 2020, 08:29

So what you really want to do is a ror or rol on the entire line on each line? What gets shifted out comes back in at the other end? As far as I know you will have to do two blits per bitplane.

KONEY · 23 October 2020, 11:04

Yes, full scroll/shift.

Actually It's working with one blit per plane:

Code:

	
	MOVE.W	#blitsize,BLTSIZE	; BLTSIZE (via al blitter !)
	bsr	WaitBlitter
	MOVE.W	#blitsize,BLTSIZE	; BLTSIZE (via al blitter !)
	bsr	WaitBlitter
	MOVE.W	#blitsize,BLTSIZE	; BLTSIZE (via al blitter !)
	bsr	WaitBlitter
	MOVE.W	#blitsize,BLTSIZE	; BLTSIZE (via al blitter !)

but of course there's the wrapped line problem.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Blitter shift BACKWARDS	KONEY	Coders. Asm / Hardware	3	29 January 2020 21:50
Blitter Mask shift during copy	LeCaravage	Coders. Asm / Hardware	6	18 March 2018 22:50
Mounting real CF eats up a lot of RAM	Amiga1992	support.WinUAE	84	10 July 2016 20:26
mapROM eats too much RAM	alphonsus	support.Hardware	9	10 July 2008 01:16

03 February 2020, 18:49	#21
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	About the original problem, Antiriad got it first time. Just scrolling an area forever will "eat up" the contents after a while - because pixel rows wrap. This is what Tut15.S demonstrates. In the following episodes, new content (characters from the scrolltext) is supplied in the right margin. Regarding the center logo I'm not sure what's going on, but if you've found a missing BlitWait that could probably make it look like that.

03 February 2020, 18:59	#22
KONEY OctaMED Music Composer Join Date: Jan 2009 Location: Venice - Italy Age: 49 Posts: 666	Oh no the logo is glitched on purpose with LSLs and LSRs I love glitch FXs So I just need to watch more of the tutorial, again I focused on what was in front of me and missed the big picture. thanks to everyone!

17 October 2020, 19:10	#23
KONEY OctaMED Music Composer Join Date: Jan 2009 Location: Venice - Italy Age: 49 Posts: 666	Well months after I'm still banging my head in the wall with blitter scrolling I'm now scrolling a full 320*256 image in a pointed bitmap and as usual some pixels are eaten away At this point I have (quite) understood there's no fix for this at a blitter settings level only: the bitmap needs also some zeroed margins every line. But how am I supposed to add those margin to an image? Like make it 1px wider or something?

18 October 2020, 13:17	#24
KONEY OctaMED Music Composer Join Date: Jan 2009 Location: Venice - Italy Age: 49 Posts: 666	So I answered by myself finding on PicCon an option to insert this 16px margin on right and I increased my buffer accordingly. Problem is now this buffer is bigger than the screen so when I point it to the copperlist a big mess happens. I'm wondering if it is even possible to scroll and entire screen this way..

18 October 2020, 20:31	#27
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	I actually talked about BPLxMOD so you hide areas of the video buffer outside the displayed part. So you can blit for x=336 (BLTxMOD=0) [I hope I understood what you want to do ]

18 October 2020, 23:35	#28
KONEY OctaMED Music Composer Join Date: Jan 2009 Location: Venice - Italy Age: 49 Posts: 666	When I point a bitmap to the copper there's no blitter involved and if the size doesn't match corruption will occur. So no BLTxMOD involved also. So what now I wanted to do was blit a 336px large image (320px + 1 zeroed word) into a 320 buffer, which is pointed to the copperlist (sorry for the bad language, anyway I mean this buffer is actually displayed). So with BLT0MOD=2 I'm taking a 320px portion from the 336px source with shifting. This should prevent the first line to go into second but it doesn't work, display is now fine but that line is still my nightmare Any hint is welcome!

19 October 2020, 13:13	#30
KONEY OctaMED Music Composer Join Date: Jan 2009 Location: Venice - Italy Age: 49 Posts: 666	oh another register, I didn't notice Then looks like there's a whole new section I need to study, thanks!

22 October 2020, 22:38	#32
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Now I'm sure I don't understand what you want to do Maybe a screen transition where a full screen scrolls within the visible area? (like a big bob that appers from the edge?) If that were the case there are better ways to do it and not with the blitter. If you insist on blitter way you have to modify the blitter registers properly, in the specific modulo and x dimension (and of course shift and memory start position). Or if you really want to blit a gigantic bob the video buffer must be much larger than 336, at least 320*2; and you can use the modulo, both of the bitplanes and of the blitter to prevent subsequent lines from wrapping and being visible. You really need to explain in detail what is the final effect you want to achieve .

22 October 2020, 23:14	#34
kamelito Zone Friend Join Date: May 2006 Location: France Posts: 1,801	@mcgeezer The includes are from Photon website copper shade http://coppershade.org/asmskool/PhotonsMiniStartup/

23 October 2020, 08:29	#39
morbid Registered User Join Date: Aug 2020 Location: Huddinge Posts: 24	So what you really want to do is a ror or rol on the entire line on each line? What gets shifted out comes back in at the other end? As far as I know you will have to do two blits per bitplane.

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