English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 14 October 2019, 19:25   #1
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Blitter fill, nothing happens?

Do these numbers look sensible for a blitter fill? I have ONEDOT lines drawn in my scratch buffer, which is a single bitplane, 320x256, and I'm trying to fill to my main screen buffer, which is 320x256 by 4 bitplanes interleaved.

scratchScreenBuffer->data = 0x00040C58
screenBuffer->data = 0x0001F058
bltcon0 = 0x09F0
bltcon1 = 0x0006
bltapt = 0x00043456
bltdpt = 0x00028FDE
bltamod = 0x0000
bltdmod = 0x0078
bltsize = 0x4014

I believe I've correctly set it up to use SRCA and DEST, straight copy A_TO_D, BLITREVERSE and FILL_CARRYIN (to try and force something to happen. I believe bltapt points to the last word of my scratch buffer and bltdpt points to the last word of my main screen buffer. These numbers should be the first of 4 blits.

But nothing seems to happen.

Spooky.
deimos is offline  
Old 14 October 2019, 19:41   #2
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
Looks about right. mod/size/bltcon0 look ok. I've used 0012 for bltcon1 in my vector routines. When you say you are pointing at last word of main screen buffer, is that really the last word, or the last word of the 1st bitplane (not the same). You might be blitting onto bitplane 4 instead and that might be colored black or something daft.

Edit: Also check BLTAFWM/LWM
Antiriad_UK is offline  
Old 14 October 2019, 20:06   #3
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Quote:
Originally Posted by Antiriad_UK View Post
Looks about right. mod/size/bltcon0 look ok. I've used 0012 for bltcon1 in my vector routines. When you say you are pointing at last word of main screen buffer, is that really the last word, or the last word of the 1st bitplane (not the same). You might be blitting onto bitplane 4 instead and that might be colored black or something daft.

Edit: Also check BLTAFWM/LWM
I've double checked 0012 (FILL_XOR) for bltcon1, and bltafwm/lwm are now set to 0xffff.

bltdpt = 0x00028FDE is the last word of the first bitplane of the destination, I've double checked the maths on that.

And I've just double checked bltapt = 0x00043456.
deimos is offline  
Old 14 October 2019, 20:14   #4
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
Hmm. Don’t know then. Try changing bltcon1 to 0002 (straight copy in descending mode). If you can’t see your lines outline something else is wrong :/
Antiriad_UK is offline  
Old 14 October 2019, 20:21   #5
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Quote:
Originally Posted by Antiriad_UK View Post
Hmm. Don’t know then. Try changing bltcon1 to 0002 (straight copy in descending mode). If you can’t see your lines outline something else is wrong :/
Seems something else is wrong.
deimos is offline  
Old 14 October 2019, 20:27   #6
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
Post some code. It’ll be something daft.

I just spent 40 mins debugging something only to find out I’d left the top of d0 uncleared in an unrelated routine ;£
Antiriad_UK is offline  
Old 14 October 2019, 20:39   #7
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Thank you. While collecting the code to post I found the problem. Basically I called my polygon fill code after the function call that draws everything else, not remembering that that function contains the call that says I've finished drawing the screen and to move onto the next buffer, so I was drawing into a buffer that wasn't about to be shown and which was cleared before it could be shown.

Now it appears that my onedot xor lines are not perfect and have gaps. I've seen this discussed in another thread, so I just need to find that and apply the same fixes.

EDIT: This: http://eab.abime.net/showthread.php?...t=blitter+fill is what I'm seeing now, I think. I just need to understand that discard the first bit thing.

EDIT 2: As I don't know any better, I've decided to go down the route of fiddling with the bltsize. My polygons now look like they should, but I still need to preserve the background outside of the polygon as I blit, and I need to bound my blit to only the area that I need rather than copying the whole buffer.
Attached Thumbnails
Click image for larger version

Name:	broken-polys.png
Views:	53
Size:	9.3 KB
ID:	64761  

