Blitter fill, nothing happens?

[deimos]

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.

[Antiriad_UK]

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

[deimos]

Originally Posted by Antiriad_UK

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.

[Antiriad_UK]

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 :/

[deimos]

Originally Posted by Antiriad_UK

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.

[Antiriad_UK]

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 ;£

[deimos]

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.

[deimos]

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)."

[Antiriad_UK]

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?

[deimos]

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.

[Antiriad_UK]

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.

[deimos]

Originally Posted by Antiriad_UK

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.

[Antiriad_UK]

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).

[deimos]

Originally Posted by Antiriad_UK

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]

Originally Posted by Antiriad_UK

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

[Antiriad_UK]

Originally Posted by deimos

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.

[deimos]

Originally Posted by Antiriad_UK

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?

[Antiriad_UK]

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.

[deimos]

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.

[DanScott]

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.