Jody.Owens@kcufgat.fidonet.org (Jody Owens) (06/01/91)
Is John ever going to fix the scrolling problem???
Jody
* Origin: Amiga Central BBS 816-587-5360 320mbs MOKCI (1:280/304)goodwinm@CS.ORST.EDU (Michael Goodwin) (06/04/91)
In article <675757488.0@kcufgat.fidonet> Jody.Owens@kcufgat.fidonet.org (Jody Owens) writes: > Is John ever going to fix the scrolling problem??? > What scrolling problem? Is there one? > > Jody > > * Origin: Amiga Central BBS 816-587-5360 320mbs MOKCI (1:280/304) -- | /\.--.--. /\ | goodwinm@prism.cs.orst.edu | . ) ) ) o / _ / / | Real signatures are in cursive. | ./ / / / .-- /--. .--. (/ \/ | | / / \__/\__/\___/ (__(__(__/\__/\_ |
Jody.Owens@kcufgat.fidonet.org (Jody Owens) (06/07/91)
The after flicker while the text scrolls.
Jody
* Origin: Amiga Central BBS 816-587-5360 320mbs MOKCI (1:280/304)lord_zar@ucrmath.ucr.edu (wayne wallace) (06/10/91)
Jody.Owens@kcufgat.fidonet.org (Jody Owens) writes: >The after flicker while the text scrolls. This is the blitter's fault. If you have an accelerated amiga (14Mhz or better) get cpublit.lzh from ab20.larc.nasa.gov. Fixes the problem entirely for us lucky people with the $$ to have an accelerated amiga. The unaccelerated amiga 1000/500/2000 users can suffer ;) Seriously, it should be fixed, but on the other hand, how many amiga 500 users do more than play games, or can even afford a modem? BLAM BLAM BLAM!!! Okay, I guess there are a few of you....;) Yup. Jack, fix it, and that's an order! Um, request? Proposition? Plea? Beg? Snivel? > Jody Wayne
231b3678@fergvax.unl.edu (Phil Dietz) (06/10/91)
In <lord_zar.676520773@ucrmath> lord_zar@ucrmath.ucr.edu (wayne wallace) writes: >Jody.Owens@kcufgat.fidonet.org (Jody Owens) writes: >>The after flicker while the text scrolls. >This is the blitter's fault. If you have an accelerated amiga (14Mhz or better) >get cpublit.lzh from ab20.larc.nasa.gov. >Fixes the problem entirely for us lucky people with the $$ to have an >accelerated amiga. The unaccelerated amiga 1000/500/2000 users can suffer ;) >Seriously, it should be fixed, but on the other hand, how many amiga 500 >users do more than play games, or can even afford a modem? BLAM BLAM BLAM!!! >Okay, I guess there are a few of you....;) Yup. Jack, fix it, and that's an >order! Um, request? Proposition? Plea? Beg? Snivel? >> Jody > Wayne Couldn't the terminal screen be double-buffered? Like it'll scroll nasty on a hidden screen, then swapped, giving a nice jitter-text-free display. True, You probably won't be able to go beyond 2400 bps (you'll be drawing and swaping like crazy), but at least it will satisfy those people used to IBMs etc. that dont flicker. ---- Flame Proof o __ | o Shield of Phil Dietz +-- <__< | -+- Arrogance 231b3678@fergvax.unl.edu /\ | / \ University of Nebraska
ewilts@janus.mtroyal.ab.ca (Ed Wilts) (06/11/91)
In article <lord_zar.676520773@ucrmath>, lord_zar@ucrmath.ucr.edu (wayne wallace) writes: > Jody.Owens@kcufgat.fidonet.org (Jody Owens) writes: > >>The after flicker while the text scrolls. > > This is the blitter's fault. If you have an accelerated amiga (14Mhz or better) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Fixes the problem entirely for us lucky people with the $$ to have an ^^^^^ Software doesn't "fix" hardware. It may work around hardware limitations, though. > Okay, I guess there are a few of you....;) Yup. Jack, fix it, and that's an ^^^^^^^^^^^^ I think Jack has a large enough order with Jr-Comm, and shouldn't have to spend his time designing another blitter... -- .../Ed Preferrred: Ed.Wilts@BSC.Galaxy.BCSystems.Gov.BC.CA Ed Wilts Alternate: EdWilts@BCSC02.BITNET (604) 389-3430 B.C. Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
bneal@umaxc.weeg.uiowa.edu (Brian Neal) (06/12/91)
> Jody.Owens@kcufgat.fidonet.org (Jody Owens) writes: > >The after flicker while the text scrolls. > This is because of blitter. The problem becomes greater if you have a Amiga 500 with no true fast ram. If this describes your situation, go into the Option menu, select Terminal, and choose a smaller number of colors for your screen. The flicker is very annoying if you have a 16 color screen, so try using 8 or even 4. The blitter can only work with 1 bitplane at a time, hence the text seems to change color as it scrolls.
m0154@tnc.UUCP (GUY GARNETT) (06/13/91)
In article <6429@ns-mx.uiowa.edu> bneal@umaxc.weeg.uiowa.edu (Brian Neal) writes: >> Jody.Owens@kcufgat.fidonet.org (Jody Owens) writes: >>The after flicker while the text scrolls. >> > This is because of blitter. The problem becomes greater if >you have a Amiga 500 with no true fast ram. If this describes your >situation, go into the Option menu, select Terminal, and choose >a smaller number of colors for your screen. The flicker is very >annoying if you have a 16 color screen, so try using 8 or even 4. > The blitter can only work with 1 bitplane at a time, hence the >text seems to change color as it scrolls. You can also try the following: 1) turn "Optimized Scroll" on. 2) set yor text color to 1, 2, 4, 8, or 16 (each of these colors is only one bitplane deep, and will not flicker during the scroll). This solution is less practical on an ANSI-Color BBS than it is on a UNIX box (which is usually what I use it with). Wildstar "No matter where you go, there you are." -- Buckaroo Banzai
entity@cccan.uucp (Cybernetworx) (06/16/91)
In article <231b3678.676527511@fergvax> 231b3678@fergvax.unl.edu (Phil Dietz) writes: >Couldn't the terminal screen be double-buffered? Like it'll scroll nasty >on a hidden screen, then swapped, giving a nice jitter-text-free display. > >True, You probably won't be able to go beyond 2400 bps (you'll be drawing >and swaping like crazy), but at least it will satisfy those people used to >IBMs etc. that dont flicker. > Actually, it COULD be done at speeds above 2400 as well. There's a few solutions that jack could consider. One would be to use direct blitter access through the hardware for the screens (of course it won't conflict with other programs blitter use because he would make sure blitter busy wasn't set. More importantly, programs running in the background would probably not require much blitter use, since it is generally used for screen updates etc) In addition, by using an interleaved bitmap screen, he would also get rid of that annoying flicker since all bitplanes are moved in one blit. (it's also considerably faster doing blits this way) For those with the extra ram, he could add an option to also enable double buffering to ensure no color flicker. An optimal solution might be to avoid the blitter altogether for moving the screen, and just use a wraparound bitmap by using the copper to do all the work. The blitter/68000 could be used simply for putting the characters on the bitmap. This would definitely be the fastest solution. >---- Flame Proof > o __ | o Shield of Phil Dietz > +-- <__< | -+- Arrogance 231b3678@fergvax.unl.edu > /\ | / \ University of Nebraska -- __ __ /// \\\ /// UUCP: ...uunet!utai!mnetor!becker!cccan!entity CYBERNETWORX INET: entity@cccan.UUCP
jprad@faatcrl.UUCP (Jack Radigan) (06/18/91)
entity@cccan.uucp (Cybernetworx) writes: >In article <231b3678.676527511@fergvax> 231b3678@fergvax.unl.edu (Phil Dietz) writes: >Actually, it COULD be done at speeds above 2400 as well. There's a few >solutions that jack could consider. One would be to use direct blitter >access through the hardware for the screens (of course it won't conflict >with other programs blitter use because he would make sure blitter busy >wasn't set. More importantly, programs running in the background would >probably not require much blitter use, since it is generally used for >screen updates etc) In addition, by using an interleaved bitmap screen, >he would also get rid of that annoying flicker since all bitplanes are >moved in one blit. (it's also considerably faster doing blits this way) >An optimal solution might be to avoid the blitter altogether for moving >the screen, and just use a wraparound bitmap by using the copper to do >all the work. The blitter/68000 could be used simply for putting the >characters on the bitmap. This would definitely be the fastest solution. A Copper list is probably the best way to go, performance-wise, since the major thing here is to keep chip DMA contention down to a bare minumim because the cpu needs some chip time in order to access the serial port which is in chip address space. An interleaved bitmap is also viable, but less so, since I have to be able to do a quick de-dice of the screen before I can allow Intuition to put up its menus. I'd think that a Copper list that is oriented to text lines would be easier to do than an interleaved bitmap. Also, the text routines would need to be customized with an interleaved bitmap, right? Since WB2.0 speeds things up a good bit already, I think that this is less of a demand than it would have been under 1.3. Additional comments welcome... -jack-
Jody.Owens@kcufgat.fidonet.org (Jody Owens) (06/19/91)
Well I downloaded the CpuBlit file and it slows the scrolling down a tad bit
but it does stop the flicker. Someone told me to set on the smooth &
optomized scroll and that should fix it but it doesn't. Anymore
suggestutions for the flicker (fixing it with Jr-Comm's option except less
color)?
Jody
* Origin: Amiga Central 816-587-5360 MOKCI (1:280/304)entity@cccan.uucp (Cybernetworx) (06/20/91)
In article <1472@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >entity@cccan.uucp (Cybernetworx) writes: >>An optimal solution might be to avoid the blitter altogether for moving >>the screen, and just use a wraparound bitmap by using the copper to do >>all the work. The blitter/68000 could be used simply for putting the >>characters on the bitmap. This would definitely be the fastest solution. > > A Copper list is probably the best way to go, performance-wise, since the >major thing here is to keep chip DMA contention down to a bare minumim because >the cpu needs some chip time in order to access the serial port which is in >chip address space. > > An interleaved bitmap is also viable, but less so, since I have to be able >to do a quick de-dice of the screen before I can allow Intuition to put up its >menus. I'd think that a Copper list that is oriented to text lines would be >easier to do than an interleaved bitmap. > > Also, the text routines would need to be customized with an interleaved >bitmap, right? Since WB2.0 speeds things up a good bit already, I think that >this is less of a demand than it would have been under 1.3. > > Additional comments welcome... > Yep, the copperlist would present the fastest solution. The main problem with interleaved bitmap being the one that you pointed out regarding the blits. The OS doesn't support interleaved blits so you'd have to write your own routines probably. This is not necessarily a bad thing, since if you went the hardware route, you could do a much faster job than the system, *BUT* the most important thing is in the font support. It would be difficult for you to be able to write something so generic as to handle all fonts etc. Simpler to go through the system. The copperlist solution would also be relatively easy to implement I think. You could use the OS to write the text into the bitmap, scroll using the copper and have a moving splitscan. This way you could have the entire thing continously wrap-around, thereby saving tons of memory. (instead of stepping through memory for a bit, and then jumping back to the top since you'd have to perform a clear at the top then...) Well, I have no problems with JR-COMM since I'm only at 2400, but it might be something you might consider for those with 14.4k. BTW, are your screens double buffered at the moment? If not, you might consider having that as an option in one of the menus for those who have the RAM available. > -jack- -- __ __ /// \\\ /// UUCP: ...uunet!utai!lsuc!becker!cccan!entity CYBERNETWORX INET: entity@cccan.UUCP