A89: Re: Shifting Planes to create illusion of palette shifting.
[Prev][Next][Index][Thread]
A89: Re: Shifting Planes to create illusion of palette shifting.
> I'll put it Yet another way, this time hopefully correct enough to get my
idea along....
I've understood all of the other messages, but at this point I just didn't
have the patience to read through more than half of it. You don't seem to
understand how fast the screen actually needs to flash in order to prevent
flicker, and what you're suggesting is not only confusing and pointless but
adds WAY too much overhead.
There are two versions of grayscale routines right now - 4 color and 7
color - and both of them do their job very well. As it is, 7 color already
has problems with flicker if you try to execute any code while the image is
displayed, rather than just display a static image. You just can't squeeze
out anything else - they can't handle it.
Nor do I see any reason for what you're suggesting at all. Originally it
was something about pallete shifting, which would not onlb be very confusing
with this but can be achieved very, very easily by inverting one or both
planes (and the inversion can be done very quickly by XORing each longword
with $FFFFFFFF).
So we've actually got two major problems with what you're suggesting:
feasibility (the fact that it won't work) and usefulness (the fact that it's
pointless)
> A)000000000000000011111111111111110000000000000000
> B)001001001001001002002002002002001001001001001001
You still don't understand - these aren't displayed in chunks. You need to
cycle the planes extremely fast - you can't display plane 0 five times and
then plane 1 five times - you need to do 0, 1, 0, 1, 0, 1 etc. with them as
closely spaced as possible.
Let me put it this way - if you don't understand the core concepts here well
enough to program it yourself, then it's likely that someone who does has
already realized that it's not feasible and/or useful.
-Scott
Follow-Ups:
References: