[request] Not exactly an ST port.... Black Tiger Redux?

[lmimmfn]

Thanks for the update, dont worry, all software has bugs, youll get there

[chadderack]

Cheers lmlmmfn

So up/down is working about 95%... a couple of remaining issues:

*When you reach the bottom of the map after a full downward scroll, a single block at the left of the screen (one row up from the "bottom" of the top half of the map) is not getting blitted. Seems like a one-off bug.

*During upward scroll... about 4 tile rows from the top, the split seems to shift down by a single scan line. (Not sure if this is an emulation glitch or a bug. If I were a betting man, I'd bet it's a bug).

I'm going to try integrating all 4 directions in a test, and then... after that... combined scrolls for 8-way scroll.

[chadderack]

Turns out the missing block? Not a bug.
The block shown isn't supposed to be filled by a vertical scroll--up or down.



The reason is that it is in a fill column, and vertical scroll should only deal with fill rows.
(The yellow background is just temporary--to show the vertical split).



The reason the block is blank is that on the initial load of the bitmap, I'm only blitting the visible screen, plus one row below--so that I can start my scroll down/scroll up test.

In the real game, I'll blit the entire screen buffer (352x288) so that all the fill areas will have their correct tiles before any scroll.

...

I'm going to squash the scanline/vertical split bug mentioned earlier (now) and then I have to think about how to blit the blocks that remain when a player reverses direction in the middle of a scroll.
Conceptually... because I'm only blitting either one or two blocks per step (horizontal is always just one block), if I get partway into a scroll and reverse the direction, the blocks that didn't get blitted should get blitted.

Maybe I don't have to worry about that, because scrolling partway down and then up, I won't see the fill row for the bottom (that was partially blitted) because the OTHER fill row is still on screen at the top, and scrolling upward will cause the fill row (at the bottom) to finish.

But I'll have to think about this.

[chadderack]

Vertical split bug will be a non-issue if the screen buffer <= 256 pixels high. Good news, because Black Tiger is 256x224

So the scrolling code for the 4 cardinal directions is working fine right now as is.

I'm going to resize the screen buffer--but will have to think about how to display other elements in the rest of the Amiga screen area without using dual playfields (because I still want at least 4 bitplanes for the game screen). Sprites? A vertical split at 256px? Anyway... that's down the road.

Once the screen buffer is resized and I've adjusted the relevant scroll code, I'm going to implement the following plan for 8 way scroll.
Maybe someone can tell me if BLIT ASCENDING mode needs to be considered for the order in which the blocks need to be blitted for 8 way scroll. I think I have it right (blit order, described below)

  Fill column: 18 BLOCKS (288 screen buffer height); 16 BLOCKS (256 screen buffer height)
  Fill row:    22 BLOCKS (352 screen buffer width);  18 BLOCKS (288 screen buffer width)

  -----------------
    CORNER BLOCKS
  -----------------

  These blocks are blocks that have not yet been blitted; they come from 
  the source bitmap relative to what's already on screen
  
  [A] -- TOP LEFT
  [B] -- TOP RIGHT
  [C] -- BOTTOM LEFT
  [D] -- BOTTOM RIGHT

  -------------
    ALGORITHM
  -------------

  BLIT ORDER: R->D->U->L (BLIT IN ASCENDING MODE)
  
  R:   All blocks fill column (left column)
  L:   All blocks fill column (right column)
  U:   All blocks fill row (bottom row)
  D:   All blocks fill row (top row)
  R+D: All blocks fill row (top row);         all blocks fill column (left column) (overlap is [A]--first blit)
  R+U: All blocks fill column (left column);  all blocks fill row (bottom row)  (overlap is [C]--last blit)
  D+L: All blocks fill row (top row);         all blocks fill column (right column)(overlap is [B]--last blit)
  U+L: All blocks fill column (right column); all blocks fill row (bottom row)  (overlap is [D]--first blit)
  
  D: Check R (for [A] overlap)--If R, skip [A]
  U: Check R (for [C] overlap)--If R, skip [C]
  L: Check D (for [B] overlap); Check U (for [D] overlap)--If D, skip [B]. If U, skip [D].

[chadderack]

After DanScott and Photon of Scoopex helped me squash a bug (race condition), the code started to work much better and I was able to sort out all 4 scroll directions and integrate them.

Video showing 4 directions smoothly scrolling

https://www.dropbox.com/s/dry5r0em9t...all_4.mp4?dl=0

Now, I'm implementing the plan described in my last post. In fact, in the video above, the right and left directions are already done--they now blit 18 blocks per 16px of travel (one block to start, a double block (two tiles high), 14 singles, another double, and one single).

This is so that the first and last blocks can be skipped ([B] or [D]) if scrolling left and down [B] or left and up [D]. That's because they will have already been blitted by the vertical scroll. Right scroll never skips. It always goes first.

Now, I'll change the vertical scrollers to blit like so:

[1][1][1][1][2][1][2][1][2][1][2][1][2][1][2][1]

where the first block is [A] and the last block is [B] (if scrolling down) and the first block is [C] and the last block is [D] (if scrolling up)

[1]=single tile, [2]=two tiles wide

