English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. General (http://eab.abime.net/forumdisplay.php?f=37)
-   -   multi-directional playfields (http://eab.abime.net/showthread.php?t=100015)

mcgeezer 14 December 2019 23:26

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

Samurai_Crow 14 December 2019 23:32

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

mcgeezer 14 December 2019 23:37

Quote:

Originally Posted by Samurai_Crow (Post 1365145)
It is difficult because the copper splits need sorting by vertical screen position. Are you doing this in C?

Doing it in assembler.

Samurai_Crow 15 December 2019 05:50

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.

roondar 15 December 2019 11:43

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.

aros-sg 17 December 2019 08:29

Quote:

Originally Posted by mcgeezer (Post 1365144)
this is despite reading the scrolling tricks docs.


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.

mcgeezer 22 December 2019 00:46

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

roondar 22 December 2019 11:30

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.

jotd 22 December 2019 15:44

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.

aros-sg 22 December 2019 17:20

Quote:

Originally Posted by jotd (Post 1366833)
somehow shows how talented the Team17 guys were when they wrote Assassin, Superfrog...


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.

aros-sg 22 December 2019 17:31

Quote:

Originally Posted by aros-sg (Post 1366843)
But gfx update itself (bobs) ran at 25 Hz..


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.

mcgeezer 22 December 2019 20:22

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

Superfrog is being the worst of them.

phx 22 December 2019 21:24

Quote:

Originally Posted by jotd (Post 1366833)
25 years after it's still super hard to do 50Hz scroll.

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.

Quote:

(and it's ridiculously easy with SDL and a modern PC damn ...)
But not so much fun. :p

mcgeezer 22 December 2019 22:49

Quote:

Originally Posted by phx (Post 1366891)
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.

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.

phx 23 December 2019 19:16

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.

Retro1234 23 December 2019 20:00

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

jotd 23 December 2019 20:29

Quote:

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

Superfrog is being the worst of them.
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...


All times are GMT +2. The time now is 14:31.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.04623 seconds with 11 queries