A89: Re: Shifting Planes to create illusion of palette shifting.
[Prev][Next][Index][Thread]
A89: Re: Shifting Planes to create illusion of palette shifting.
Please bare with me if I am just being
thickheaded.
Scott
Thank you for correcting my 121212. I was not connecting 0 0 1 0 0 1 with what I was trying to
say, and I messed me up.
Sooo...
I'll put it Yet another way, this time
hopefully correct enough to get my idea along....
Think of two grey4libs. One with addresses of
planes 0 and 1
another with addresses of planes 0 and
2
Grey4A knows about 0 and 1
Grey4B knows about 0 and 2
The interupt would have to start a program that
figures out wich one to use.
Additonal overhead is keeping track of which
greyroutine has the floor. I think Keeping track of it would be
accomplished with a counter that gets incremented And something that
makes a dicision based on a moderately significant bit in that
counter
What I mean by a moderatley significant
bit:
If this program gets called once per screen
refresh and the screen gets refreshed 15 times per second we would choose the
3rd or 4th least significant bit [16 cycles between flops of this bit] so the
routine would switch between Grey4A and Grey4B about 1 time per
second.
If that bit were 0 Grey4A would "have the
floor"
If that bit were 1 Grey4B would take
it.
(apperantly the greyscale libs keep a sort of
counter going between callings and they display a diff plane based on that
counter... so another iteration of a greyscale routine might work
awsome)
The Grey4A and Grey4B would handle the 0 0 1 0 0 1
0 0 1 and 0 0 2 0 0 2 0 0 2 respectivly
Interupt occurs
increment counter
decide if Y is 0 or
B
If Y ==
B
{
Check moderatley significant bit inorder to set X to 1 or
2
draw planeX
}
If Y ==0
draw plane 0
Figures:
*1*
A) extra decision
B) same decision as in grey 4 lib
A)111111111111111122222222222222221111111111111111222222222222222211111111111111112222222222222222
B)00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B00B
*2*
A) moderatley significant bit
B) plane displayed
A)000000000000000011111111111111110000000000000000111111111111111100000000000000001111111111111111
B)001001001001001002002002002002001001001001001001002002002002002001001001001001002002002002002002
The only thing that I could see as causing flicker
is the extra overhead--this could be fatal to this idea... not really if the
screen held plane 0,1 or 2 for a few extra refreshes, only the blinking text
would look wierd... blinking text is supposed to look wierd!
Potential optimizations,
figure out what plane needs to be shown only
every 3rd cycle (this might also be used to increment the counter less
often and use a less significant bit in the counter... less
rotates?)
set plane 2 as the normally shown plane (aka Dark
Grey) so the bit in the counter could be used directly as what plane to show as
B
----- Original Message -----
Sent: Monday, March 20, 2000 10:02 PM
Subject: Re: Shifting Planes to create illusion of
palette shifting.
> > 4 color 3 plane
grayscale.
>
> Nope, it just don't work well that way - read
on:
>
> > Instead of 1 2 1 2 1 2 1 2 etc,
>
>
Actually, currently the grayscale all uses:
> 0 0 1 0 0 1 0 0 1 0 0 1. .
. twice as many zeros as ones
> (for graphlib - in gray4lib, it's
twice as many ones as zeros)
>
> always start counting a zero when
refering to anything programming related
>
> > we would do 1 2 1
2 1 2 1 2 1 2 1 3 1 3 1 3 1 3 1 3 1 3 1 3 1 2 1 2 1 2 1
> 2
>
> That is exactly identical to [0 1 0 1 0 2] repeating, or:
> 0 1 0
1 0 2 0 1 0 1 0 2 0 1 0 1 0 2 0 1 0 1 0 2 0 1 0 1 0 2 0 1 0 1 0 2
>
(always spread these as evenly as possible.)
>
> Yes, that WOULD
normally allow 8-color grayscale - but it flickers too much
> for the calc
screen. Therefore, some sacrifices must be made which makes 1
>
screen display 2/3 of the time and the others each 1/6 of the time, I
>
believe. That allows for seven colors (8 combinations, but two
overlap)
> with very little flicker.
>
>
------------------------------
> And to sum that up and reply to the whole
rest of the message:
>
> Theoretically, yes, you would be somewhat
right (assuming you spread the
> switches as evenly as possible, not
"every half second") - but it's
> certainly not an idea that many people
haven't thought of before. And, in
> practice, it just doesn't work
- there are practicality issues preventing
> that from working without a
rediculous amount of flicker.
>
> -Scott
>
Follow-Ups:
References: