06 December 2016, 02:44 | #1 |
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
Infinite vertical scrolling
I'm new to Amiga programming and I'm trying to figure out how to write a simple vertical scrolling engine. I have 4 bitplanes tall enough to contain 2 screens worth of 16x16 tiles.
Every frame I move the bitplane pointers in my copperlist up by 1 scanline. When the window reaches the end of the tilemap I move it back down so the bottom half of the tilemap is visible. But I need to do it in a way that it's invisible to the user. I think what I need to do is blit the next row of tiles both off the top and the bottom of the visible area so that when I reset the bitplane pointers the screen is still showing the same data, right? But when I did that, I couldn't blit the two rows of tiles before running out of time during the frame. Is there some example code floating around I can look at? |
06 December 2016, 09:17 | #2 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 936
|
http://aminet.net/package/dev/src/ScrollingTrick
Check this out. Explains most of the commonly used scrolling techniques. |
06 December 2016, 10:28 | #3 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
The scrolling trick package on Aminet is great stuff.
Do note that vertical scrolling using the copper-split version of his trick will make getting bobs drawn correctly on the screen harder (and use more CPU time). |
06 December 2016, 10:42 | #4 | |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,219
|
Quote:
|
|
06 December 2016, 10:47 | #5 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
At any rate, I'd suggest to the OP that blitting 2 rows of tiles is the best way to start out. Time enough for trying out more complicated routines after that works. |
|
06 December 2016, 11:17 | #6 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,345
|
For proxima 3 I'm using 3 screen for it, and I switch pointer when needed.
|
06 December 2016, 12:42 | #7 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,377
|
Make your bitmap two screens high. That way you can always blit outside of the visible area, as long as you blit two rows per update with a certain offset.
|
06 December 2016, 14:08 | #8 |
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
|
06 December 2016, 14:20 | #9 | |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,219
|
Quote:
Are you coding in 68k asm? |
|
06 December 2016, 14:31 | #10 |
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
I'm doing it in C but I'm going to rewrite my blit functions in ASM. I'm new to Amiga but not 68k.
Last edited by LuigiThirty; 06 December 2016 at 15:08. |
07 December 2016, 04:56 | #11 |
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
I optimized the hell out of my C tile blitting routine before rewriting it in ASM and now I seem to be able to draw them no problem! That and looking at the scrolling trick for reference got me going and now I have a happily wrapping vertical scrolling playfield at 60fps
I think the next step is to, uh, change this to PAL so I can do 320x256@50Hz instead of 320x200@60Hz. |
07 December 2016, 10:36 | #12 | |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,219
|
Quote:
|
|
07 December 2016, 21:14 | #13 |
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
By the way, I'm compiling my program with VBCC, which can output debug info compatible with SAS/C. I tried setting up remote debugging using a serial cable between my PC running WinUAE and my A2000. I can load the program onto the target machine with cprx but when my program writes a new Copperlist, I just get a scrambled picture from a Copper run amok. If I copy the program onto a floppy and run it on the A2000, it's fine. Huh?
|
09 December 2016, 17:04 | #14 |
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
Turns out I was wrong
I think the problem may lie in my frame loop, not my blitter code. I disabled all my bobs and am just rendering tiles now. It shouldn't be stuttering just drawing 20 16x16 tiles! Hmmmmmm. I'm not sure how readable the code is but if you've got any ideas please don't hesitate to share. I'll keep plugging away at it. |
10 December 2016, 13:01 | #15 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
I only had a quick look over the source, so just a few notes:
|
10 December 2016, 13:13 | #16 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
With that said, here are my tips: Your code spends a lot of time blitting tiles when you reach the 16th frame. I did some cycle counting and your blitter routine is close to 650 cycles per call (assuming you are using a 68000 and that I didn't screw up). Now, you have chosen to not use an interleaved screen mode so each tile is 4 blits. And you're blitting 20 tiles in total when you reach the 16th frame. In total you are doing 80 blits. This is the equivalent of spending ~52.000 CPU cycles in such a frame, just to do tile blitting. There are ~141.000 of them in a PAL frame, so you are spending over a third of a frame just setting up blits. There are two ways to improve this:
These two can be combined as well. Other than that you could also try to use 'blitter nasty' mode for blitting tiles, but it really should not be needed in this case as the blits are tiny. Now, the rest of your code looks simple enough and should really run fairly fast. However, since we don't know which part is running slow, I'd suggest using colour 0 as a 'debug mechanism': set it to a different colour for every part of the loop and reset after you're finished in the loop. This way, you can see which part of the code takes which amount of raster time and focus there. If I had to guesstimate, I'm thinking it may be overhead around calling your blit or a frame wait routine that somehow doesn't do what you want (although it looks almost exactly like the one I use and that one works). All things combined - this is a bit of a mystery as I don't see anything that should be running so slow as to make your code drop frames. |
|
10 December 2016, 18:07 | #17 | ||
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
Thanks for the analysis! I haven't cycle counted per scanline since I did Atari 2600 programming. It's easier on a 6502 than a 68000!
My A2000 has a 68030 so that's what I have WinUAE set to. Quote:
Quote:
Last edited by LuigiThirty; 10 December 2016 at 18:38. |
||
10 December 2016, 21:37 | #18 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
Because it is only showing on the emulator you may actually be seeing the result of a difference in frame rate between what the emulator wants to show and what your display is doing. This shows as the odd hickup every now and then as the emulator doubles a frame every now and then to convert between 50 and 60Hz. Quote:
Quote:
Last edited by roondar; 10 December 2016 at 21:39. Reason: spelling |
|||
10 December 2016, 23:43 | #19 | |
Registered User
Join Date: Dec 2016
Location: USA
Posts: 101
|
Quote:
|
|
11 December 2016, 02:44 | #20 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
I think I understand the problem now. The issue is that your frame loop only updates the copper list after blitting the tiles.
In short: the WFRAME code waits until rasterline 244 (out of 262 for NTSC). The copper list sets the bitplane pointers at rasterline 0 (there is no wait in the copper list prior to the setting of the pointers). This means the code has only a few rasterlines worth of time to set the pointers before the copper will write them. During frames which blit the tiles, the code probably ends up taking more than the available time between line 244 and line 0, so when it does write the pointers into the copper list, the copper list execution is already past setting them into the display registers. This will result in a stutter. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Smooth vertical scrolling in AMOS | idrougge | Coders. AMOS | 43 | 21 February 2021 12:58 |
Horizontal vs vertical scrolling | Amiga1992 | Coders. General | 20 | 26 October 2015 11:15 |
infinite money in ishar 2 | Jacobson | support.Games | 7 | 19 April 2012 12:42 |
[Found: Insanity Fight] Vertical Scrolling Shootemup | capehorn | Looking for a game name ? | 5 | 13 March 2009 08:18 |
Vertical scrolling motorcycle game.. Anyone? | Thrash75 | Looking for a game name ? | 11 | 18 May 2005 19:44 |
|
|