Re: A89: Palet Shifting Routine
[Prev][Next][Index][Thread]
Re: A89: Palet Shifting Routine
I did some more thinking, now I think I can say what I meant.
>From a News Item:
>2.) ...Normally, the "screen" - which is represented in memory - is located
at $4c00. An ASM
> program can change this address, and the screen will display the data at
the new address.
>Grayscale is created by creating two planes - essentially two screens - and
changing the
>location that the calculator reads the screen data from very quickly.
****
The grayscale routine does (simulate/emulate?) a pallet. If we could have
multiple planes and step through them while switching between the 1st 2nd
and Nth plane we could do something with a similar effect as rotating the
pallet.
For sprites there would have to be multiple sprites that correspond with the
planes that are displayed. To move the sprite would require N plane writes.
From: "Olle Hedman" <oh@hem.passagen.se>
Sent: Friday, March 10, 2000 1:18 AM
Subject: Re: A89: Palet Shifting Routine
>
> That sounds very slow. The reasons why thoose arcadegames used that
technique is
> that all the palette-handling was(is) done in hardware, so you saved a lot
of
> cycles dealing with that, instead of changeing your whole sprite.
*****
I knew that Greyscale and pallet was done in HW on those machines... and
TI's have to have to have software stuff. (see first sentace I wrote in
this message)
********
> Actually, most games at least up to some years ago (and some today) uses
this
> tech to animate water or stuff like that. The reason is that it is fast,
since
> you just have to send some commands to a hardware port, and don't have to
redraw
> the sprite.
> The ti does not have any palette.
> To emulate a palette in software, as I understand you want, is to lose the
point
> of it some..
> And the format of grayscale pictures is very tightly connected with the
hardware
> in the ti89, so to have any other format would be very ineffective.
> Of course not impossibe, but you could just as well change the whole
sprite
> instead of fiddling around with some pseudo-palette..
******
I wasn't thinking of a pseudo-pallet, just the additon of more "planes" to
be switched between durring the greyscale routine.
******
> You should try find some docs on how the grayscale works in the calcs, and
then
> you'll understand more, why it is quite a bad idea to try to change the
format
> of sprites and such. Either that, or me or someone else here is happy to
explain
> it to you.
>
*****
Sprites would keep a similar format as they are now, it would just have more
"planes".
******
> file://Olle
>
> Aaron Peterson wrote:
> >
> > Does anybody have a pallet shifting routine out?
> > and what is the feasibility of this with b&w contrast changing grey
> > displays?
> >
> > (some old arcade games had this, my atari did it to avoid burning out
the
> > screen, windows 9x does it to animate the start up logo)
> >
> > I want a routine that has 4 static shades and, 4 or 12 rotating
shades...
> > whose colors can be redefined. (heck, a 3 static shades plus a blink
value
> > would be cool)
> >
> > This would allow us to have low cycle cost animation... er maybe not if
we
> > had to have 4 bits to a pixle instead of 1,2 or 3. (and TI doesn't
have a
> > grey scale display...)
> >
> > we would need a sprite routine to handle this.
>
References: