Quick question about the Blitter (and image stride)

[chadderack]

For an image to look right on the Amiga screen...

...does a source image in a chip memory buffer need to match the stride of the screen if you want to blit any part of it to the screen buffer?

EX: Source image is 256x256x4... bitplane pointers every $20 bytes
Screen is 320x256x4... bitplane pointers every $28 bytes

ETA: The source is interleaved, if that wasn't clear.


Thanks

[DanScott]

You have a separate modulo for each blitter channel

So modulo for the source (channel A) would be 0, and the modulo for destination (channel D) would be 8 ($28-$20)

[chadderack]

Originally Posted by DanScott

You have a separate modulo for each blitter channel

So modulo for the source (channel A) would be 0, and the modulo for destination (channel D) would be 8 ($28-$20)

Cool, that's what I thought.
I've decoded the bitmap that way (as 256x256x4, interleaved)
and tried this:

    lea DecodedGraphic,a3
    lea Screen,a4

    move.l a3,d3
    move.l a4,d4
	
    move.w #$0DFC,BLTCON0(a6)                               ;use A,B, D. Op: D = A+b
    move.w #$0000,BLTCON1(a6)
    move.w #$FFFF,BLTAFWM(a6)
    move.w #$0000,BLTALWM(a6)
	
    move.w #0,BLTAMOD(a6)
    move.w #28,BLTBMOD(a6)									;rightmost columns (4) repeated
    move.w #8,BLTDMOD(a6)
    move.l d3,BLTAPTH(a6)
    move.l d5,BLTBPTH(a6)
    move.l d4,BLTDPTH(a6)
	
    move.w #$14,BLTSIZE(a6)

...and this is the result. Guess I'm not getting it or something. Should the decoded bitplanes be non-interleaved? When decoding the source bitmap,
I re-interleaved the bitplanes every $20 bytes (32) because the image is 256px wide.

Thanks Dan!

[chadderack]

Hang on... maybe my code isn't quite setting up the stride correctly. I'll have to check into this. Thanks, Dan... for confirming. I think the bitplane pointers are still $28 bytes apart in the decoded source.

[DanScott]

If you are just copying data, then you just need D=A minterms..

move.w #$09F0,BLTCON0(a6)

and no need to set up anything to do with channel B

you'll probably need #$FFFF in BLTALWM too (or it will mask off the last source word on each line)

[chadderack]

Originally Posted by DanScott

If you are just copying data, then you just need D=A minterms..

move.w #$09F0,BLTCON0(a6)

and no need to set up anything to do with channel B

you'll probably need #$FFFF in BLTALWM too (or it will mask off the last source word on each line)

I am just copying data, but it needs to be copied twice (apparently).

I'm decoding the tile bitmap into 256x256 bitmap blocks, like this:

TILES:
[000][001][002][003][004][005][006][007][008][009][00A][00B][00C][00D][00E][00F]
[010][011][012][013][014][015][016][017][018][019][01A][01B][01C][01D][01E][01F]
[020][021][022][023][024][025][026][027][028][029][02A][02B][02C][02D][02E][02F]
[030][031][032][033][034][035][036][037][038][039][03A][03B][03C][03D][03E][03F]
[040][041][042][043][044][045][046][047][048][049][04A][04B][04C][04D][04E][04F]
[050][051][052][053][054][055][056][057][058][059][05A][05B][05C][05D][05E][05F]
[060][061][062][063][064][065][066][067][068][069][06A][06B][06C][06D][06E][06F]
[070][071][072][073][074][075][076][077][078][079][07A][07B][07C][07D][07E][07F]
[080][081][082][083][084][085][086][087][088][089][08A][08B][08C][08D][08E][08F]
[090][091][092][093][094][095][096][097][098][099][09A][09B][09C][09D][09E][09F]
[0A0][0A1][0A2][0A3][0A4][0A5][0A6][0A7][0A8][0A9][0AA][0AB][0AC][0AD][0AE][0AF]
[0B0][0B1][0B2][0B3][0B4][0B5][0B6][0B7][0B8][0B9][0BA][0BB][0BC][0BD][0BE][0BF]
[0C0][0C1][0C2][0C3][0C4][0C5][0C6][0C7][0C8][0C9][0CA][0CB][0CC][0CD][0CE][0CF]
[0D0][0D1][0D2][0D3][0D4][0D5][0D6][0D7][0D8][0D9][0DA][0DB][0DC][0DD][0DE][0DF]
[0E0][0E1][0E2][0E3][0E4][0E5][0E6][0E7][0E8][0E9][0EA][0EB][0EC][0ED][0EE][0EF]
[0F0][0F1][0F2][0F3][0F4][0F5][0F6][0F7][0F8][0F9][0FA][0FB][0FC][0FD][0FE][0FF]

This creates a 256x256 bitmap of the first part of the Level 1 map.

The next block of tiles gets decoded into the bitmap immediately after, at [100],[101], etc.
This is because I want to create a temporary bitmap 2048x256 for scroll testing. Each bitmap "block" of 256px x 256px follows the previous.

The issue is... I'm trying to blit the first block (square... 256x256 pixels) to the left half of the screen like this:



Then I want to start the second block (a 64x256 strip) on the right side of the 320px screen, like this:



The trouble is... I can't seem to get that to work either by
1) doing two blits (the second blit destroys what's in the screen buffer):

    lea DecodedGraphic,a3
    lea Screen,a4

    move.l a3,d3
    move.l a4,d4

    move.w #$09F0,BLTCON0(a6)                    ;use A, D. Op: D = A
    move.w #$0000,BLTCON1(a6)
    move.w #$FFFF,BLTAFWM(a6)
    move.w #$FFFF,BLTALWM(a6)

    move.w #0,BLTAMOD(a6)                        ;256px wide (16 tiles)
    move.w #8,BLTDMOD(a6)                        ;320px wide (20 tiles) - 4 tiles
    move.l d3,BLTAPTH(a6)
    move.l d4,BLTDPTH(a6)

    move.w #$10,BLTSIZE(a6)                      ;16 tiles/cols

    add.l #$8000,d3                              ;Move to next 256x256 px tile block
    add.l #32,d4                                 ;Move to right side of screen

    move.w #24,BLTAMOD(a6)                       ;256px wide; first 4 tiles
    move.w #32,BLTDMOD(a6)                       ;320px wide; last 4 cols/tiles
    move.l d3,BLTAPTH(a6)
    move.l d4,BLTDPTH(a6)

    move.w #$4,BLTSIZE(a6)                       ;4 tiles/cols

2) Blitting once using two sources--one pointing to the source block, the second source offset $8000 bytes, or 256x256px.
I'm guessing since the BLTSIZE has to be $14 to cover all of the 320px screen .... the stride gets messed up

or

3) Blitting to two different temporary buffers--once for the big block, second time for the strip and then blitting a third time to the screen--combining both sources.

...

I'm not waiting for the next vertical blank to do the second blit. Should I be doing that, if doing two blits?

I probably won't need to do this "in game"... I just need to understand why the blitter can't seem to create a screen buffer from smaller images with different source widths.

[Galahad/FLT]

I'd be checking what that $8000 value you're adding actually means, as that value for instance is bigger than a 4 bitplane screen.

Whilst your blits are tiny, you have no blit wait, have you set WinUAE to do immediate blits to compensate for this?

[chadderack]

Originally Posted by Galahad/FLT

I'd be checking what that $8000 value you're adding actually means, as that value for instance is bigger than a 4 bitplane screen.

#$8000 is just the distance to the next block of 256x256 pixels (16x16 tiles). At 2px/byte... that comes out to $8000 (32,768 bytes). The strip of tiles shown in the pic was created by offsetting the source bytes by #$8000 so I know that's correct.

Whilst your blits are tiny, you have no blit wait, have you set WinUAE to do immediate blits to compensate for this?

I thought there might need to be a blitwait between the two blits, but WinUAE freezes. Does actual hardware do immediate blits? I'd rather emulate actual hardware and do things right.

ETA: I can just decode the tiles in such a way that they make one long bitmap, instead of 8 sequential 256x256 bitmaps. But I may lose tile indices that way. Not sure. Maybe I'll try it.



Thank you for your response, Galahad/FLT.

[chadderack]

Originally Posted by Galahad/FLT

...you have no blit wait, have you set WinUAE to do immediate blits to compensate for this?

After setting blits to immediate in WinUAE and fixing up my source to add WAITBLIT and (offset to right side of screen was 32 bytes--not 512) ... it puts the correct image on screen. Since it's just for a test, the immediate blit setting may be fine.

However, I think maybe I should just create a long bitmap 2048x256 instead of 8 separate 256x256 bitmaps.

[DanScott]

Originally Posted by chadderack

However, I think maybe I should just create a long bitmap 2048x256 instead of 8 separate 256x256 bitmaps.

Either way, that's 256k of chip ram just for that.... you need to re-think your strategy

[chadderack]

Originally Posted by DanScott

Either way, that's 256k of chip ram just for that.... you need to re-think your strategy

Yeah, for the whole game for sure

I just implemented the 2048x256px bitmap, and used a modulo of 216 and it worked.

The reason I bothered is to see the entire width of the top part of the level 1 map for scrolling tests.