TI-H: Re: Shifting Planes to create illusion of palette shifting.


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

TI-H: 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 -----
From: "Scott Noveck" <noveck@pluto.njcc.com>
To: "Aaron Peterson" <happy_cobbler@bigfoot.com>; <assembly-89@lists.ticalc.org>
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
>

References: