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

[skyzoo73]

I don't know if it happens in the early levels, but as you can see in this video, it can happen that the scrolling goes diagonally from floor to floor if the player makes a jump like this. ( 33:02 )

[ Show youtube player ]

[chadderack]

Yeah that's a good example. You can see right there that the player character (once jumped down) more or less holds a steady x/y position on the screen while the map scrolls diagonally up and left. As soon as he lands, the y scrolling stops.

[sparhawk]

Originally Posted by Adropac2

Very glad to see chadderack doing this and yes the Arcade certainly doesn't get as much mention as you'd think it should

I was a lot in the arcades but I have never seen it before until about ten years ago on MAME where I immediately liked it. I certainly would have spent some amount if the arcade would have been available in my area.

[chadderack]

Ok, here for the bad... too...

... but it looks so pretty... like the Matrix

https://www.dropbox.com/s/yk7zs8prmm...11-36.mp4?dl=0

It's what happens when I implement a complex scrolling algorithm (with no real-time debugging) and the blitting is silly.



I'm going to punt on this version of the test scroll and make some hay with Solid Gold's version

[saimon69]

I can suggest youtube for more accessibility to videos

[chadderack]

Originally Posted by saimon69

I can suggest youtube for more accessibility to videos

Yeah, it's just a hassle to upload them there Dropbox is quick and dirty.
I have to remember passwords and stuff for YT... which is beyond my mental capacity at the moment

This version is a LITTLE better. At least it's blitting full tiles to the wrong place
(This is just an internal test of mine to mess with horizontal scrolling. Seems scrolling is the trickiest aspect to nail down. Once done, the rest should be relatively much simpler)

https://www.dropbox.com/s/6aeocyzzky...40-47.mp4?dl=0

[chadderack]

Well, it's like Moses gone up the hill and come back down all scraggly... hungry... naked... and ... well... better

Latest on scrolling:

https://www.dropbox.com/s/dge15cnef2...works.mp4?dl=0

(NOTE: I've widened the viewport so that the tiles being blitted (DIWSTART/STOP) can be seen while they are blitted. Ordinarily, that will be hidden).

Nearly completely works fine; one glitch is when you scroll through the entire screen buffer (352px), the first tile of the next screen (once the bitplane pointers are updated) is off by a single bitplane. That's why you see that single messed-up tile at the top of the screen... after the first entire screen scrolls by. You see it again right after the second screen scrolls by... (a few stray pixels showing).

This shows that the Black Tiger Level 1 map has a sizeable gap in the upper right quadrant... but there's a surprise at the end (wait for the black screen to scroll by...)

A few notes on scrolling:

*RIGHT scroll:

*Decrease the scroll value(s) by $11 (BPLCON1) to move right.
*When you go below zero ($00), that will be $ef. Fix that up to be $ff and then it's time to move all 4 bitplane pointers +2 bytes.
*Blit all tiles in the unseen far left column, one bitplane offset so that it is technically overwriting the second bitplane's pointer to that block.

That is because the tiles will "wrap" around the right side to the left, but one bitplane down.

*When you get through the entire buffer of bitplane pointers (or scroll one screen width), you have to update all 4 bitplane pointers by adding the bitplane offset to them. I just keep track of this by using a separate scroll pointer...instead of trying to calculate it from the start of the real buffer.

*LEFT scroll... haven't started

I feel all right about this. Like Bill & Ted returning after time traveling and getting their "chops." It took throwing most of the notes I'd gotten from places aside and trying to draw it out on paper and visualize. There's a lot to keep track of.

I assume LEFT scroll will be a challenge with the bitplane pointers, probably because of that wrapping that I talked about.

Anyway... I'm getting up to speed. Thank you for your patience so far
I promise I'm a good coder--just not up-to-speed with Amiga's hardware yet

[DanScott]

Originally Posted by chadderack

A few notes on scrolling:

*RIGHT scroll:

*Decrease the scroll value(s) by $11 (BPLCON1) to move right.
*When you go below zero ($00), that will be $ef. Fix that up to be $ff and then it's time to move all 4 bitplane pointers +2 bytes.

Definitely NOT the way to do it.

You want to calculate BPLCON1 and the bitplane pointer offset from a variable that stores the current X scroll position. It's just a few lines of code

[chadderack]

Originally Posted by DanScott

Definitely NOT the way to do it.

You want to calculate BPLCON1 and the bitplane pointer offset from a variable that stores the current X scroll position. It's just a few lines of code

That is a good idea. (16 - Video X Position % 16) * $11, or similar. $ff (for right scroll) maps to X=1... $0 to X=0, etc.

The bitplane pointer offset is being calculated from Video Position X... but I could probably be more efficient about it. Haven't done any optimizations at all.

I need to update the offset one frame sooner, it looks like... because of the messed up tile at the top of the column.

Thank you for the feedback, Dan

[chadderack]

I've done as Dan suggested and simplified that code. Also realized that I was scrolling/blitting in the wrong order, which was why the one tile didn't show up correctly. Now it does.

Working on left scroll next, then the vertical scroll.

[sparhawk]

Really cool to see your progress. Also your enthusiasm for that project is quite refreshing. I hope you will get it to a full game.

[chadderack]

Originally Posted by sparhawk

Really cool to see your progress. Also your enthusiasm for that project is quite refreshing. I hope you will get it to a full game.

Thank you Very kind of you to say.

[phx]

Originally Posted by chadderack

That is a good idea. (16 - Video X Position % 16) * $11, or similar. $ff (for right scroll) maps to X=1... $0 to X=0, etc.

Don't do any complex calculations. You want to use tables as much as possible for performance reasons. I thought you had a look into the Solid Gold sources?

Like this:

; Horizontal scroll codes for BPLCON1, xpos 0..15
ScrollTab:
        dc.w    $0000,$00ff,$00ee,$00dd,$00cc,$00bb,$00aa,$0099
        dc.w    $0088,$0077,$0066,$0055,$0044,$0033,$0022,$0011
[...]
        ; write fine scrolling code for (xpos & 15)
        moveq   #15,d0
        and.w   d2,d0
        add.w   d0,d0
        move.w  ScrollTab(pc,d0.w),Cl_scroll+2(a2)

BTW, is horizontal scrolling in BT unlimited or does a level/map end at some point?

[DanScott]

Originally Posted by phx

BTW, is horizontal scrolling in BT unlimited or does a level/map end at some point?

Level 3 wraps around (infinitely) horizontally

[chadderack]

Originally Posted by phx

Don't do any complex calculations. You want to use tables as much as possible for performance reasons. I thought you had a look into the Solid Gold sources?

Like this:

; Horizontal scroll codes for BPLCON1, xpos 0..15
ScrollTab:
        dc.w    $0000,$00ff,$00ee,$00dd,$00cc,$00bb,$00aa,$0099
        dc.w    $0088,$0077,$0066,$0055,$0044,$0033,$0022,$0011
[...]
        ; write fine scrolling code for (xpos & 15)
        moveq   #15,d0
        and.w   d2,d0
        add.w   d0,d0
        move.w  ScrollTab(pc,d0.w),Cl_scroll+2(a2)

Hi phx! Yes, I am actually using a table to avoid calculations
My current code looks quite a bit like this. Thank you!

[chadderack]

https://www.dropbox.com/s/3d3ny1ydol...works.mp4?dl=0

Scrolling both ways works. Got rid of most of the pointer arithmetic and just used a bitplane pointer.

I found that Georg's source (in C) had a lot of calculations in it, which is why I went that route initially. Now I use a lookup for the offsets, since (relative to the first bitplane pointer) the locations of the tiles to blit are constant.

Keeping a bitplane pointer to the first bitplane made everything dead simple. I need to test direction changes (which is where the "saveword" idea comes from).

I didn't use a linked list or blit full columns of tiles at once; just the one tile per pixel method. I think Solid Gold used the linked list/full column method... if I was reading phx's source correctly.

Next I'll try the quick direction changes and make the "saveword" work and then work on up and down (which should be much easier).

I'm glad I slogged it out. Had to go through a lot of debugging and thinking, but thinking did me some good.


ETA: Thank you to mcgeezer for suggesting using uaedbg. It helped squash a nasty bug I never would have found without it.

[vulture]

Looks good

[dlfrsilver]

yes it looks good !

[chadderack]

Still working on vertical scroll. It's about 85 % there.

The big issue is that the screen buffer has "empty" tile rows (16px high) both on top and on bottom for the incoming blitted tiles. (The buffer is 352x288... the display area is 320x256).

Because of these tile rows on top and bottom of the picture... the bottom half of the copper split screen (which has a "stationary" pointer) displays the incoming tiles in the wrong location. When scrolling down, for instance, the tiles blit two rows too high.

...

The pointers for the "top half" of the split are the ones that are incremented by a full scanline to "scroll" the screen down by a pixel.
The pointers for the bottom half of the split remain stationary; it's almost like dragging a rug from the top of the rug upward (because the copper split is what moves).

...

Checking phx's source, the code appears to also wait 32 pixels (allowing for a top/bottom tile row) before modifying the copper split... which is stationary with an FFDF wait before a 2C01 wait.

The 2C01 wait value starts to change once the first 32 pixels have scrolled down (y = 32). The problem with using that is that I have a "jump" in the copper split... it transitions (hard) from the "stationary" FFDF/2C01 to FFDF/3C01 (at y=32), then FFDF/3B01 (at y=33) after one more scroll.

The copper waits at FFDF/3C01 (y=32) don't do anything bad... I'm guessing because a vertical 3C wait (after FFDF) is out of range. FFDF/3B01 (y=33) causes the vertical split to jump downward 16 pixels or so.

...

There are also a few glitches when changing directions; the code is just scrolling down, then up in a loop. The change of directions blanks the screen for one frame. These glitches I should be able to sort out more easily. Getting my head around the other issue is proving to be a brain buster so far.

[chadderack]

Code is better; the reason for the "jump" is that my coordinate system (video x/y) was off by 16 pixels (1 tile height).

Still off... because I'm scrolling between y=1 and y=255, which causes the last blit (going both up and down) to get skipped. I need to sort the video coordinate system.