18 August 2020, 13:36 | #21 | ||
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Quote:
It's basically just a bug I need to squash. |
||
18 August 2020, 18:43 | #22 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
I ended up cheating and overlaying sprites at the top border.
It was just causing too much of a headache to fix properly. I’ll use the sprites for a score panel and some parralax. |
27 August 2020, 21:25 | #23 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
I just want to ask a question real quick....
Is it possible to do an 8-way scroll routine (single speed updates), by blitting only 1 or 2 tiles on either the vertical or horizontal axis? The few games I have looked at (Chuck Rock, Zool, Robocod) all blit an entire wall of tiles in the direction of travel. Has anyone achieved this or was I striving for the impossible? Geezer |
27 August 2020, 22:27 | #24 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Quote:
Quote:
|
||
27 August 2020, 22:39 | #25 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
My scroll engine needs to move pretty fast though... probably 4 pixel increments per second frame and the only way I have been able to get it to work is if I blit an entire wall either horizontally or vertically. Edit - Just moving horizontally or vertically in one direction is pretty easy for me to achieve... Apidya/Rygar moves in 2 pixel increments requiring two tiles to be blit horizontally (or vertically). It's the mulit-directional issue I can't solve without blitting the whole wall - literally driving me crazy. Last edited by mcgeezer; 27 August 2020 at 23:00. |
|
27 August 2020, 22:40 | #26 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
phx anticipated me
I would have recommended to you Lionheart, but it has a copper list that is not easy to follow. Probably it's better to check phx's game! |
27 August 2020, 23:22 | #27 |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 5,031
|
^"Solid Gold" is nice to play as well
(and not only read the source code) |
28 August 2020, 00:04 | #28 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Yes, the 8-way scrolling engine in Solid Gold worked fine. It can scroll a maximum of 4 px/frame and draws a new row/column in two phases. Horizontally 9+9 tiles and vertically 12+11 tiles (refer to scroll.i in the source). Two phases, because of double buffering: 16 / 2 / 2 = 4 px/frame.
The source is available on Aminet and on the NOD home page. Although, being 7 years old, it is certainly no longer state-of-the-art and has room for improvements (later I noticed that I'm blitting more rows/columns than I have to). I'm working on a new 8-way scrolling engine. |
24 September 2021, 16:54 | #29 | |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
Quote:
|
|
04 October 2021, 15:41 | #30 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
|
04 October 2021, 16:02 | #31 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
|
04 October 2021, 16:18 | #32 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
I'm happy to help you develop the routine and answer question, but please realise that if I simply give you the answer it won't probably won't help you. What is it you are stuck with atm? Graeme |
|
04 October 2021, 16:31 | #33 | ||
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
Quote:
Quote:
It may just be that the screen buffer I'm using isn't the correct width (it should be screen width + the extra width of 2 tiles)... ..the source seems confusing, because MapXYPosition and VideoXYPosition will be out of sync if the source and destination bitmaps are different widths. I'm guessing that means keeping track of when to reset the VideoXYPosition based on the MapXYPosition (in pixels). My source bitmap isn't divisible by the screen width... which complicates things. (2048 vs 320+32). I *think* what Georg is saying about mapposx / mapx relates to the source bitmap... and what he says about x/y relates to the visible screen area (or the destination bitmap + 2 tiles width). But am not sure... it takes a while to implement things and then to start up and test. I've debugged the mapx/mapy and x/y computing algorithms, and they seem to add things correctly. I'm just not sure if they're the right "things." My plan is to build Solid Gold (from phx), remove everything that isn't scrolling... and then see what's left Thanks, Graeme! |
||
04 October 2021, 18:04 | #34 | ||
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
The first is when using MonAm, have a flag at the top of your code which disables any kill system type stuff. In mine I have stuff like this: Code:
ENABLE_DEBUG: equ 0 IFEQ ENABLE_DEBUG INIT_FORBID_OS ; Forbid() SAVE_COPPER ; Load View stuff OS_WAITBLIT OWN_BLITTER ; Take Blitter WAIT_FOR_BLITTER DISABLE SAVE_SYSTEM_STATE INIT_DMA_INT lea CHIPBASE,a5 STOP_DRIVE_MOTOR jsr agdInstallAudioPlayer ; Load the copper move.l COPPTR_ORIGIN,a1 ; Get copper structure move.l (a1),d1 ; Address of copper list move.l d1,COP1LCH(a5) ; move.l d1,COP2LCH(a5) move.w #0,COPJMP1(a5) move.w #0,COPJMP2(a5) move.w #(DMAF_SETCLR!DMAF_MASTER!DMAF_BLITHOG!DMAF_RASTER!DMAF_COPPER!DMAF_BLITTER|DMAF_SPRITE),DMACON(a5) move.w #$ff00,POTGO(a5) ENDC The other thing to do is use the power of WinUAE, I encourage you to look into using uaedbg to side load you executable. It takes a little configuration but you'll get symbols included in your program with the ability to debug it with the system off. Also a top tip in WinUAE that you may not know about is watch points. Often in my code i'll write stuff like this: Code:
clr.w $100 Code:
w 0 100 2 W ALL I also have an on screen display which shows the contents of a few words and long word variables, again this is super useful and worth doing - I'm going to improve my version so I can switch it between using sprites or bitplanes (currently in only has bitplanes). (I'm happy to send you my debug OSD if you want it). Quote:
The way I did it was to get horizonal scrolling working, then vertical and then combined the two. Setup a test tilemap and and a test tile sheet (using Tiled) and make sure you can scroll it. Using large bitmaps and scrolling around them isn't going to be a good way to do an 8 way scrolling on the Amiga, unless you are confined to a very small scrolling area. Cheers, Graeme |
||
04 October 2021, 20:53 | #35 | ||||
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
Cheers! I owe you a beer! Might owe a couple before the end of your post
Quote:
Quote:
Quote:
Quote:
This is just in the interest of finishing that so I can say "I did what I set out to do." I'm sure using a giant bitmap is horribly inefficient. It's just for test at the moment. It is working a little better... however the locations of the tile blits aren't correct. Seems they blit horizontally along the top of the screen instead of in the Screen buffer (left column) vertically. Example: https://www.dropbox.com/s/6aeocyzzky...40-47.mp4?dl=0 I'll see what I can do with the UAEDbg... I've heard that WinUAE has a great debugger. It's up to about 2 beers now. |
||||
09 October 2021, 19:37 | #36 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
Well done, mcgeezer, on the "w 0 100 2 w all" option in WinUAE Debug. Found a bug where I was updating the copperlist palette while scrolling (a missing rts).
Also have X-scrolling (left/right) working. Up/down should be no problem (in comparison). Main point for me to remember is avoid pointer arithmetic. I knew this from C... should have remembered better |
09 October 2021, 23:03 | #37 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Should being the operative word here as it depends how you do it. I really should do a video on winuae debugging. |
|
09 October 2021, 23:37 | #38 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,842
|
|
14 October 2021, 19:19 | #39 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
The test scroller I've got working is nearly ready for 8-way scrolling integration.
Each of the 4 cardinal (L/R/U/D) directions are working (with minor bugs.... a small vertical split bug to squash). The way I'm thinking of addressing the original issue of THIS thread works like this: Here's an example of an entire screen buffer (352x288); 4 bitplanes; tiles 16x16; display size: 320x256px. Visible screen In terms of the responsibilities of the scroll code (up/down/left/right), each direction will fill one of the four red areas... the left and right scroll will fill the right and left columns (respectively--the right scroll blits one planeline down) and the up and down will blit to the bottom and top fill rows. The blocks are blitted in steps. For each pixel in left/right scrolling, a single tile is blitted. When scrolling right, the blocks are blitted left to right. When scrolling left, the direction is reversed. For up and down it's almost the same, except that there are more columns (20) than steps. No problem. Just blit a double-wide block 4 times. The scheme I'm currently using is blocks 0-5,7,9,11, and 13 are single blocks. The rest are double wides. (I'm actually doing 21 columns with an extra at the end). Because I decided to give the responsibilities out like that--where only vertical and horizontal blocks belong to the scroll directions that blit them--we have four blocks left out at the corners: Maybe we call these "adopted blocks," because nobody seems to own them. Maybe if we were going to only scroll 4 directions, those blocks would not come into play.. since you could always scroll once to the left and then once down, for instance, to get the column and row belonging to that block blitted. Because we have to blit more blocks in the ROWS, my thought is to first try to have the horizontal scroll directions take care of the corner blocks. If scrolling left--for instance... blit B and D. If scrolling right, blit A and C. If the scroll direction doesn't include a left/right component... and it is pure up or down, then it should be downward scroll blitting A and B and upward scroll blitting C and D. I haven't implemented this (yet) but this is how I'm thinking. How does this align with what actually works? Maybe mcgeezer's previous bug (in this thread) dealt with blitting A/B/C/D more than once during the scroll? That's just a guess. Anyway... this is just some thinking. It may not actually work--it's not tested |
14 October 2021, 19:53 | #40 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,213
|
Perhaps create a new thread for your development (rather than post in 2 seperate existing threads ?)
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
doom multi ? | turrican3 | support.Games | 2 | 16 August 2019 08:22 |
OCS/ECS Playfields - blitting objects using colours 16-31? | Marle | Coders. Blitz Basic | 6 | 03 October 2018 19:19 |
Multi-quoting | Graham Humphrey | project.EAB | 38 | 21 August 2010 22:19 |
Multi Zocker | mai | HOL data problems | 0 | 04 December 2009 11:08 |
Multi-Assign | Shoonay | support.Apps | 17 | 12 April 2005 15:16 |
|
|