[A83] Re: Grayscale Scrolling -> Help Needed:

[Prev][Next][Index][Thread]

[A83] Re: Grayscale Scrolling -> Help Needed:

 

Basically i have a grayscale pic. It is 192x192 so i divided up into 6 parts
(my previous example screwed up). They are all 96x64, which is 1 full
screen.The lookup table idea sounds good, but i'm not sure how to impliment
it. The big problem is the grayscale stuff. Basically Ian Grafs routine uses
the screens slow refresh rate to give the illusion of grayscale. This is
doneby showing different parts of the pic at different speeds. The lighter
the gray the faster it flashes. Now thats fine by itself but it has its own
plotting routine and stuff, so i'm not sure how to make it so that it would
tile 6 full screens, so that i can scroll through them.

>From: "David Phillips" >Reply-To: assembly-83@lists.ticalc.org >To:
>Subject: [A83] Re: Grayscale Scrolling -> Help Needed: >Date: Mon, 20 Aug
2001 17:44:37 -0700 >>>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,
thenyou 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
atthe 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
screenevery 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
valuecan 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
oftimes to shift is the same >for the entire screen, and the byte to shift
isdifferent 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
setthe 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
ofspace. 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
togenerate 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? >>>>

----------------------------------------------------------------------------
Get your FREE download of MSN Explorer at http://explorer.msn.com[1]


--- Links ---
   1 'http://go.msn.com/bql/hmtag_itl_EN.asp'