All seems to be going to plan.

[jotd]

this is a great step forward.

[chadderack]

Cheers, jotd

Scroller "working" with joystick input. I'm using an XBOX 360 controller (USB) and it seems very responsive.

(video demonstrating joystick input w/scroll)
https://www.dropbox.com/s/p7pgqzefgp...oller.mp4?dl=0

Quick changes of direction seem to leave unblitted blocks. That's because I don't "finish" blitting unblitted blocks when switching directions (yet). Scrolling up and right leaves a trail of diagonal (unblitted) blocks from the top right corner.

I'm concerned that scrolling just a pixel in either or both directions per frame might seem slow. Seems like MAME runs Black Tiger a bit faster and scrolling one pixel is "faster," if that makes sense. But you can't go faster than the video refresh rate for frame rate. I can modify the code to scroll "faster" by implementing a scroll velocity--but 2 pixels per frame might seem excessive. I'd have to use a frame counter and scroll 3 pixels every two frames or something, which might seem too jerky.

Otherwise, things are working pretty well.

Guess the next step is to sort the "unblitted blocks" when switching direction and then... maybe the real fun begins

[chadderack]

Small update--MUCH BETTER scrolling 8 ways (video)

Bugfixes:

• Was skipping the wrong block when blitting up (was skipping [D] instead of [C]). That's why there was a diagonal trail of blocks from the upper right corner in the previous video.
  
• "Save words" work--this is the word-size value that is saved/restored when you change scroll direction from right/left and back. If the savewords aren't working, you'll see 16 pixel "dashes" (artifacts) after changing direction.
  
• A one-off map x bug when scrolling back left after scrolling right.

The result--much better.

The only issue now is this: Because I blit 18 blocks when scrolling left or right, at least two of the blocks must be two tiles high. Currently, I'm blitting block 1 and block E (the 2nd and 15th blocks) as two-tile high blocks. Because of this, when changing direction diagonally, the "inside" block (the lower tile of block 1 or the upper tile of block E) gets left on the screen. You probably saw one or two of those in the current video.

I should just implement the right-left blits like Georg did--shift everything down one tile and blit 17 blocks (not 18). Then the problem should take care of itself, because any "inside" block will already have been on the screen when the diagonal scroll starts.

I'll make the change in the morning (if there's time).

...

In other news, I just did something crazy--ordered one of these. I must be crazy

[chadderack]

Fixed! The scroller is fixed 100%. No issues now.

I had to adjust the algorithm like so. Essentially now, neither up nor down scroll ever blits a block to the top left corner or bottom left corner block of the fill column:

R+D: All blocks fill row (top row); all blocks fill column (left column) except [A]
R+U: All blocks fill column (left column); all blocks fill row (bottom row) except [C]

D: Skip [A] always
U: Skip [C] always

A short video to show that everything works

https://www.dropbox.com/s/wet5pi8z5b...00%25.mp4?dl=0


Now, on to bigger/better things (what... an 8-way scroller isn't the best thing? ) Think I'll work on palettes, and a plan to re-encode the tileset--narrowing down the list of tiles needed per level so that only those are brought in by disk (before each level) or something.

I'm also going to stop bringing in the actual data/tiles from the arcade version--the tileset will be re-encoded for the Amiga specifically.

[skyzoo73]

Can I say that this is one of the discussions I follow with the most interest on the forum? It will be because together with G'n'G it is one of my favorite arcades, and when I say favorites I mean that if I had to choose 5 arcades to lock myself in a bunker due to a nuclear holocaust surely Black Tiger / Black Dragon would be among them. Congratulations on the titanic effort in trying to bring it to the Amiga, I hope with all my heart you succeed. Keep it up !

[chadderack]

Thank you kindly, skyzoo! We're going to give it our best (me and the mouse in my pocket). Wouldn't be able to do it without the fantastic cast of skilled and knowledgable programmers on this site

https://www.dropbox.com/s/4nbvi15wa9...aller.mp4?dl=0

Another short video. The screen has been "resized" to the normal Black Tiger screen size (256x224) and I've hidden the fill/blit columns. The one on the left is hidden with a 256px high black sprite. Wondering if there's a better way to hide it. I tried to do it with DIWSTART/STOP but couldn't figure it out. Probably has something to do with always skipping the first two bytes of the buffer and never scrolling back to zero (only to buffer+2).

I've also put some nominal text on the screen (for debug, possibly) just to see how that's handled (also sprites... since I don't want to mess with cookie cutter blits yet).

Anyway this works well (to my liking).

The next steps are sort of wide open--and it feels like the Wild West up in here. There's--pretty much everything left to do. Will probably start working on conversion of the graphics assets into something that will work well. I think DanScott says he's worked out the best way to do the tile encoding so that the maximum number of colors from the arcade game make it into the port version. I'll also give it a go and see where this leads.

Thanks

[chadderack]

Map coordinates showing on screen (for debug purposes)

https://www.dropbox.com/s/j1yogr8n4y...oords.mp4?dl=0

Seems I have a vertical split bug to fix when the Y position <= $10.

[chadderack]

Figured it was time to create a proper project thread.

Link