Last edited by deimos; 14 October 2019 at 21:14.
deimos is offline  
Old 15 October 2019, 08:49   #8
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
So, I have polygons drawing now, how do I keep any background from outside the polygon? i.e. How do I combine cookie-cutting with filling?

SRCA points to my scratch area. SRCC points to the same place as my destination. I'm blitting with the minterm A_OR_C so if A (the scratch area and the fill?) is set then the destination is set, else is C (the background) is set then the destination is too.

But what I'm seeing looks as if stuff that's in the background (SRCC) is also flipping the fill status as well as SRCA.

That can't be right?

The only useful thing the HRM says is this "Use a standard copy blit (or any other blit, as area fills take place after all shifts, masks and logical combination of sources)."
deimos is offline  
Old 15 October 2019, 10:11   #9
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
What is your end goal?

My method of doing vectors (no idea if its right, it's just what I got to work, sure there is a better way that noone is telling ) changes depending on what sort. For example from this intro https://www.pouet.net/prod.php?which=81350 in the vector routine part it swaps between convex (the glenz stuff) and complex (the cube split).

The way I did them:

Convex:
3 bpl interleaved. I clear the screen in 1 blit (bounded for the size of the object) I draw all the lines for the entire object. Then fill the 3 bpls in one blit (again bounded around the object). During the clear screen blit and the fill blit I do all the cpu calculations.

Complex.
I draw each face in a 1bpl scratch buffer and then fill it in place on the scratch buffer. Then I cookie cut/copy blit them onto the main screen in order of depth. From my source I'm using a $dfc minterm (ABD sources) for this which is using A as the source AND the mask (the filled polygon is its own mask), B for screen, D for screen. This ORs the polygon onto the screen keeping the background. Depending on the color I want I may do the copy onto 1 or more bitplanes. Feels like there's a better way to do this but I've not found it yet

This sounds similar to what you describe?
Antiriad_UK is offline  
Old 15 October 2019, 10:31   #10
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
My polygons are all guaranteed to be convex.

In your code are you filling to a scratch buffer and then blitting the completed polygon to the displayed buffer?

Edit: you are for the complex, what about the convex?

Edit 2: I understand, the convex stuff doesn't clear, only fills. So the complex stuff is what I'm trying to do, and you do it in two steps.

Last edited by deimos; 15 October 2019 at 10:37.
deimos is offline  
Old 15 October 2019, 10:45   #11
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
For convex I've got a 3 bpl screen buffer and 3bpl back buffer (interleaved). I'm drawing ALL the lines of the entire object on the 3 bpls of the back buffer. So if a line needs to be in color03 I'll draw that line on bpl1 and 2. Then I'm doing a single fill over all 3 bpls - I'm not copying individual faces or anything. For that to work the line draw has to draw inverted lines so that intersections between polygons on the same bpl get erased and the fill continues to work without glitching. I've always used other people's line draw routines (lazy) and they usually come in a "invert line" by default.

I always assumed everyone did it this way for convex but I often see talk of scratch buffers and copy+filling individual polys and then erasing the scratch buffer by redrawing (inverting) the same lines. But never got it to work faster myself for convex.

Edit: see attachement. That's what my glenz looks like before it's filled. The colors are a bit weird (glenz related) but you get the idea.
Attached Thumbnails
Click image for larger version

Name:	vectorfilled.png
Views:	35
Size:	6.4 KB
ID:	64771  

Last edited by Antiriad_UK; 15 October 2019 at 10:54.
Antiriad_UK is offline  
Old 15 October 2019, 10:59   #12
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Quote:
Originally Posted by Antiriad_UK View Post
talk of scratch buffers and copy+filling individual polys and then erasing the scratch buffer by redrawing (inverting) the same lines
Exactly, that's what I always understood was the one true way to do it, but if the blitter can't fill and cookie-cut at the same time, then we need to fill to the scratch area and copy over, which means you can't just xor the scratch buffer line to erase them, you have to clear the fill you did to the scratch area before you can reuse it.
deimos is offline  
Old 15 October 2019, 11:02   #13
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
What you can do though is have two scratch buffers:
1. Draw lines on Scratch A
2. Do a Copy+Fill to Scratch B
3. Redraw lines on Scratch A to erase

Edit: Don't need to clear scratch B as that gets auto cleared with each copy (assuming you are copying a bounded area).
Antiriad_UK is offline  
Old 15 October 2019, 11:03   #14
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Quote:
Originally Posted by Antiriad_UK View Post
Edit: see attachement. That's what my glenz looks like before it's filled. The colors are a bit weird (glenz related) but you get the idea.
Unfortunately I can't do that, I need to clear or set the polygon shape on each bitplane depending on the polygon's colour as there will already be stuff drawn on screen that I need to draw over.
deimos is offline  
Old 15 October 2019, 11:04   #15
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Quote:
Originally Posted by Antiriad_UK View Post
What you can do though is have two scratch buffers:
1. Draw lines on Scratch A
2. Do a Copy+Fill to Scratch B
3. Redraw lines on Scratch A to erase
But:

4. Erase Scratch B
deimos is offline  
Old 15 October 2019, 12:15   #16
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
Quote:
Originally Posted by deimos View Post
But:

4. Erase Scratch B
See edit above.
If you copy+fill to scratch B using a bounding rectangle for the size of the polygon. And then you copy from scratch B to screen using the same rectangle, then you actually never have to clear scratch B.
Antiriad_UK is offline  
Old 15 October 2019, 12:44   #17
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Quote:
Originally Posted by Antiriad_UK View Post
See edit above.
If you copy+fill to scratch B using a bounding rectangle for the size of the polygon. And then you copy from scratch B to screen using the same rectangle, then you actually never have to clear scratch B.
So, how does this auto-clearing work then?
deimos is offline  
Old 15 October 2019, 13:09   #18
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 218
Two polygons, let's say bounding rectangle of these are top left/bottom right:
poly1: 10,10/100,100
poly2: 25,25/75,75 (i.e. smaller that poly1 and also inside poly1)

1. Draw poly1 to Scratch A
2. Copy+fill 10,10/100,100 area to Scratch B
3. Cookie cut copy from 10,10/100,100 area to screen
4. Redraw poly1 on Scratch A
5. Scratch A is now totally blank, Scratch B still used
6. Draw poly2 to Scratch A
7. Copy+fill 25,25/75,75 area to Scratch B. This won't clear the "outside" portion of poly1, but it doesn't need to. The new 25,25/75,75 area is all we care about and that is cleared from the copy.
8. Cookie cut copy from 25,25/75,75 area to screen
9. Redraw poly2 on Scratch A

Scratch B never gets totally cleared, but it doesn't matter.
Antiriad_UK is offline  
Old 15 October 2019, 13:17   #19
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 550
Oh, you're relying on the copy+fill clearing the bits outside the polygon. That does make sense and seems like an easy thing to implement. I'll get to it this afternoon.

Thanks.
deimos is offline  
Old 15 October 2019, 13:23   #20
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 619
You certainly don't want to cookie cut anything...

Your scratch area only needs to be one bitplane size.

You can then "OR" the polygon from the scratch area to the bitplanes it is required on, and "NOT AND" to the bitplanes you want to clear the polygon in.
DanScott is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Blitter: clean-up line drawing and fill mode idle cycles. ross Coders. Asm / Hardware 9 12 May 2018 22:32
Blitter Vertical Fill 71M Coders. Asm / Hardware 34 16 November 2017 22:31
Blitter fill problem mekhall Coders. Asm / Hardware 7 20 June 2016 00:04
Blitter fill timing leonard Coders. Asm / Hardware 42 01 September 2014 11:00
Clipping line for blitter fill leonard Coders. Asm / Hardware 12 27 April 2013 12:03

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 00:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09470 seconds with 14 queries