English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 05 May 2005, 07:26   #1
cdoty
RasterSoft Dev

cdoty's Avatar
 
Join Date: Feb 2005
Location: Manteno IL
Posts: 58
Send a message via ICQ to cdoty Send a message via AIM to cdoty
Blitter Question.

Any idea what could cause the blitter to product strange results?

I use the blitter to restore parts of the screen, and then blit a sprite.

The restore blit produces weird errors, the width should be 32 pixels and the height should be 16 pixel, but it almost appears to reverse these values (0x0402 is my BlitSize), and my mod value is 36 ((320 - 32) / 8) for source A and Dest D. In between blitting the 5 planes, I am only setting channel A, D pointers and, BLITSIZE. I normally wait fo the blitter to complete between planes, but have also commented out the wait.

And using the same values, I can blit a sprite correctly. The only differences are the use of all 4 channels, masking the last word, mod values for channels A and B (mask and pixel data) and, a shift value for channels A and B. The mod values for C and D are the same as above. BLITSIZE is the same as above. My sprite is acutally 16 x 16, but I use the extra 16 bit as required and mask the last word.

The correct pixels are transferred, but the locations are wrong. I can see what it's doing, if I override the source in the restore operation.

I am using the AA chipset, but only using 5 planes.

I've debugged and verified that the values are what they should be.
cdoty is offline  
AdSense AdSense  
Old 05 May 2005, 08:24   #2
Codetapper
Moderator

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Age: 39
Posts: 2,865
Send a message via Skype™ to Codetapper
Lightbulb More info required...

Are you sure the modulo for source A in the restore part shouldn't be 0? If you're effectively saving the background that is going to be destroyed to a buffer, it's likely to be a continuous buffer in memory so no modulo on the A channel.

Can you attach your source code so we can see everything in that routine? Is your sprite on a word boundary itself - ie. up against the far left? What minterms are you using? (I think source would be easier to look at!)

Also pictures of the screen before the screen restore, after screen restore, after new blit etc would be useful if you can do that.

The theory you've written does all sound correct, so it must only be a small bug.

Last edited by Codetapper; 05 May 2005 at 09:36.
Codetapper is offline  
Old 05 May 2005, 13:52   #3
girv
Reticulator of Splines
girv's Avatar
 
Join Date: Aug 2004
Location: Northern Ireland
Posts: 920
Send a message via ICQ to girv Send a message via AIM to girv Send a message via MSN to girv Send a message via Yahoo to girv
Source code and screenshots if possible would be very helpful

I assume youre doing a $9f0 D=A copy blit for the restore?

What size is your capture area?

If you set bltcon0=$1f0 or set the source to a block of all $ff, is the correct area of screen affected? Is it possible that the initial blit to capture the background is borken and capturing the wrong data?
girv is offline  
Old 05 May 2005, 15:16   #4
cdoty
RasterSoft Dev

cdoty's Avatar
 
Join Date: Feb 2005
Location: Manteno IL
Posts: 58
Send a message via ICQ to cdoty Send a message via AIM to cdoty
Quote:
Originally Posted by Codetapper
Are you sure the modulo for source A in the restore part shouldn't be 0? If you're effectively saving the background that is going to be destroyed to a buffer, it's likely to be a continuous buffer in memory so no modulo on the A channel.

Can you attach your source code so we can see everything in that routine? Is your sprite on a word boundary itself - ie. up against the far left? What minterms are you using? (I think source would be easier to look at!)

Also pictures of the screen before the screen restore, after screen restore, after new blit etc would be useful if you can do that.
I'm actually blitting from a 320 x 224 background screen to the screen (which is also 320 x 224)

* D0 - Bitplane mod value
* D1 - Blitsize
* A0 - Back pointer
* A1 - Screen pointer
BlitBack:
jsr BlitterWait
* Set Source A first and last word mask
move.l #0xFFFFFFFF, BLTAFWM

* Set Source A modulo
move.l d0, BLTAMOD

* Set Dest D modulo
move.l d0, BLTDMOD

* Set blitter control bits
move.l #0x09F00000, BLTCON0

* Do 5 bitplanes
move.l #(5-1), d7

BlitBackLoop:
jsr BlitterWait

* Set Source A
move.l a0, BLTAPT

* Set Dest D
move.l a1, BLTDPT

* Blit start and size
move.w d1, BLTSIZE

* Advance to next bitplane
add.l #PLANESIZE, a0
add.l #PLANESIZE, a1

dbra d7, BlitBackLoop

rts

PLANESIZE is 320 * 224 / 8
D0 is 36
D1 is 0x0402 (I've also tried 0x0401 and 38 for Mod value, since I'm not using a shift)
A0 is the background data (320 x 224 x 5) allocated as CHIP
A1 is the screen (320 x 224 x 5) allocated as CHIP

You can download the program from http://www.emuvibes.com/Frog.zip. It uses the A button and not start as shown on the screen, this allows testing in WinUAE.

This is setup as a CDTV bootable CD, although all testing is done on the WinUAE CD32 configuration in NTSC. The BlitBack is changed to point A0 to the top of the background data before entering the BlitBackLoop. This make the area that is blitted more obvious.

