14 October 2021, 03:07 | #241 |
Registered User
Join Date: May 2018
Location: Ireland
Posts: 687
|
Thanks for the update, dont worry, all software has bugs, youll get there
|
14 October 2021, 13:30 | #242 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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. |
14 October 2021, 15:32 | #243 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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. |
15 October 2021, 16:27 | #244 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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) Code:
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]. Last edited by chadderack; 15 October 2021 at 18:16. |
20 October 2021, 19:03 | #245 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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. |
20 October 2021, 21:36 | #246 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,359
|
this is a great step forward.
|
21 October 2021, 12:42 | #247 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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 |
23 October 2021, 00:06 | #248 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
Small update--MUCH BETTER scrolling 8 ways (video)
Bugfixes:
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 |
23 October 2021, 13:21 | #249 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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: Code:
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 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. |
23 October 2021, 14:09 | #250 |
Registered User
Join Date: Sep 2019
Location: Italy
Age: 51
Posts: 302
|
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 !
|
26 October 2021, 00:44 | #251 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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 |
26 October 2021, 14:11 | #252 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Black Tiger | anata | project.Maptapper | 1 | 19 September 2013 07:24 |
Mace vs. Black Tiger | Kodoichi | Nostalgia & memories | 35 | 13 April 2011 13:32 |
Black Tiger | Uncle Micko | support.Games | 6 | 07 October 2007 03:13 |
Black Tiger NES | NfernalNfluence | Retrogaming General Discussion | 3 | 08 May 2007 15:48 |
[Fixed] Black Tiger dev. | haynor666 | HOL data problems | 2 | 08 July 2003 08:41 |
|
|