English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 15 December 2019, 00:26   #1
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,633
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 ---

[ Show youtube player ]

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
mcgeezer is offline  
Old 15 December 2019, 00:32   #2
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,336
Send a message via Yahoo to Samurai_Crow
It is difficult because the copper splits need sorting by vertical screen position. Are you doing this in C?
Samurai_Crow is offline  
Old 15 December 2019, 00:37   #3
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,633
Quote:
Originally Posted by Samurai_Crow View Post
It is difficult because the copper splits need sorting by vertical screen position. Are you doing this in C?
Doing it in assembler.
mcgeezer is offline  
Old 15 December 2019, 06:50   #4
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,336
Send a message via Yahoo to Samurai_Crow
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.
Samurai_Crow is offline  
Old 15 December 2019, 12:43   #5
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,596
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.
roondar is offline  
Old 17 December 2019, 09:29   #6
aros-sg
Registered User

 
Join Date: Nov 2015
Location: Italy
Posts: 40
Quote:
Originally Posted by mcgeezer View Post
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.
aros-sg is offline  
Old 22 December 2019, 01:46   #7
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,633
Looks like I'm getting there ... gradually but still some off by one errors.

[ Show youtube player ]

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

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
mcgeezer is offline  
Old 22 December 2019, 12:30   #8
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,596
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.
roondar is offline  
Old 22 December 2019, 16:44   #9
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 3,527
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.
jotd is offline  
Old 22 December 2019, 18:20   #10
aros-sg
Registered User

 
Join Date: Nov 2015
Location: Italy
Posts: 40
Quote:
Originally Posted by jotd View Post
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 is offline  
Old 22 December 2019, 18:31   #11
aros-sg
Registered User

 
Join Date: Nov 2015
Location: Italy
Posts: 40
Quote:
Originally Posted by aros-sg View Post
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.
aros-sg is offline  
Old 22 December 2019, 21:22   #12
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,633
I think barring Alien Breed, Team 17 games were all very over rated.

Superfrog is being the worst of them.
mcgeezer is offline  
Old 22 December 2019, 22:24   #13
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,566
Quote:
Originally Posted by jotd View Post
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.
phx is offline  
Old 22 December 2019, 23:49   #14
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,633
Quote:
Originally Posted by phx View Post
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.
mcgeezer is offline  
Old 23 December 2019, 20:16   #15
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,566
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 is offline  
Old 23 December 2019, 21:00   #16
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,519
@phx I thought your games used large screens to scroll?
Retro1234 is offline  
Old 23 December 2019, 21:29   #17
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 3,527
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...
jotd is offline  
 


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 09:22
OCS/ECS Playfields - blitting objects using colours 16-31? Marle Coders. Blitz Basic 6 03 October 2018 20:19
Multi-quoting Graham Humphrey project.EAB 38 21 August 2010 23:19
Multi Zocker mai HOL data problems 0 04 December 2009 12:08
Multi-Assign Shoonay support.Apps 17 12 April 2005 16:16

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 04:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.08767 seconds with 15 queries