| |
mankeli
Registered: Oct 2010
Posts: 129 |
VSP/linecrunch scrolling with sprites
Hi. I wonder how Mayhem in Monsterland and other games utilizing techniques mentioned in the topic, can still show sprites? The sprite pointers should be visible in background.
In Skybox, I was able to have the sprite pointers just visible there since everything was pretty glitchy anyway and they still had the correct D800 colors. The Performers' demo that had almost similar greetspart probably hid them in the black areas. (I didn't look though)
But I cannot comprehend how it's possible otherwise. Does MIM use different kind of VSP scrolling? |
|
| |
Burglar
Registered: Dec 2004
Posts: 1077 |
Mayhem just uses VSP, no linecrunching, and since vsp only requires a stable raster and 2 rasterlines to do, there are no other timing requirements, so sprites work fine, below the critical ~2 rasterlines.
edit: Performers don't use VSP |
| |
Oswald
Registered: Apr 2002
Posts: 5082 |
In the case of Mayhem, there's plenty of ways of hiding it, using illegal mode for example, or making the chars hires and same color as background with $d800, or 24 row mode.
Fred's back is in bitmap mode and levels are drawn so that no screen colors are used in those parts. (atleast I think so, never checked, but no other way)
edit: I have a vague memory of seeing Fred's back editor and it flashed the sprite pointers on the screen for avoidance. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Not used by the games in question, but if you were to use charmode VSP+linecrunch and already had a sprite streaming/depacking system in place, meaning sprite pointers are always the same, you could also copy the proper char data (needed by your screen / tilemap) into the chars pointed to by the sprite pointer values. |
| |
Krill
Registered: Apr 2002
Posts: 2952 |
Maybe you could also switch screens going into and out of the sideborder. Sprite pointers are read in the border, char/bitmap data in the display window.
Of course, badlines are going to be a problem... =) |
| |
Martin Piper
Registered: Nov 2007
Posts: 703 |
When I made the self playing demo of "Born in Space" playable, and added a lives hack, I noticed that when it AGSP scrolled far enough then it would show the sprite pointers in its multicolour bitmap. It only has one bitmap, not double buffered.
At 38:35 https://youtu.be/R1rOAwTY90E?t=2314 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1407 |
I like Cadaver's solution. You could even reserve (eg) the last eight characters of your charset for the pointer area and copy appropriate defs into the charset, and also a few lines of pixels from the sprite definitions for {the actors that that cross the first raster of that row} into sprite defs f8-ff, and temporarily switch the sprite pointers to $f8..$ff just for a raster or two either side of the problematic badline.
Back when I was working on a shooter with an AGSP bitmap scroller my plan was to just ensure the sprite pointers landed on areas that only used background and d800 colours, so it didn't matter if the screen memory values were vandalised by the sprite multiplexer (or alternately I was just going to remap those pixels and live with the slight corruption) |
| |
mankeli
Registered: Oct 2010
Posts: 129 |
Thanks! Very good info. Didn't realize that Mayhem would work with VSP only. I guess you could use multiple screens with 1 character Y offsets to make the scroll update "constant-time", but how is the D800 handled? (Or is it in bitmap mode?)
And funny/cool idea that a game editor would actually show the invalid areas. (Atleast from coder viewpoint :D) And Cadaver's idea for mitigating this is pretty good as well. |
| |
Burglar
Registered: Dec 2004
Posts: 1077 |
Quoting mankeliThanks! Very good info. Didn't realize that Mayhem would work with VSP only. I guess you could use multiple screens with 1 character Y offsets to make the scroll update "constant-time", but how is the D800 handled? (Or is it in bitmap mode?)
it's charmode, it does both screen and colram. since VSP can scroll in very little rastertime, there's plenty time to draw the left and right edges.
and it does 24 rows, so no issues with sprite pointers |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1407 |
mankeli: most frames Mayhem just updates a single column of colour ram, but every time it hits 40 columns of scroll it needs to snap back and copy all of colour RAM up one character. There are some slightly unrolled loops at $2480 that do this four rows at a time, probably chasing the beam to some extent, because it's going to take over 9000 cycles to do that. |
| |
Oswald
Registered: Apr 2002
Posts: 5082 |
Quote: Maybe you could also switch screens going into and out of the sideborder. Sprite pointers are read in the border, char/bitmap data in the display window.
Of course, badlines are going to be a problem... =)
I've been asking around in another topic about this some 10 15 years ago |
| |
Oswald
Registered: Apr 2002
Posts: 5082 |
Quote: mankeli: most frames Mayhem just updates a single column of colour ram, but every time it hits 40 columns of scroll it needs to snap back and copy all of colour RAM up one character. There are some slightly unrolled loops at $2480 that do this four rows at a time, probably chasing the beam to some extent, because it's going to take over 9000 cycles to do that.
VSP in mayhem kinda pointless it doesnt do anything that needs more time than copying the whole screen by hand. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1407 |
Yeah I'm a bit surprised the colour ram update is that slow TBH - it means they need to be able to cope with losing half their cycles to screen update on the occasional frame without glitching. Maybe they had plans for something faster, but ran out of code space for it?
(VSP still saves them a fuckton of cycles on average, and maybe they just don't sort the sprites or something on snapback frames, but still, Oswald's point stands) |
| |
Fungus
Registered: Sep 2002
Posts: 679 |
Phobia uses VSP as well, and I don't recall it having to do the snap back thing, but then again it's been ages since we did that so I don't remember the details.
I'm not aware of any game using AGSP. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
the sprites are above the bottom row as the bottom row moves up and down the actual last row is not part of the "level" and hence by the time you get to said row there are not any sprites to show. So you just set the Sprite pointers to what you need them to be, and then set them back after.
But in the Mayhem in Monsterland case, they open the borders and put the HUD sprites in to it, which have specific known values. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1407 |
Anything that scrolls horizontally continuously over multiples screens using VSP but not linecrunch has to do the snapback - by the time you've scrolled 39 characters to the left the top row of your screen contains characters 39-78 inclusive, and scrolling one more character means you're going to be displaying 0..39 again - so you need to shift the whole screen up a row. |
| |
Jetboy
Registered: Jul 2006
Posts: 274 |
Quote: Anything that scrolls horizontally continuously over multiples screens using VSP but not linecrunch has to do the snapback - by the time you've scrolled 39 characters to the left the top row of your screen contains characters 39-78 inclusive, and scrolling one more character means you're going to be displaying 0..39 again - so you need to shift the whole screen up a row.
youu cannot scroll to the left with VSP. Just to the right.It is done by delaying vic yo fetch data. You cannot scroll more than 39 characters with pure vsp.
scrolling to the left is achieved by starting with screen already scrolled to the right, then decreasing scroll.
That means there is no situation evwr when there are
characters 40+ in the first line with pure vsp, To achieve that you need to use linecrunching. |
| |
Martin Piper
Registered: Nov 2007
Posts: 703 |
It's actually more like triggering the (partial) bad line early to fetch more characters, not delaying to fetch less. ("by delaying vic yo fetch data")
This means that it's entirely possible to have characters 40+ in a screen appear on the first visible line, without line crunch. |
| |
Jetboy
Registered: Jul 2006
Posts: 274 |
Only because previous line was linecrunched :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 703 |
Quote: Only because previous line was linecrunched :)
No it's not a full line. So it isn't a line crunch.
For example, this image: https://ibb.co/P1PPjwV
The border colour update indicates the time just before DMA delay trigger point. It's in the last 4 cycles of the trigger window.
In the ICU64 debug view you can see screen $400 contains 40 '0' characters, then 40 '1' characters, and so on.
The first visible line on the C64 contains 36 '0' characters, followed by 4 '1' characters. The '1' characters are characters 40+, i.e. characters 40-43.
Obviously there is no line crunch, since the first line shows '0' characters first. There are 25 rows visible, chars 0-9, then 0-9 again, then chars 0-4, for 25 rows in total.
The bottom right white reversed '@' characters come from the colours in the last part of the colour RAM, obviously, and the 7e8-7ff range, not visible ion the ICU64 debug view.
This rather simply shows that it is possible to show characters 40+ (the four '1' characters in this case) on the first line without a line crunch. |
| |
Brush
Registered: Apr 2002
Posts: 22 |
Quote: Phobia uses VSP as well, and I don't recall it having to do the snap back thing, but then again it's been ages since we did that so I don't remember the details.
I'm not aware of any game using AGSP.
Fred's Back does.
Fred's Back |
