At 08:59 �� 19/2/2002 +0000, you wrote: >Phoebus R. Dokos wrote: > >>Another problem presented is the PAN and SCROLL Commands which do not >>allow part of the physical screen to be panned or scrolled and only a >>window or cursor line (which can be pretty damn annoying (and slow) if >>you ask me... > > >If you set up a window as part of the physical screen, then PAN & SCROLL >will, shurely; do a "OPEN#ps_chan,scr", then just keep doing a >"WINDOW#ps_chan,<area to Pan/scroll> : PAN/SCROLL#ps_chan" - or am I just >missing summat here...I nose, you wanna do this in a single command. > >
I tried that but doesn't work right at least not all the time... The thing is that you PAN (or scroll) and then have to move contents from a memory area to fill the gap. Well it doesn't work exactly right. Additionally and regarding the use of a single scroll (or pan) command, it would take more than one command anyway as things are: 1. You scroll 2. You see which part has scrolled and copy that to the place of the space left by pan(or scroll), then increment a "scroll counter", so you'll know where to begin. 3. Return to 1. In any case that can be solved without too much memory waste if your scrolling area is kept to a minimum and you use a lot of repeating patterns (a la Hyperdrive -BTW anybody has that? My MDV died on that too :-((( ) which you alternate using a seemingly random pattern (eg. clouds moving on the sky). Continuous scrolling though is really tough to implement and be at least somewhat "believable". I just finished a test for which instead of using PAN/MOVE I use Memory_MOVE throughout a strip of a 100 pixels by 1600 pixels so I get fluid motion. The problem is that because this is severly fragmented (Line at a time and you have to pick and chose from the screen memory) it is VEEEEERRRRYYYY slow. (Compiled its a little better though) Phoebus
