multi-directional playfields
 

Damn these things are hard to get right.

Very frustrated, you think you have it then you don't. I've been on with this for a couple of weeks now and it's proving a challenge... this is despite reading the scrolling tricks docs.

If I can do it then I can unlock some better platformer games. (Rolling Thunder, Shinobi and that sort).

The odd dirty tiles I can live with as I know how to sort them... the problem is the map stitching when I move lower into the map and along the x-axis goes tits up.

Very frustrating...

--- sorry...this is just a rant ---

https://youtu.be/dx0vPCHrixA

Did other coders find this hard to do, or am I just being simple? The tile map is arbitrary so I've set it to 80x80 tiles. It's using copper video splitting as well.

Geezer

It is difficult because the copper splits need sorting by vertical screen position. Are you doing this in C?

Doing it in assembler.

That's going to make the explanations harder but maybe I can manage.

The gist of a copper block sorter is that you have to have your copper list buffered in chunks in fast RAM so you can determine what order the operations need to be in before copying the partial lists into chip RAM.

Each block consists of a header containing a single CWait followed by a payload of CMoves. You sort the blocks using the position passed to the CWait then copy the ordered copper list into chip RAM. If I were doing this I'd make each block a node in a linked list and use an iterative natural merge sort to do the sorting.

It is kind of what MrgCop is supposed to be but isn't.

I'd say the Copper list splits all depend on what else you're doing with the Copper. Many games that use a Copper split for vertical scrolling limit (or even abstain from) other Copper trickery, which makes it a lot easier to work out how the Copper list ought to work. My suggestion would be to start from a position of not doing any Copper tricks until the system works.

Generally, I find it much easier to do stuff like this by splitting it into it's separate components. Horizontal and vertical scrolling can be seen as two different problems to solve. Similarly, getting the correct tiles on the screen for horizontal and vertical scrolling are also separate components. To me thinking and implementing each of these four elements individually makes everything much easier to follow than trying to write it all at the same time.

I'd start with just working out the vertical Copper split scroll as that is the most complicated part of this type of scrolling. Then, after that works, I'd add in the vertical part of the tilemap. Then horizontal scrolling/tilemap.

Run the examples (all, not just the one whose techinque you want to use) in the archive with HOW param to see what happens during scrolls to the fillup columns/rows. Add option to your code for similar feature (always display same address on screen -> ignore scroll position). Compare.

Horizontal scrolls affect vertical fillup row when X pos goes over 16 pixel boundary.
Vertical scrolls affect horizontal fillup columnn Y pos goes over 16 pixel boundary.
(Assuming tilesize 16x16)

In video it looks like horizontal fillupow column is built in the reverse direction (when scroling right it builds up from bottom to top, instead of top to bottom).

For testing it may help to have a simple tilemap where you have one screen full of red tiles, to the right one screen full of green tiles, to the bottom one screen full of blue tiles. Something like that.

If there are bugs they should likely be visible soon even when scrolling only small parts of the tilemap. Scroll a bit to the right. Then keep scrolling to the bottom for a bit
longer. Then some more to the right. And to the left again. And then to top.

Looks like I'm getting there ... gradually but still some off by one errors.

https://youtu.be/JRUF24tDCAc

The playfield is currently 288x256, i'll need to hide 16 lines at both the top and bottom of the video to give a playfield size of 288x224.....(ohhh my, I wonder why I chose that playfield size > https://en.wikipedia.org/wiki/Rollin...r_(video_game) :D )

The reason this is so complicated is for performance. The playfield is 21 words wide so on 7 of the 8 available even frames I have to make 3 blits, for the odd frames I'll probably copy the blits to the other buffered screens.

Hopefully, I'll get good performance.

Geezer

Performance should be very good if you can manage to split the required blits over the available frames. Even if a game scrolls reasonably fast, you should still be able to get away with blitting only a fraction of the columns required for the new scrolled in stuff per frame.

Then again, even if you had to blit all of the new columns every frame, it should still not be that much overhead. Copy blits are very quick, you can do quite a few in a frame.

somehow shows how talented the Team17 guys were when they wrote Assassin, Superfrog... 25 years after it's still super hard to do 50Hz scroll.

(and it's ridiculously easy with SDL and a modern PC damn ...)

Keep up the good work. Seeing the result now, it's clear that you're going to make it.

No, many of their games only did the scrolling (hw) at 50 Hz. But gfx update itself (bobs) ran at 25 Hz. For this you don't need fast/clever scrolling routine, Even just repainting everything (25 Hz) everytime works == no real scroll routine at all.

And this can look pretty ugly in some cases.

For example imagine player sprite chasing enemy sprite. Both run to the right at 50 pixels per second.

On a real 50 Hz game the player sprite and the enemy sprite stay fixed in place on the same spot on the monitor.

On a 50/25 Hz game the player sprite likely stays fixed (if it is a hw sprite), but the enemy sprite which is likely a bob will jitter between position X and position X-1 at 50 Hz.

I think barring Alien Breed, Team 17 games were all very over rated.

Superfrog is being the worst of them.

It isn't.

50Hz scrolling, also 8-way scrolling, is negligible and needs only a few raster lines per frame when using the right technique. In the worst case you will copy-blit a few tiles in the border. Usually there are many more tiles to blit just for tile-animations on the screen. The biggest impact have numerous big BOBs in the scene, which have to be blitted masked with all four channels and an extra-word for shifting.

But not so much fun. :p

To do it right is not easy, at least I'm not finding it easy anyway....in fact easy is the wrong word... tricky is more appropriate.

True. I remember it took a few weeks before everything worked perfectly, when I wrote Solid Gold. I was especially looking for one bug which trashed a bitplane pointer and another one which made tiles disappear, when scrolling diagonally.

I would point you to scroll.asm of Solid Gold, but it is probably hard to read, because the scrolling routine also includes the movement of the coloured background raster-bars.

@phx I thought your games used large screens to scroll?

I prefer Bitmap Brothers games by a mile (even if they were sometimes using 17fps/16 colors direct ST port...), but Team 17 games were technically impressive. Unfortunately, the gameplay wasn't the best. I enjoyed superfrog because of the huge levels & varied gfx, but gameplay was bland, I agree.

The hardest to do is to reuse some asm routine for another game. To gain speed, one can be tempted to hack stuff / tailor for the game you're creating, and it's difficult to create a "generic" set of routines (specially in asm) that you can reuse.

mcgeezer I wish you a lot of luck for your project. you're a realistic guy who knows what he's doing and ends what he starts. I know we're cursing asm, but c/c++ adds a lot more overhead if you don't use the proper options. For instance my bagman executable is 1MB once stripped...

I'm trying to get my 8 way scrolling engine working again as I got quite frustrated with it last time I tried it.

I'm almost there, however I can't seem to figure out what is probably a simple problem to solve which is clipping the upper part of the screen where new tiles are drawn.

Here's a video:

https://youtu.be/oIAqKx_6BGg

I've also put an ADF in the zone (probably need an A1200 config).

I can't seem to get the top border clipped, initially I though I could have just indexed 16 scan lines into the bitmap but that adds complications toward the bottom. The size of the screen is 256 pixels so I'm trying to get an actual screen size of 240 (15 tiles depth) showing from VPOS $2c.

Is there an easy way to hide the upper 16 scan lines without having to use a WAIT copper instruction? (like a DIWSTRT trick) I could use some sprites to cover it which would be handy for a score panel anyway but just want to make sure I'm not missing something easy before I do.

My mind is probably fried with this so I'm not making much sense.

Geezer

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

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