[A83] Re: Grayscale Scrolling -> Help Needed:
[Prev][Next][Index][Thread]
[A83] Re: Grayscale Scrolling -> Help Needed:
I didn't think real grayscale was possible on 83, but if it is, looks decent
enough and doesn't cause a huge performance hit, then you have a few ways of
scrolling a large picture.
The first method is the old school method that most people use, since it's
the most obvious and seems to be fastest without detailed analysis. You
draw the entire screen at the start, and then when you scroll, you use the
shift/rotate and block copy instructions on the screen buffer to "scroll"
the data. You then fill in the missing edge using conventional drawing
methods.
The second method is newer. The first person I knew to use it was Kirk
Meyer, for Commander Keen for the 86. Hideaki Omuro's (crashman) tile map
routine uses this method (I actually gave him the idea to interleave it with
the display controller delay period :) You use lookup tables to redraw the
entire screen every frame.
If this is the first time you've ever heard of this idea, then your first
thoughts will likely be wondering exactly how this works, and how it can
possibly be faster than scrolling using shift/copy operations. Well, for a
static picture that is already "drawn" (i.e. not tiles), that needs to be
scrolled one frame at a time, it might not be faster. But, it will be
easier (and more fun!) to code, simpler and more flexible. If you want to
scroll two pixels at a time, it will definitely be faster. Plus things like
animation, etc., are already taken care of (yes, not needed for a static
picture, but generally you want more than a static picture). Also,
something to consider is to use Graphics Studio and convert the picture into
a set of tiles and a tile map (it's optimization and dithering should be
"perfect).
Conceptually, the idea is pretty simple. How do you display a single screen
of the picture when it's aligned? Easy, just copy the bytes. Ok, how do
you do it when it's not aligned? Shift the bytes one to seven times, then
copy the shifted byte. Alright, so how do we make it faster? Shift lookup
tables.
Lookup tables make it faster because instead of actually shifting the byte,
we just up what it should be in the table. What kind of table do we need?
Each byte can be 256 possible values, and will need to be shifted between
zero and seven times, so each byte value can be transformed eight different
ways. Multiply that together and we need a 2048 byte table. Now, even
though shifting zero times gives the original value, we still need it in the
table, otherwise we would need to check for this special case, which would
slow down the code and eliminate usefulness of this method.
How do we arrange the table? Since the number of times to shift is the same
for the entire screen, and the byte to shift is different for each byte, it
makes sense to arrange the table in sets of 256. If we align the table,
then we can just set the high byte of a 16 bit address to the starting
address of that shift position in the table, and set the low byte to the
byte we need to shift.
You'll want to generate the lookup table at runtime, since storing it in the
program would be a waste of space. I don't know which calc or shell you are
wanting to write this for, but I'm sure some of the 83/83+ experts on this
list can tell you where you might stash a 2k aligned lookup table. I don't
have any code off-hand to generate this table, but you can probably swipe
some from crashman's tilemap routine, or write your own. Really, that's one
of the easy things :)
Another thing to think about is that you really need two tables, for the
fastest speed. One for the left byte, and one for the right byte. Because
when you shift a byte, you end up with a left part and right part. The
right byte from one byte is combined with the left byte of the next byte.
This may sound confusing, but if you think about how the data is layed out,
it's not too hard.
You can get by with one lookup table, but it will take a little more
arithmetic to lookup both values. On the 82 series, this is probably
necessary, since there isn't a lot of available free ram like on the 86 (of
course, the question arises: why aren't you programming for the 86? :)
> Hi, I have a big problem. I have composed a large grayscale pic using Ian
> Grafs grayscale stuff. It is 192x192. I can divide it up into 6 blocks,
each
> exactly 96x64. Thats 6 full screen bits. Example: [ ][ ] <--\
[ ][ ]
> <--- Full Pic (6 blocks) [ ][ ] <--/ [ ] = 1 full screen. Now what
i
> want to do is make a 4 way scrolling routine that will let me scroll
around
> as if it were one big picture. Everything i have tried has crashed or not
> worked. Is there anyone in the world who can help me?
References: