Re: A89: Palet Shifting Routine


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

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.
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..
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.

//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.


Follow-Ups: References: