I'm currently using the delta-update (only printing the changes) in XOR
to get 192*192 pixel scrolling. It doesn't go at 50 frames per second,
but looking at the C64 version of Sanxion, that's obviously not running
at 50fps either:
http://www.youtube.com/watch?v=WDg1GX37bkU&feature=related
For example, at about 1m35 the bonus level bullets are obviously
skipping out lots of frames to get a good speed. The mountain level
before that, looks like the scrolls are going 16 pixels per update,
which looks like 25fps at most.
But I think most people forget that full screen scrolling *never* went
at 50fps on 8 bit machines. Even the ST struggled, and the Amiga only
managed it because it had the blitter. If you want to convert it, just
go with whatever you can get away with!
Howard
On 21/04/2012 18:59, Adrian Brown wrote:
Yer, with limited tiles its not soo bad. The current thing im working
on uses a change check for updates but that's not for scrolling. Im
just not sure any method would work for a mode 4 screen, its just too
much data.
Adrian
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Thomas Harte
*Sent:* 21 April 2012 18:31
*To:* [email protected]
*Subject:* Re: Musics
The best idea I've come up with is to use a very limited number of
tiles and scroll like one of those infinite ball demos.
So, you have 8x8 tiles and 8 screen buffers. You scroll only either 1
or zero pixels at a time, only ever in one direction. Assuming it's a
right to left scroll, for each movement you switch from one buffer to
the next. Then run through each on-screen tile and paint only if that
tile is not the same as the tile one position to its left.
With a small number of possible tiles and a normal sort of platform
game layout (ie, lots of horizontal platforms) you shouldn't have to
draw all that much. Level two of Super Mario Brothers would probably
be an ideal usage case.
I guess that the next thing would be to store your tile map as the
computed list of tile changes to draw per tile column, and to consider
whether compiling your tiles so that you map from the combination of
old tile and new to the code and draw only the changes gives a
meaningful boost for the memory cost.
I'm not sure whether anybody else has done this sort of thing, but I
really mean to give it a go sometime soon.
On Saturday, 21 April 2012, Adrian Brown wrote:
That's top, im a child of the electronic sound -- don't think my wife
is too impressed with it blasting out of the office though ;) Im
working on some other sam bits at the moment (when time allows) For
programmery people, scrolling on sam is what let it down imho.
Thinking of something like sanxion, who has some ideas on how to move
that much data. Im guessing it would have to be mode 2 to really be
able to get a decent speed scroller. Ive tried various things for a
decent speed scroll mode 4, but it just doesn't seem possible if you
want a lot of graphics on screen, even with compiled block data.
Adrian
*From:*[email protected]
<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>
[mailto:[email protected]
<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>]
*On Behalf Of *David Sanders
*Sent:* 20 April 2012 11:16
*To:* [email protected]
<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>
*Subject:* Musics
Hello List,
If anyone fancies a listen to the most fiendishly complicated piece of
Sam music I've written, here it is:
http://dsanders.co.uk/sanxion.dsk
It's kind of a conversion of Rub Hubbard's Sanxion loader, but done
from memory so probably quite different. I believe the effect at
around 2:00 has never been done before on the Coupé! A first time for
everything even on the Sam eh? So, why did I spend my morning writing
this? Your guess is as good as mine, but I reckon someone now ought to
make the effort to convert the actual game. Ahem.
Cheers
David