I'm hoping that this isn't just a bug in WinUAE.

Last edited by cdoty; 05 May 2005 at 15:34.
cdoty is offline  
Old 05 May 2005, 15:17   #5
cdoty
RasterSoft Dev

cdoty's Avatar
 
Join Date: Feb 2005
Location: Manteno IL
Posts: 58
Send a message via ICQ to cdoty Send a message via AIM to cdoty
Quote:
Originally Posted by girv
I assume youre doing a $9f0 D=A copy blit for the restore?

What size is your capture area?

If you set bltcon0=$1f0 or set the source to a block of all $ff, is the correct area of screen affected? Is it possible that the initial blit to capture the background is borken and capturing the wrong data?
It fills an area above the sprite. I'm not actually capturing the screen, I blit from a duplicate copy back to the screen.
cdoty is offline  
Old 05 May 2005, 15:25   #6
cdoty
RasterSoft Dev

cdoty's Avatar
 
Join Date: Feb 2005
Location: Manteno IL
Posts: 58
Send a message via ICQ to cdoty Send a message via AIM to cdoty
I've posted the relevant parts of the source to http://www.emuvibes.com/Src.zip

It starts in Sprites.c with AddSprite, which does work correctly.

Then any changes in the sprite's position or graphics causes AddEraseBlock to be called.

These are restored starting in WaitVBlank in Routines.s. WaitVBlank calls RestoreBackground, which processes through the EraseBlock structure looking for any used EraseBlocks. RestoreBackground calls BlitBack for each block found.
cdoty is offline  
Old 05 May 2005, 15:28   #7
girv
Reticulator of Splines
girv's Avatar
 
Join Date: Aug 2004
Location: Northern Ireland
Posts: 920
Send a message via ICQ to girv Send a message via AIM to girv Send a message via MSN to girv Send a message via Yahoo to girv
MOD registers are word sized
girv is offline  
Old 05 May 2005, 15:45   #8
cdoty
RasterSoft Dev

cdoty's Avatar
 
Join Date: Feb 2005
Location: Manteno IL
Posts: 58
Send a message via ICQ to cdoty Send a message via AIM to cdoty
Quote:
Originally Posted by girv
MOD registers are word sized
D'oh! that was it. It works fine now.

I looked at that routine for hours yesterday, and it was solved in minutes here.
cdoty is offline  
Old 05 May 2005, 16:09   #9
girv
Reticulator of Splines
girv's Avatar
 
Join Date: Aug 2004
Location: Northern Ireland
Posts: 920
Send a message via ICQ to girv Send a message via AIM to girv Send a message via MSN to girv Send a message via Yahoo to girv
Quote:
Originally Posted by cdoty
I looked at that routine for hours yesterday, and it was solved in minutes here.
Do you understand why it didn't work before and what was happening when you were writing longs to AMOD and DMOD? I dont mean to be patronising, I'm just offering to explain if you don't get it Nothing worse than blindly applying a fix without understanding why it was broken in the first place.

And don't worry about staring at code for hours and missing obvious bugs,we all do it!
girv is offline  
Old 05 May 2005, 16:23   #10
bippym
Global Moderator

bippym's Avatar
 
Join Date: Nov 2001
Location: Derby, UK
Age: 39
Posts: 8,387
Send a message via Skype™ to bippym
nice to be able to understand that code regardless

/me whips out some asm books
bippym is offline  
Old 05 May 2005, 17:17   #11
cdoty
RasterSoft Dev

cdoty's Avatar
 
Join Date: Feb 2005
Location: Manteno IL
Posts: 58
Send a message via ICQ to cdoty Send a message via AIM to cdoty
Quote:
Originally Posted by girv
Do you understand why it didn't work before and what was happening when you were writing longs to AMOD and DMOD? I dont mean to be patronising, I'm just offering to explain if you don't get it Nothing worse than blindly applying a fix without understanding why it was broken in the first place.
I was initally going to post a reply back about the MOD register being in bytes, but then it hit me what you were saying.

I realized I was writing the high word to BLTAMOD (which was zero) and BLTDMOD. For a moment BLTDMOD contained the right value.

Thanks for the help.
cdoty is offline  
Old 06 May 2005, 15:22   #12
cdoty
RasterSoft Dev

cdoty's Avatar
 
Join Date: Feb 2005
Location: Manteno IL
Posts: 58
Send a message via ICQ to cdoty Send a message via AIM to cdoty
Results

If you're interested in seeing the results (and downloading the demo), check it out at http://www.game-shoppe.com/.
cdoty is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Please help me!! Blitter pain! h0ffman Coders. Asm / Hardware 5 15 June 2013 18:59
Blitter using the copper... h0ffman Coders. Asm / Hardware 9 23 February 2012 08:25
Did Starglider use the blitter? mc6809e Retrogaming General Discussion 8 04 February 2012 15:19
Filling with the blitter... Lonewolf10 Coders. Tutorials 7 13 September 2011 14:30
Blitter nasty or not? JackAsser Coders. Tutorials 5 28 March 2010 22:45

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:18.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Page generated in 0.16959 seconds with 11 queries