Sprites, transparency and backgrounds

I’ve written some C code that moves a sprite across the screen. It’s pretty simplistic at this stage; it just moves from left to right in a straight line. However, I’m having a bit of a “logic issue” where it comes to drawing a background.

At startup I’m drawing a full background to cover everything. I then draw the sprite on top of it. When the sprite moves, I redraw the background in its previous space. For example, if the 50×50 sprite is currently at 0,0 and I move it 5 units to the right, then I redraw the background from 0,0 to 5,50. Next, I draw the sprite in its new location (5,0).

That works perfectly with a square sprite, but I’m using a round sprite with transparency around the edges. It leaves a trail in the transparent area when it moves; this of course makes sense because I’m not redrawing anything in that “dead zone”.

My problem is that I don’t know how to get around this. I’ve tried drawing the background over the whole original sprite (in this case from 0,0 to 50,50) and then redrawing the sprite in its new location, but that results in flicker. I’ve had a couple of other ideas but they’re pretty clunky, and I don’t want to mention them just yet in case I get back “yes, that’ll work” instead of a “proper” solution :)

Any tips?

I think people would use screen buffering to reduce flicker, to draw to the non-visible buffer and then switch when drawing is complete.

Alternatively, if you don’t envisage having too many objects to have to deal with, you could take a copy of the screen before plotting the sprite (not the entire screen, only the part that will be overwritten) so you can paste it back when the object moves.

There’s probably a better/cleverer way, but I’m not a games programmer…

Edit: This might help? http://www.riscos.com/support/developers/agrm/index.htm

Thanks for that link; looks like I have a bit of reading to do!

I did think about taking a copy of the screen before plotting the sprite, but this copy would therefore only contain a piece of the background – and then I’m right back where I started.

One of the guys at work had suggested drawing to the buffer, but naturally I completely forgot about that! :)
I’ve found the relevant section in the PRM so there’s some more “light” reading.

Thanks for the pointers :)

Hi Chris,
I am a games programmer and released Overlord (Amcog Games) earlier this year and am working on a new title at the moment. (Just spent 3 hours tidying up the main game sprites, which was a slow process…)

If you are developing for modern RISC OS hardware i.e. Iyonix, Pandaboard, Beagleboard, ARMX6, Raspberry Pi, then you will need to employ “triple buffering” rather than double buffering. Further, the raspberry Pi has some instabilities around when the frame wait occurs.

I’m using BASIC at the moment as its quite rapid for development (and makes a change from C++ during my day job)
The BASIC equivalent to the routines you need are on this page at the base of the page:
Triple Buffering

Tony

Hi Tony,

I’d seen Overlord; unfortunately it doesn’t look like my kind of game but it’s good to see new development for the platform. Legends of Magic looks interesting though, and I might grab it when it’s ready (I don’t have enough free time to beta test so I haven’t said anything in its thread).

Thanks for the tip about triple buffering; it seems that nothing is ever as it seems around here! Jeffrey’s provided an overview on page 2 so that combined with the code from page 3 should be useful.

I’ve actually been careful not to say the word “game” in this thread as I don’t want to get anyone’s hopes up! I’ve been working on this off and on (more off than on, if I’m honest) for maybe a year now so don’t expect anything anytime soon…

I realise that this is completely devoid of detail (don’t have time right now for a full description) but have you run into a crash (abort on data transfer) when doing OS_Byte 19 to wait for sync?

Edit: Cancel that; I wasn’t calling it correctly (believe it or not!)