Sprite routines in MODE 13 - how did YOU do it?

discuss general risc os software applications and utilities
Related forum: adventures

Posts: 2355
Joined: Sun May 19, 2013 9:19 am
Location: FRANCE

Re: Sprite routines in MODE 13 - how did YOU do it?

Post by Zarchos »

1st of all thanks for your interest and positive comments : it's a real incentive for my 'work'.
Seeing the screenshots here is what I can say :
- the background is entirely black : I've got the fast filling routines for that, I intend to use for the Bad Apple demo (see my videos on my YT channel).
It's much faster than sprites plotting, simply because you don't have to load anything (except up to 4 pixels of the screen memory, wheen needed for the beginning and for the end of your segment. And my routines can cope with alternate pattern colour1,colour2,colour1,colour2 to 'increase' the colour perception).
- 1 load N stores routines is definitely helpful for the foreground 'plane'
- compiled sprites at runtime, with the method I explained earlier (creating them using what's left in terms of cycles per frame, not as a whole), taking into account that what is immediately adjacent to your current screen must be in memory to plot it without delay, if your main character moving must make the whole scene scrolls.
-playing area is limited to 320 x 200 : it helps not having to plot too much data on screen ; furthermore you could use an interrupt to switch to 16 colour mode 9 to display the bottom part and save some bandwith, or even to 4 colour screen mode and with RasterMan have 3 colours and gradient of colours ... the Amiga way. The cursor sprite could also be used in this part, as it could also be used in the playing area, for the main character (his hammer for example. Thats' almost free lunch in terms of CPU cycles).

I think on a 2 Mbyte machine all this could fit (consider I need only 60 kbytes of memory all the time for my sprite plotting routines, and even if I generate 4 compiled sprites for each sprite , 1/the code is very compact 2/the data (pixels) are very compact too ; and I don't use any mask at all).

More later.
I'm on a nasty bug at the moment :wink: getting on my nerves.

Last edited by Zarchos on Wed Apr 19, 2017 1:46 pm, edited 1 time in total.
User avatar
Rich Talbot-Watkins
Posts: 1707
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Sprite routines in MODE 13 - how did YOU do it?

Post by Rich Talbot-Watkins »

FWIW here's a video of Mode 9 Blurp running at 50fps, with awful graphics and far-sparser-than-intended level scenery. This is as far as I got with this before abandoning it (preferring to work on the Beeb, and on my RISC OS Sega Master System emulator).

I wasn't really happy about needing to go to a 16 colour mode, which is probably half the reason I never got far with it.

What's the runtime cost of compiling a sprite? Is there feasibly time to do it while running the game and rendering frames at 50fps? (including the cost on ARM3s of invalidating the cache too). It's a route I absolutely never explored, even though I'd heard of it being done back in the day. Always seemed to me like a last resort kind of thing, though I was probably most put off by the memory management / fragmentation issues, rather than the technical challenge of generating optimized executable ARM code.

By the way, in Hamsters, the background isn't black - it's a fixed graduated background (the cityscape silhouette actually forms part of the foreground scenery, weirdly). My ideal thought here would be to be able to substitute any simple tiled background, and not necessarily a repeating motif like in Blurp (obviously this benefitted hugely from load once, store multiple!).

Good luck with that nasty bug!
Posts: 2355
Joined: Sun May 19, 2013 9:19 am
Location: FRANCE

Re: Sprite routines in MODE 13 - how did YOU do it?

Post by Zarchos »

The runtime cost of generating/compiling a sprite is next to nothing : see in my videos : I plot 4 consecutive white pixels, each time I have generated the ARM code for one segment (not line : segment), so even if you've got a big sprite with long segments of pixels on a given line pertaining to the sprite, the cost in terms of CPU usage is neglectible.
Again : you generate the compiled sprites, segment by segment, using the free time until you reach the VBL.
The granularity of your CPU consumption is the creation of ONE segment... it's next to nothing.
Your code knows how much time it has to do that, with the IOC timer decreasing a value initiated at the start of the VBL (and now even easier RasterMan updates in realtime the number of the scanline the electron beam is on ;-) )

It's the same for the generation of segments of pixels needed for the routines (these pixels need to be rearranged, most of the time, to an optimal ordering which is in most of the cases different from what you see on screen. Imagine this :
what you want to see on screen is this, from a word boundary :
bbbp1 p2p3p4p5 b is background pixel, p(number) is the pixels(its number in the segment) pertaining to your sprite
word word
you could think the pixels are going to be ordered this way
000p1 p2p3p4p5
word word
when in fact for my routines, for that specific case, you'd better have
p1000 p2p3p4p5
this way your code is 1 LDMIA then 1 STRB to plot p1 and 1 STR to plot p2p3p4p5

And yes the memory management will be important, but again defractioning will happen when you know you have some free time until reaching the VBL, and by definition in a game running at 50 fps you always have so free time until reaching the VBL.

If you think I'm dreaming all this please say so.
To me there's a real authentic realistic possibility all this makes sense and could actually work !
And I'm so excited by the perspectives !
Remember I wanted to federate all the people I knew in France to create a games development company for the Archies ... I'm sure we could have created marvellous products ! (Or please let me think so [-o< )
Bad luck Acorn never distributed their fab commies outside the U.K., it prevented me from doing it.

PS : Have you still got the source of your game ?
It's really cute and the gameplay looks much more than good !
Posts: 62
Joined: Thu Feb 25, 2010 2:24 am

Re: Sprite routines in MODE 13 - how did YOU do it?

Post by David1664 »

Old thread resurrected!

Zarchos is doing some very impressive stuff in the realm of sprite plotting.

His latest video:


Who would have thought this was possible BITD?

Posts: 121
Joined: Fri Nov 24, 2017 1:35 pm

Re: Sprite routines in MODE 13 - how did YOU do it?

Post by Phlamethrower »

IIRC "generate 4 different copies of the sprite at different pixel offsets" is the basic approach that was used by FastSpr sprite plotter used by Asylum and Oddball. It's also the approach that I used myself back in the day (not sure exactly where I discovered the approach - probably I just copied what Asylum was doing).

FastSpr also used some kind of compression scheme for the sprites, to help skip transparent areas, and maybe to avoid storing duplicate row data in the sprite file. http://asylum.acornarcade.com/g_docs.php has some of my notes from when I was reverse-engineering the format.
Post Reply

Return to “32-bit acorn software: other”