ltf@killer.DALLAS.TX.US (Lance Franklin) (07/20/88)
Since I got such great response to earlier questions, I thought I'd try
another thats been bothering me for quite a while...I tried it a few months
ago and never got an answer that satisfied me.
When running a window on a screen that's interlaced, is there any way, in
a non-hardware-specific, intuition-friendly way to tell whether you're
starting an even or odd scan when you return from a call to WaitTOF. I've
done a little text file reader a-la Less that does a smooth scroll, but it
always looks a bit funny in interlace mode, since the blit that I do to
scroll the raster tends to "catch up" to the current scan position when
in interlace mode (or maybe not...I haven't fully analyzed why the effect
happens...it's kind of a "ripple" in the screen...but I wanted to see if
only doing the update on the even scans helps...it appears to help sometimes
if I wait TWO WaitTOF's between blits). I thought about double buffering,
but I don't want to wast the memory on two bit planes. Right now, I open
a CUSTOMBITMAP window with two planes on the WorkBench, then allocate a
bitmap with a single plane with it's address replicated in both plane pointers
in the RastPort.Bitmap structure. This allows me to have four color gadgets
in the frame, but faster blits (thru a second RastPort structure pointing to
the same single plane). Until we get to the point where we can open windows
with a different number of planes on the border and the interior, it'll do.
Oh yeah, two more little questions...
#1: Is there any way to have proportional gadgets rendered in anything
other than the windows Detail and Block pen?
#2: Is there any way to get String Gadgets to use anything but the
screen's default font...get's a bit annoying when somebody
replaces the WorkBenchs default font to an 11 point font.
Thanks.....Lance
"It's a Man's Life, taking your clothes off in public!"
--
+------------------+ +------------------------------------------------------+
| Lance T Franklin | | Now accepting suggestions for clever, humourous or |
| ltf@killer | | incredibly insightful .signature quote. Send Now! |
+------------------+ +------------------------------------------------------+jimm@amiga.UUCP (Jim Mackraz) (07/21/88)
In article <4860@killer.DALLAS.TX.US> ltf@killer.DALLAS.TX.US (Lance Franklin) writes:
)
)When running a window on a screen that's interlaced, is there any way, in
)a non-hardware-specific, intuition-friendly way to tell whether you're
)starting an even or odd scan when you return from a call to WaitTOF.
Good questions. I dunno. I probably should.
) Right now, I open
)a CUSTOMBITMAP window with two planes on the WorkBench, then allocate a
)bitmap with a single plane with it's address replicated in both plane pointers
)in the RastPort.Bitmap structure. This allows me to have four color gadgets
)in the frame, but faster blits (thru a second RastPort structure pointing to
)the same single plane). Until we get to the point where we can open windows
)with a different number of planes on the border and the interior, it'll do.
Nice idea, I think. Actually, no. If you are really doing a custombitmap
Window, it is a 'superbitmap' window, and a gimmezerozero window, and
you are paying too much for speed. Maybe in screen-land, there's
a trick here, but not in window-land.
Don't forget: the actual number of bitplanes visible is determined by
the screen. Superbitmaps, etc. are just metaphors, and not always
particularly fast metaphors.
Your trick would probably do everything twice, for both bitplanes,
whether the bitplanes were at the same address or not. You need to lie
about either the BitMap.Depth or the RastPort.mask to get rendering
to only do one plane.
You CAN render to a single plane: just set the mask in your Window's
RastPort to 1, and use it for window-clipped rendering through the
rastport. There may be some voodoo with layers where this won't work, but
I don't think there's anything else you could do in this case.
One thing I know for sure: if you do text in pen color 1 or 2 (i.e., into
a single bitplane) you can SCROLL it using clip blit just moving a single
bitplane.
)Oh yeah, two more little questions...
)
) #1: Is there any way to have proportional gadgets rendered in anything
) other than the windows Detail and Block pen?
)
) #2: Is there any way to get String Gadgets to use anything but the
) screen's default font...get's a bit annoying when somebody
) replaces the WorkBenchs default font to an 11 point font.
Yep: wait until V1.4. Until then, you have to roll your own. Neither
is too hard, if you don't try to scroll your string gadgets in a
proportional font.
)Thanks.....Lance
)"It's a Man's Life, taking your clothes off in public!"
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.jesup@cbmvax.UUCP (Randell Jesup) (07/21/88)
In article <4860@killer.DALLAS.TX.US> ltf@killer.DALLAS.TX.US (Lance Franklin) writes: >but I don't want to wast the memory on two bit planes. Right now, I open >a CUSTOMBITMAP window with two planes on the WorkBench, then allocate a >bitmap with a single plane with it's address replicated in both plane pointers >in the RastPort.Bitmap structure. This allows me to have four color gadgets >in the frame, but faster blits (thru a second RastPort structure pointing to >the same single plane). Until we get to the point where we can open windows >with a different number of planes on the border and the interior, it'll do. I do hope you're changing the number of planes in this second bitmap as well, or it won't help any. Don't hold your breath for different numbers of bitplanes in window borders/interiors. An easier way to get fast access to the inner part of a window is to simply mask out the planes you don't need at a given moment using the rp->Mask. Make sure you reset it when you're done. If you're using BltBitMap this won't help, but that's no real good with windows anyways. (ClipBlit should respect the mask, since it takes rastports). >Oh yeah, two more little questions... > > #1: Is there any way to have proportional gadgets rendered in anything > other than the windows Detail and Block pen? Not now (maybe in 1.4). > #2: Is there any way to get String Gadgets to use anything but the > screen's default font...get's a bit annoying when somebody > replaces the WorkBenchs default font to an 11 point font. Not now (major additions to string gadgets for 1.4 coming). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
childs@cadnetix.COM (David Childs) (07/21/88)
In article <2596@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: <In article <4860@killer.DALLAS.TX.US> ltf@killer.DALLAS.TX.US (Lance Franklin) writes: <) Right now, I open <)a CUSTOMBITMAP window with two planes on the WorkBench, then allocate a <)bitmap with a single plane with it's address replicated in both plane pointers <)in the RastPort.Bitmap structure. This allows me to have four color gadgets <)in the frame, but faster blits (thru a second RastPort structure pointing to <)the same single plane). ^^^^^^^^^^^^^^^ < <Nice idea, I think. Actually, no. < <Don't forget: the actual number of bitplanes visible is determined by <the screen. Superbitmaps, etc. are just metaphors, and not always <particularly fast metaphors. < <Your trick would probably do everything twice, for both bitplanes, <whether the bitplanes were at the same address or not. You need to lie <about either the BitMap.Depth or the RastPort.mask to get rendering <to only do one plane. I believe Lance was saying he uses a different RastPort structure with a depth of ONE point to the same single plane the other RastPort points to twice, and then uses the second different RastPort to do the blit. If I'm wrong please tell me. Why would it render everything twice if he used his second Rastport? I understand that the screen has 2 bitplanes, but if the Rastport has only one where would the second blit go? <)Thanks.....Lance < jimm David David Childs Internet: childs@cadnetix.COM Cadnetix Corp UUCP: cadnetix!childs 5775 Flatiron Pkwy {uunet,boulder,nbires}!cadnetix!childs Boulder, CO 80301
jimm@amiga.UUCP (Jim Mackraz) (07/24/88)
In article <3379@cadnetix.COM> childs@cadnetix.COM (David Childs) writes: )In article <2596@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: )<In article <4860@killer.DALLAS.TX.US> ltf@killer.DALLAS.TX.US (Lance Franklin) writes: )<) Right now, I open )<)a CUSTOMBITMAP window with two planes on the WorkBench, then allocate a )<)bitmap with a single plane with it's address replicated in both plane pointers )<)in the RastPort.Bitmap structure. This allows me to have four color gadgets )<)in the frame, but faster blits (thru a second RastPort structure pointing to )<)the same single plane). ^^^^^^^^^^^^^^^ )< )<Nice idea, I think. Actually, no. )< )<Don't forget: the actual number of bitplanes visible is determined by )<the screen. Superbitmaps, etc. are just metaphors, and not always )<particularly fast metaphors. )< )<Your trick would probably do everything twice, for both bitplanes, )<whether the bitplanes were at the same address or not. You need to lie )<about either the BitMap.Depth or the RastPort.mask to get rendering )<to only do one plane. ) )I believe Lance was saying he uses a different RastPort structure with a depth )of ONE point to the same single plane the other RastPort points to twice, and )then uses the second different RastPort to do the blit. If I'm wrong please )tell me. Why would it render everything twice if he used his second Rastport? )I understand that the screen has 2 bitplanes, but if the Rastport has only one )where would the second blit go? ) )<)Thanks.....Lance )< jimm ) ) David Childs Internet: childs@cadnetix.COM Well, I didn't see the key phrase 'with depth equal to one.' My comments apply to bitmaps with multiple pointers pointing to the same bitplane. As we've both made clear, depth of 1 is the trick. Maybe I don't see what the plans for the bitmap with multiplicity was. It's perhaps a way of tricking Intuition rendering to restrict itself to a single plane, but the more standard way would probably be the rastport mask. It depends on how you want to collapse 4 colors to 2, I guess. Maybe Lance had it all figured out. jimm -- Jim Mackraz, I and I Computing amiga!jimm BIX:jmackraz Opinions are my own. Comments regarding the Amiga operating system, and all others, are not to be taken as Commodore official policy.
ltf@killer.DALLAS.TX.US (Lance Franklin) (07/24/88)
In article <2622@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >In article <3379@cadnetix.COM> childs@cadnetix.COM (David Childs) writes: >)In article <2596@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >)<Your trick would probably do everything twice, for both bitplanes, >)<whether the bitplanes were at the same address or not. You need to lie >)<about either the BitMap.Depth or the RastPort.mask to get rendering >)<to only do one plane. >) >)I believe Lance was saying he uses a different RastPort structure with a depth >)of ONE point to the same single plane the other RastPort points to twice, and >)then uses the second different RastPort to do the blit. Yup..Exactly what I do..I thought about using mask, but I didn't want to take the chance of making an error and writing to the same bitmap twice (or to a non-existant plane). Doing it this way let me use all the ROM Kernal routines that use RastPorts and BitMaps without worrying about anything else. >Well, I didn't see the key phrase 'with depth equal to one.' My comments >apply to bitmaps with multiple pointers pointing to the same bitplane. Whoops...sorry, didn't make myself clear the first time. I definately create a SECOND RastPort and BitMap structure, both with a depth of one, then use those to do the rendering. Duplicating the plane pointer in the window ensures that the window displays the bitmap I'm rendering to. >Maybe I don't see what the plans for the bitmap with multiplicity was. >It's perhaps a way of tricking Intuition rendering to restrict itself to >a single plane, but the more standard way would probably be the rastport >mask. It depends on how you want to collapse 4 colors to 2, I guess. Yeah...the problem with duplicating the bitmap pointers in the window RastPort was that the colors you ended up with were 00 and 11...ok if you want orange lettering on a blue background. It was an experiment, anyway. I tried it another way, doing a regular WBENCH window (no CUSTOMBITMAP) and creating the second bitmap with a depth of 1 pointing only to the zero'th bitmap in the window's RastPort. Got fast rendering with colors 00 and 01, but had an extra plane sitting around. Now, if I could just figure out how to use the second plane for double-buffering, maybe I could get a REAL smooth scroll without side-effects. :-) >Maybe Lance had it all figured out. Maybe. Lance -- +------------------+ +------------------------------------------------------+ | Lance T Franklin | | Now accepting suggestions for clever, humourous or | | ltf@killer | | incredibly insightful .signature quote. Send Now! | +------------------+ +------------------------------------------------------+
childs@cadnetix.COM (David Childs) (07/26/88)
In article <2622@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: )In article <4860@killer.DALLAS.TX.US> ltf@killer.DALLAS.TX.US (Lance Franklin) writes: ) Right now, I open )a CUSTOMBITMAP window with two planes on the WorkBench, then allocate a )bitmap with a single plane with it's address replicated in both plane pointers )in the RastPort.Bitmap structure. This allows me to have four color gadgets ^^^^^^^^^^^^^^^^^^ )in the frame, but faster blits (thru a second RastPort structure pointing to )the same single plane). (JUST ONCE) ^^^^^^^^^^^^^^^ THIS IS THE 1 YOU DIDN'T SEE ^^^^ THAT I DID. (Please note, I added it.) )In article <2596@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: )As we've both made clear, depth of 1 is the trick. )Maybe I don't see what the plans for the bitmap with multiplicity was. ) jimm He had the first RastPort be two bitplanes, so that he could render 4 color gadgets. I don't know if this is needed, but I believe that's what he wanted. He wants 2 colors for everything but the gadgets. Therefore, two rastports. Am I getting close Lance? David David Childs Internet: childs@cadnetix.COM Cadnetix Corp UUCP: cadnetix!childs 5775 Flatiron Pkwy {uunet,boulder,nbires}!cadnetix!childs Boulder, CO 80301
ewhac@well.UUCP (Leo L. Schwab) (07/27/88)
In article <4860@killer.DALLAS.TX.US> ltf@killer.DALLAS.TX.US (Lance Franklin) writes: >When running a window on a screen that's interlaced, is there any way, in >a non-hardware-specific, intuition-friendly way to tell whether you're >starting an even or odd scan when you return from a call to WaitTOF. [ ... ] An inspection of GfxBase structures reveals a lot of intersting and promising locations for inspection. However, since they're undocumented (no comments describing what they do), they are most likely private, subject to change, don't even think about it, etc etc etc. So we are left with a hardware solution. The hardware solution is to look at custom.vposr and examine bit #15. If it is set, you are in the long field (whatever that means). If it is unset, you are in the short field. It is unclear which is the even field and which is the odd field. Dale? Code to examine this would look like: #include <hardware/custom.h> #ifndef MANX extern struct Custom custom; #endif : : if (custom.vposr & 0x8000) /* Long field */ else /* Short field */ Hope it helps. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Hmm, you're right. Air is made up of suspended meat loaf." -- Josh Siegel
dale@boing.UUCP (Dale Luck) (07/28/88)
In article <6639@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > An inspection of GfxBase structures reveals a lot of intersting and >promising locations for inspection. However, since they're undocumented (no >comments describing what they do), they are most likely private, subject to >change, don't even think about it, etc etc etc. You're right if you expect to see 1.5 come out with some more bug's fixed and even greater features, you keep your dirty hands off my dirty bits. ;-) How about if WaitTOF returns a number describing the field we are on. There are actually 4 distinct fields in the generation of ntsc video. Current hardware only allows easy extraction of the LONGFRAME/SHORTFRAME information. > So we are left with a hardware solution. In general this is a poor assumption. The hardware guys need a bit of freedom to exercise their abilities to fix problems and improve the system. There may be times when you will just have to wait for us to provide a clean and future compatible way at getting at this information via well thought out software mechanisms.. > > The hardware solution is to look at custom.vposr and examine bit #15. >If it is set, you are in the long field (whatever that means). If it is >unset, you are in the short field. It is unclear which is the even field >and which is the odd field. Dale? The information is in the hardware manual. If bit15 is set then we are on the Long Frame. >_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ >Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (07/30/88)
In article <343@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <6639@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >> An inspection of GfxBase structures reveals a lot of intersting and >>promising locations for inspection. However, since they're undocumented (no >>comments describing what they do), they are most likely private, subject to >>change, don't even think about it, etc etc etc. > >You're right if you expect to see 1.5 come out with some more bug's fixed >and even greater features, you keep your dirty hands off my dirty bits. >;-) > I'll have you know that I wash my hands about a dozen times a day. >How about if WaitTOF returns a number describing the field we are on. Yes, please. That would be great. >The hardware guys need a bit of freedom to exercise their abilities >to fix problems and improve the system. There may be times when you will >just have to wait for us to provide a clean and future compatible way >at getting at this information via well thought out software mechanisms.. > But for those of us who need the ability now, asking us to please wait can be a bit frustrating (why does this sound like the overscan argument of some months back?). So I'll use the hardware, and put a disclaimer in the manual: "Warning: This program only works with circa 1988 Amiga hardware. It is entirely possible that future revisions of the custom chips will cause this program to toss its cookies. If this is the case, don't yell at Commodore, yell at me; it's my fault. I'll fix it. If I'm still in business." >>It is unclear which is the even field >>and which is the odd field. Dale? > >The information is in the hardware manual. If bit15 is set then we are >on the Long Frame. > Yes, but is the "Long Frame" the even field or the odd field? (Or is that information in the manual and I'm just too lazy to look?) _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor