The Sinclair QL Forum

For your fun I share some simple animation made with my QL.
Simply unzip the files into your flp1_device and lauch the _bas file.
For faster machines or emulators please try the paused version and increase the PAUSE parameter if necessary.
They won't work on an unexpanded QL: some extra RAM is required.
Enjoy!

https://www.dropbox.com/s/tf5olrq5g2mnqcp/miao.zip?dl=0
https://www.dropbox.com/s/qwwmn8vcpmlbc ... n.zip?dl=0
https://www.dropbox.com/s/3l0twzuemrsu2 ... k.zip?dl=0
The following one has some sound: be careful because on certain emulators the sound may be unreliable.
https://www.dropbox.com/s/2kevr4cxe7yc0bu/X.zip?dl=0
https://www.dropbox.com/s/fc9r2f35lqt02 ... e.zip?dl=0
Sorry for this one, but I didn't resist:
https://www.dropbox.com/s/cucgxypwm8dj6v4/D.zip?dl=0
Another one:
https://www.dropbox.com/s/nnxzuc3fazew8 ... s.zip?dl=0
The Christmas card. In case of faster systems/emulators: please slow down the animation increasing the "p" value (5 or 6 should be OK for Qemulator).
https://www.dropbox.com/s/ip38pg9l0g69m ... Y.zip?dl=0

P.S.
Since the .zip files are normal _bas and _scr, they should be normally unzippable outside QL without data loss.

I just tried the cat one, that's really clever How does it work?

vanpeebles wrote:I just tried the cat one, that's really clever How does it work?

Thanks
Anyway, it's nothing so special: an uncompressed _scr sequence is first loaded in Ram1, then displayed with LBYTES.

I might have a go at one, using the code

vanpeebles wrote:I might have a go at one, using the code

Could you please explain better what do you mean?

Hi Cirstan,

Tried all the files on QEMulator under Wine on a Linux machine, works really well.

I remember a while back, there was talk about using the Minerva enabled second screen flicker free animation. I think the idea was to write one image to the SCR1 and SCR2 at the same time and flip the screen after the raster scan.

I wrote some assembler extension to copy SCR1 to SCR2, quite trivial really. Maybe worth revisiting the idea.

Cristian wrote:

vanpeebles wrote:I might have a go at one, using the code

Could you please explain better what do you mean?

Make my own scr files and then animate them using that example

vanpeebles wrote: Make my own scr files and then animate them using that example

Sure, please feel free. Maybe we're starting a new Qanimation era
I have some other animation to share soon

Nice little demos showing how to achieve an animation in plain superbasic! Just spent pleasant little half hour tinkering with them and getting them to work on QPC2 (not had much time to do much QL tinkering recently, so enjoyed that!).

Greatly simplified, the animation routine takesa advantage of the speed of LBYTES loading data from a ramdisk. For less experienced users, the files are just ordinary saved 32K screen images.

Because of that, the demos will only work on a QL with 512x256 screen fixed at address 131072 (decimal).
Of course that will loop around forever until you BREAK out of it. You could change the PAUSE speed% to IF INKEY$(speed%)=CHR$(27) THEN EXIT animating to allow the user to press ESC to quit from the loop.

If you experiment with Cristian's routines on an emulator or anything with extended screen modes, bear in mind the following:

The emulator has to be set to start with a QL compatible screen (512x256 at address 131072 in QL colour modes)
The programs have inline code between procedure definitions - ideally the definitions would be after the main program.
The programs switch between mode 4 and 8 in the program.
The program is essentially an installation routine which formats, copies and renames files to ram1_ from flp1_
As it stands, hard-coded to work from FLP1_ only
Ideally, the screen graphics files would have a standard extension such as "_scr" to help identify them amid other files

Next step for tinkerers whose systems include a MOVE_MEMORY type extension (you would need something like Turbo Toolkit for this) would be to take it to the next level by loading each screen into a common heap area of memory and use MOVE_MEMORY to zap the screens quickly to the screen. Calculate how many screen (screens*32768) and ALCHP that much memory. Load each screen into that memory 32768 bytes apart. Then in turn copy each 32k area into the screen memory.

base=ALCHP(32768*number_of_screens)
LBYTES scr_01, base
LBYTES scr_02, base+32768
LBYTES scr_03,base+32768+32768
REM and so on
REPeat animating
MOVE_MEMORY base TO 131072:PAUSE speed%
MOVE_MEMORY base+32768 TO 131072:PAUSE speed%
and so on
END REPeat animating
RECHP base: REM get rid of allocated memory

Not a tested routine, just written as I haven't time to take this further.

In itself, not much improvement over Cristian's routines, but with the necessary knowledge you can start to blitz each line of the graphics at a time, allowing 32K screens to be loaded into a larger screen and so on, progressively building into a general purpose animation routine which could work on more than just a basic black box QL. There are extensions and toolkits out there such as my DISPLAY_CDE which let you interrogate the system to find the address of the screen in memory, how many bytes per line across the current display mode (so you can calculate line by line where to put the 128 bytes per line of a standard QL screen line by line into the video screen for more flexibility in terms of handling extended resolutions and so on). The subject of a future animation and cut/paste type article perhaps if ever I get time, whichis unlikely ATM.

Thanks, Cristian.



{Not trying to be negative or critical, just trying to be helpful to less experienced users,}