multi-directional playfields

[mcgeezer]

Originally Posted by ross

Hi Graeme, what kind of complications?
You can simply DIWSTOP 16 line before. Maybe I miss something obvious here.

Originally Posted by hooverphonique

To "hide" the top 16 bitmap lines, just set your bitplane pointers 16 lines into the bitmap (as you said).


If you want the screen to end 16 lines early, set DIWSTOP to $2c-16=$1c (vertical).

Indeed and this is what I'm doing, I'm just getting complications when trying to manipulate the copper.

It's basically just a bug I need to squash.

[mcgeezer]

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.

[mcgeezer]

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

[phx]

Originally Posted by mcgeezer

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?

Depends on the scroll speed, the tile size and the size of the visible scrolling area, if I understand you correctly. With 1 pixel/frame it should be possible when blitting 2 tiles at once, but with just 1 tile you have to shrink your display window.

Has anyone achieved this or was I striving for the impossible?

I was blitting 3 tiles every frame for my last horizonal-only scrolling games, allowing a scroll-speed of up to 2 pixels/frame.

[mcgeezer]

Originally Posted by phx

Depends on the scroll speed, the tile size and the size of the visible scrolling area, if I understand you correctly. With 1 pixel/frame it should be possible when blitting 2 tiles at once, but with just 1 tile you have to shrink your display window.

I was blitting 3 tiles every frame for my last horizonal-only scrolling games, allowing a scroll-speed of up to 2 pixels/frame.

This is exactly what I mean PHX. Consider the limitation of 1px per frame movement in any direction. Did you achieve it? I was getting all kinds of issues with misplaced tiles when doing diagonal movement.

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.

[ross]

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!

[malko]

^"Solid Gold" is nice to play as well
(and not only read the source code)

[phx]

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.

[chadderack]

Originally Posted by mcgeezer

This is exactly what I mean PHX. Consider the limitation of 1px per frame movement in any direction. Did you achieve it? I was getting all kinds of issues with misplaced tiles when doing diagonal movement.

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.

I'd like to have a muck around with this. Would you mind uploading the src to the zone? Cheers one way or the other.

[mcgeezer]

Originally Posted by chadderack

I'd like to have a muck around with this. Would you mind uploading the src to the zone? Cheers one way or the other.

Sorry - is this to PHX or is this to me?

[chadderack]

Originally Posted by mcgeezer

Sorry - is this to PHX or is this to me?

Sorry... to you, actually. I'm kind of stuck in scrolling hell meself .
Thanks

[mcgeezer]

Originally Posted by chadderack

Sorry... to you, actually. I'm kind of stuck in scrolling hell meself .
Thanks

I can send you my source code for doing it, but if I am honest and given your task at hand it will be much better for you in the long run if you try and figure out the scrolling technique yourself as it is core to pretty much every thing you will plot on the screen.

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

[chadderack]

Originally Posted by mcgeezer

I can send you my source code for doing it, but if I am honest and given your task at hand it will be much better for you in the long run if you try and figure out the scrolling technique yourself as it is core to pretty much every thing you will plot on the screen.

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.

Yeah I figured that these are the times that build those Amiga muscles.

What is it you are stuck with atm?

Graeme

Well aside from not having real-time debugging with MonAm (because my code turns off the OS) it's about implementing Georg's algorithm with tile blits.

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!

[mcgeezer]

Originally Posted by chadderack

Well aside from not having real-time debugging with MonAm (because my code turns off the OS) it's about implementing Georg's algorithm with tile blits.

So a couple of tips here I can give.

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:

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

If I want to debug in MonAm I simply set ENABLE_DEBUG to 1.

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:

clr.w $100

Then in WinUAE I'll enter:

w 0 100 2 W ALL

This causes WinUAE to break into the debugger when your clr.w $100 hits... very very useful. Also, learn and make sure you use the Action Replay 3 cart - in particular learn the P command and how to visually inspect memory.

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).

Originally Posted by chadderack

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!

I would really try to build it yourself... that's the best way to do it.

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

[chadderack]

Originally Posted by mcgeezer

So a couple of tips here I can give.

Cheers! I owe you a beer! Might owe a couple before the end of your post

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:

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

If I want to debug in MonAm I simply set ENABLE_DEBUG to 1.

Guess I'll have to find those macro definitions. I'll check through your sources from your YouTube series on www.amigagamedev.com.

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:

clr.w $100

Then in WinUAE I'll enter:

w 0 100 2 W ALL

This causes WinUAE to break into the debugger when your clr.w $100 hits... very very useful.

That would be very useful... especially to inspect the state of the scroll after one frame.

Also, learn and make sure you use the Action Replay 3 cart - in particular learn the P command and how to visually inspect memory.

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).

Was kind of thinking along those lines... get some debug strings drawn to the lower left/right of the screen. I was just about to look through the forums for something like that.

I would really try to build it yourself... that's the best way to do it.

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

The concept I was trying to implement was just a long horizontal scroll through the top 1/4 of the map for Level 1; once it reached the end in the right direction, reverse and go back left.

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.

[chadderack]

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

[mcgeezer]

Originally Posted by chadderack

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

Should being the operative word here as it depends how you do it.

I really should do a video on winuae debugging.

[kamelito]

Originally Posted by chadderack

Well aside from not having real-time debugging with MonAm (because my code turns off the OS) it's about implementing Georg's algorithm with tile blits.

You may wanna try Adebug which is a low level Monam equivalent.

[chadderack]

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

[DanScott]

Perhaps create a new thread for your development (rather than post in 2 seperate existing threads ?)