A89: Re: Re: Shifting Planes to create illusion of palette shifting.

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

A89: Re: Re: Shifting Planes to create illusion of palette shifting.

I can do it in basic [2plane no prob][3plane flickers].

I don't see why it couldn't be done in ASM using the highly optimized
greyscale routines.

The attached file is a basic program that works.  Up and down change the
number of trills [music term] before switching trill type.  Left and right
changes the mode of what gets displayed twice in a row. [B or 0 (see my last
message]

[An abreviated version also included at bottom]

Scott,   Thank you for your time.  I think you are saying that there is not
any time to be able to switch greyroutines periodically as to create the
illusion of palette shifting.

You haven't convinced me that this would be impossible [ My newbie
Naivety?], and I will continue investigating this... but not on the
TIcalc.org mailing lists because of lack of patience.

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

I didn't see anything in your reply that goes with my intended purpose...
you talk about inverting images and 7grey with tons of flicker as being bad.
I don't want to invert images.  I want to exploit that flickering.

Think BLINK.

What I want is similar to 7grey... with a huge amount of flicker [except for
the pixels that are the same in all of the planes witch need to show up as
black or white]
I want to exploit the flicker to get a different effect.  I have not seen a
program do this, so I am talking about it, asking about it, researching it,
refining my own thoughts so that I might achieve this effect.

enclosed are some examples in basic.  I have to do a clearscrn that messes
up the effect.

Keep 4 shades static and provide 4 alternating shades.

The sprite drawing and sprite stuff would be extremely similar to stuff that
works with grey7lib. [move 3 planes around]
Only 4 shades of gray would appear on the screen.  Some of these would
appear to blink.

Blinking


> > A)000000000000000011111111111111110000000000000000
> > B)001001001001001002002002002002001001001001001001
          |-----1/2 second---|

******
Complete version is attached
******
Prgm
Local  i,j,hh,mm

Dialog
Text  " Pseudo Shiter"
EndDlog

Lbl  aaa
ClrDraw
PxlText  "Bk Lt Dk WL LW BD DB",8,0
PxlText  "Bk=Black WL=White&LtGrey",48,0
PxlText  "Lt=LtGrey DB=DkGrey&Black",56,0
PxlText  "??????      ??????   0  ",19,0
PxlText  "??????   ???      ??? 1 ",28,0
PxlText  "???   ???      ??????  2",37,0

0»j
3»i
5»hh
2*hh»mm

PxlText  string(hh)&" ??hh ?modeÐ",64,0
Lbl  aa
If mod(i,3)=0 Then
j+1»j
If j<=hh Then
PxlText  "??????      ??????   0  ",0,0:Else
PxlText  "??????   ???      ??? 1 ",0,0
If  j>=mm:0»j:EndIf:Else
PxlText  "???   ???      ??????  2",0,0

EndIf

i+1»i
Goto  aa

EndPrgm


[also I won't send email to your private box anymore, I got excited and
thought I had it right this time and wanted a quick responce...
innappropriate?]

----- Original Message -----
From: "Scott Noveck" <noveck@pluto.njcc.com>
To: "Aaron Peterson" <happy_cobbler@bigfoot.com>;
<assembly-89@lists.ticalc.org>; <ti-hardware@lists.ticalc.org>; "Olle
Hedman" <oh@hem.passagen.se>; <nbr@ticalc.org>
Sent: Tuesday, March 21, 2000 1:24 PM
Subject: 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
>

PS.89P

References: