5 bitplanes ...

[chadderack]

Originally Posted by Jobbo

You can't do that. The copper is way too slow. It can change one color every 8 pixels at best.

Good to know. Thank you.

It sounds like you are overestimating the capabilities of the Amiga and especially the A500, do some tests so you know what you're up against.

It's early days still, trying to figure things out. Glad folks like you, Dan Scott, phx, Photon, Graeme, jotd and others are here with the experience.

[chadderack]

...continuing reading Georg's scrolling tricks:

BITMAPWIDTH=352
(x=352,y=0) = (x=0,y=1)

(MIND=BLOWN)



It's simple realizations like that that will help quite a bit

[jotd]

Originally Posted by Jobbo

You can't do that. The copper is way too slow. It can change one color every 8 pixels at best./Q

I heard that but then how do they do plasma effects with smallest width than 8?

It sounds like you are overestimating the capabilities of the Amiga and especially the A500, do some tests so you know what you're up against.

Plenty of games demonstrate that a good port is possible. But it's not easy extracting that kind of performance.

yes, looking at Turrican the A500 seems super powerful but it's because the coders are just mutants.

[mcgeezer]

Believe me, I've implemented that algorithm in assembler and it was not easy (at least it wasn't for me anyway).

[mcgeezer]

Originally Posted by jotd

I heard that but then how do they do plasma effects with smallest width than 8?

.

It has enough time to do one palette change per 4 pixels if i recall the HRM... (i could be wrong though).

[DanScott]

Originally Posted by jotd

I heard that but then how do they do plasma effects with smallest width than 8?

They don't With up to 4 bitplanes DMA running, the copper can change one hardware register every 8 pixels.

Anything else you've seen is just a "trick" to deceive the eye

[jotd]

what about with only 1 bitplane DMA running? (sorry for hijacking the thread but I need to know)

[DanScott]

Originally Posted by jotd

what about with only 1 bitplane DMA running? (sorry for hijacking the thread but I need to know)

0 to 4 bitplanes is the same... 8 pixels per write, of course, you can WAIT for a 4 pixel position, but all writes are 8 pixels per register

[defor]

Originally Posted by jotd

what about with only 1 bitplane DMA running? (sorry for hijacking the thread but I need to know)

Copper MOVE requires 4 DMA time-slots. Therefore it can change a single color register every 8 low-res pixels, and that's only if there are those 4 slots available -- fetching of more than 4 bitplanes eats out of those slots.
See diagram.
Plasma effects usually combine color changes in copper-list with a clever use of bitmap data (plus various horizontal shifts, changing bitplane pointers to pre-computed gradients in bitmaps per line, etc.)

[DanScott]

Another couple of things to consider about Black Tiger....

Level 3 map wraps around in the X, so your scrolling/tiledraw system needs to handle that (as well as your object triggering system)

There are also animated tiles (lava in level 4, Entrance/Exit signs for the dungeons amongst others)

Most of the sprites appear throughout all the levels with distinct (and quite variable) palettes (eg.. purple orcs, green orcs etc..)

[chadderack]

Originally Posted by DanScott

Another couple of things to consider about Black Tiger....

Level 3 map wraps around in the X, so your scrolling/tiledraw system needs to handle that (as well as your object triggering system)

There are also animated tiles (lava in level 4, Entrance/Exit signs for the dungeons amongst others)

Most of the sprites appear throughout all the levels with distinct (and quite variable) palettes (eg.. purple orcs, green orcs etc..)

Thank you, Dan.



When reversing the source code I did notice that Level 3 is 64x128 (tiles) unlike the other levels (128x64). Also did remember that the rock tiles are animated to look like they are glowing in level 4 (and IIRC there might be other places in other levels). I assume those tile palettes can be animated via copperlist (with some slots left open).

....

Right now I've been implementing a test scroll in the main.asm source.

(What follows is probably old hat to most of you, but I just want to see if I'm on the right track).

Just to be quick I loaded the entire undecoded tile bitmap data from Black Tiger (gfx2) and decoded the Level 1 map into a 2048x1024 screen buffer.

It scrolls, but not properly... basically because I decoded it into a 2048x1024 "bitmap" and set the bitplane pointers directly to that buffer, instead of setting up a separate screen buffer.

Once the scroll (horizontal) gets past the first 320 pixels, the bitplane pointers aren't pointing at the correct data.

I need to modify the test code to have a separate screen buffer, and then copy the first 352x256 pixels into it (352 to account for "extrawidth"). (I'm uncertain if that's right).

When doing this properly, of course, we (you or me or whomever) would probably be using a re-encoded bitmap that is more Amiga friendly in terms of decoding (and palette)... but I just wanted to see part of the Level 1 map on screen.

I'll add the screen buffer in my next code update and see if I can't get this working properly. The ScrollingTricks.lha algorithm--when blitting a tile during scroll-- seems to want to grab an already decoded tile from a block tile bitmap... but I don't have that yet. I'm guessing decoding tiles on the fly would be a performance hit.

[chadderack]

Here's what the scroll looks like right now (as described in the post above)

https://www.dropbox.com/s/pe97ikall1...12-26.mp4?dl=0

[chadderack]

All right, I guess I'll have to ask this here... since I'm getting stumped.

Consider that I want to copy all the bits from the source screen to the destination screen with a blit.

I have 4 bitplanes, 320px wide and 256px high for the screen buffer. One would think you could get it done in a single blit... but apparently that is exactly the size limit of a single blit.

For the "h" term of BLTSIZE...

h=4*256*64 = $10000, or 65536... too large to fit into the word-size for BLTSIZE.

So you figure... two blits? One for the top half of the screen, one for the bottom half?

Doing that... I seem to run into an issue where if I blit a second time--even after moving BLTDPTH down by $5000 bytes (halfway down the screen)... what was apparently blitted to the top half of the screen is zeroed (blacked) out.

I wouldn't think this would happen, since the BLTDPTH destination pointer changed... but ...

here's the naughty/broken code. Probably something obvious I'm missing...

    lea DecodedGraphic,a3
    lea Screen,a4
    move.l a3,d3
    move.l a4,d4

    move.w #$09F0,BLTCON0(a6)                               ;use A and D. Op: D = A
    move.w #$0000,BLTCON1(a6)
    move.w #$FFFF,BLTAFWM(a6)
    move.w #$0000,BLTALWM(a6)
    move.w #0,BLTAMOD(a6)
    move.w #0,BLTDMOD(a6)
    move.l d3,BLTAPTH(a6)
    move.l d4,BLTDPTH(a6)

    move.w #(h*tile_bitplanes*64)/2,BLTSIZE(a6)

    ;first half of screen blitted

    add.l #$5000,d3                     ;second half of source
    add.l #$5000,d4                     ;second half of dest

    move.l d3,BLTAPTH(a6)
    move.l d4,BLTDPTH(a6)

    move.w #(h*tile_bitplanes*64)/2+screen_width/16,BLTSIZE(a6)

[ross]

Originally Posted by chadderack

For the "h" term of BLTSIZE...

h=4*256*64 = $10000, or 65536... too large to fit into the word-size for BLTSIZE.

You are lucky, h=0 equals 1024(*x) so it is the max usable value

[chadderack]

Originally Posted by ross

You are lucky, h=0 equals 1024(*x) so it is the max usable value

Wow...

Here I thought I was just being dumb, not using another source (B or C and fixing up the pointer to point at the second half of the source)

[chadderack]

BTW, thank you ross! (And everyone else so far ) It's fun, and a great challenge so far.

So the reason why you see the "torn-up" looking screen (in my current code) after the screen scrolls 1 tile to the left is that the bitplane pointers have moved 20 columns, or 40 bytes. That would put the bitplane pointer that started out pointing at bitplane 0 to the starting point for bitplane 1. (Or is it 3 and 2?)

At any rate (after 20 columns), it goes something like:

bplptr0 = bplptr1
bplptr1 = bplptr2
bplptr2 = bplptr3
bplptr3 = bplptr3+40 (or bplptr0 to the next vertical line in the graphic)

Of course, none of those bitplanes are going to combine correctly once the pointers are out of sync.

After 60 more columns scroll by, though, we get what "looks" like the bitplanes decoded correctly... but they are shifted down by an entire line (one pixel in the Y direction).

...

So the problem is I've decoded the tile bitmap to suit a 320x256 screen instead of decoding it in a more natural 256x256x4 format. A 256x256x4 block is $8000--being that each bitplane takes only 32 bytes (16 columns of 16-pixel wide/high tiles)... 2 bytes per column.

This divides Black Tiger's maps (except level 3) into 8 BIG tile blocks wide by 4 big tile blocks tall. (For level 3, it's 4 BIG blocks wide, and 8 BIG blocks high).

...

To fix the bitplane "ripping" problem described above, I need to fix the decoding so that it arranges the data into chunks of 256x256x4, not 320x256x4... and then fix the pointers when copying the screen (and tiles) from the source bitmap.

[chadderack]

Just about to spend the rest of the evening with my fine girlfriend...

...came by to say that I think I've worked out the maths for scrolling in my particular situation. I'll implement this and see what happens.

            HORIZONTAL SCROLLING-RIGHT; 4 BITPLANES
            DEST (SCREEN) BITMAP= 16+320(visible)+16 = 352px
            SOURCE BITMAP       = 2048px

            SRC:          DEST:  (BITPLANE PTR OFFSETS)   SRC         DEST      X-POS (PIXELS)
            -----------------------------------------     -----------------------------------------
PIXELS
SCROLLED  1      $B0      $2C                              $160         $0
          2    $10B0     $2EC                              $960       $160
          3    $20B0     $5AC                             $1160       $2C0
          4    $30B0     $86C                             $1960       $420
          5    $40B0     $B2C                             $2160       $580
          6    $50B0     $DEC                             $2960       $6E0
          7    $60B0    $10AC                             $3160       $840
          8    $70B0    $136C                             $3960       $9A0
          9    $80B0    $162C                             $4160       $B00
          A    $90B0    $18EC                             $4960       $C60
          B    $A0B0    $1BAC                             $5160       $DC0
          C    $B0B0    $1E6C                             $5960       $F20
          D    $C0B0    $212C                             $6160      $1080
          E    $D0B0    $23EC                             $6960      $11E0
          F    $E0B0    $26AC                             $7160      $1340

[dlfrsilver]

Great job !

[chadderack]

Some positive developments (for me, anyway) and the Black Tiger project
here.

[axilmar]

Originally Posted by jotd

From 1986 (IMHO) arcade games beat up ECS hardware to a pulp.

Given that in September 1986 Outrun was released, and in 1985 Hang on and Space Harrier was released, the above is an understatement...

EDIT:

The arcade board of Black Tiger used ...two Z80 CPUs (According to this: http://www.thepixelpump.com/blacktiger/specs.php). Yeap, a game with two Z80 CPUs used 1024 colors on screen and was much better than what the Amiga was doing at the time!!!