| |
Compyx
Registered: Jan 2005
Posts: 631 |
Release id #150179 : Differential Scrolling
Guess I'll start the discussion then,
I don't see any advantage of using this technique over traditional ways of scrolling, and I'll leave VSP out of the equation for now.
Seems to me that when using actual 'level' data using a tile based approach would be faster and a lot less memory hungry. Not to mention it would allow scrolling backwards, something this differential scrolling would have a hard time to do.
Also I don't get the 'full screen' update when scrolling left-to-right at one pixel at a time, seems incredibly wasteful.
Well, I said my piece, now for the actual coders ;) |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
i can see the idea, but i cant see a useful application :) |
| |
Fungus
Registered: Sep 2002
Posts: 691 |
Seems like a c64 implementation of the PC idea used for Commander Keen by John Carmack. I can see the use of it there, but not on C64 where it had hardware scroll capabilities and tiles.
None the less, interesting. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I once tried an RLE approach to bitmap scrolling, compressing all bitmap data with RLE and decompressing a column during scrolling. Sucked. Just encoding all bitmaps into a 'charset' with 16-bit indici/pointers was much faster, and simpler. |
| |
CRT
Registered: Oct 2012
Posts: 87 |
I don't think it's something new. Delta-compression, delta-updates is something I like to use often when it fits my needs. Still a really nice example.
Edit: The most obvious day to day example that comes to mind is mpeg based video in one form or another.
This works nicely on C64 for small differences. But it's good to have an escape backup routine to replace the entire screen if need be. |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
If I understand the concept correctly, this only really works when you have large areas of a single character, which isn't going to be applied to very good looking scenes.
However, I found it worked well for scrolling colorram in Hawkeye 2. There, you're going to be much more likely to have large swaths of the same byte, and only updating the edges between colors can save a lot of time chasing the raster. Plus, depending on how you implement it, it can scroll bidirectionally. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Yes nothing new here. I also used the same technique for color ram scrolling in Canabalt. For actual background graphics with lots of details this does not provide a benefit, except if you have large areas of sky which is all the same character. |
| |
Carrion
Registered: Feb 2009
Posts: 317 |
Quote: i can see the idea, but i cant see a useful application :)
And it was my question too...
How can we exploit that? What gfx modes (hires? multi?) can a graphician use and how big it can be?
This looks tempting especially because of the parallax effect :) |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
The parallax doesn't have anything to do with the char scrolling routine, though. |
| |
Sokrates
Registered: Jun 2014
Posts: 7 |
I just had this idea and found no information that this was done on the c64 before, so I wrote this little demo.
Now I see that this idea was implemented before, at least for color ram scrolling.
But beside the technique is not completely new, I think this demo is still useful to share this knowledge with a broader audience than before.
So maybe we'll see more fancy use cases in the future :-) |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Oh, I just remembered another time I used this technique: BASIC animations! :-D Move the cursor, PRINT the animation item which also prints enough spaces beside it to erase the prior frame (or leave smears to animatedly draw a border or smoke trails or whatever). It makes fluid-enough large PETSCII animations quite feasible when you're an 8 year old who doesn't know asm yet. :-) |
... 19 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
