On Wed, Feb 14, 2018 at 01:52 am, Paul Marshall wrote:
I am a bit uneasy about using the hard drive in this wayIf you use a *GSAVE/*DISPLAY pair to move a block of graphics the 'round trip' will simply be via cache RAM, not your hard drive. Indeed if you repeat it sufficiently frequently, using the same filename, the bitmaps may never make it onto your disk at all, except the last of course!
Nevertheless there is an alternative method you can use when you know that your window is sufficiently smaller than the backing bitmap (which is usually 1920 pixels wide) that there is enough 'off screen' area into which to move your block. In that case you can use RECTANGLE ... TO copy the block from the visible area into the off-screen area, and then another one to copy it back (either to the same place or somewhere different). This is exactly the technique I use in the recent 'penrose.bbc' demo to save and restore the region behind the 'ball' sprite.
However you really need to wean yourself off any technique that involves copying a region of the screen, because it is likely to be very slow. All modern graphics cards are optimised for rendering, and support for moving bitmap data in the opposite direction (i.e. from the screen to your program) is limited and slow. Although it may be counter-intuitive, redrawing the entire screen every frame is likely to give the best performance, because that's how modern programs are expected to work.
David Williams' Forces of Darkness game is an excellent example: every frame is redrawn from scratch (using GFXLIB routines in BB4W and native SDL functions in BBCSDL) which may seem an awful lot of work compared with animating just the moving 'sprites', but it can achieve frame rates of 50 fps or so even on a relatively slow platform like the Raspberry Pi.