Inquiry about 'generated sprites' techniques used on the ST and the Falcon

[Zarchos]

As a (lazy) ARM coder I have developed what I believe is a good 'generated code sprites' generator.
I would like to know which solutions you chose on the ST and later machine with faster CPUs, and the Falcon (with its chunky modes).

My technique and ideas for the Archies are described here :
http://www.stardot.org.uk/forums/viewto ... s+plotting and the links provided in the thread.
Please note the Archimedes uses chunky modes, linear, so what happens is that the memory controler on the Archimedes reads sequentially, under DMA, the memory space defined as memory screen, sends this data to the VIDC (video controler) which outputs them.

My routines use mode 13, it is the 320 x 256, 8 bits per pixel screen mode on the Acorn Archimedes.

Thanks for your comments, it will be highly appreciated.

I think I have re invented the wheel and it has all been done already on the ST ; but if, who knows, that wasn't the case, I would be more than happy to give even more details to some programmers out there to port the technique to the ST.

Please note : this thread isn't intended to start a 'My machine is much better than yours'.
Contrary to the other well known other 68000 machine at the time, I do praise the ST for being the 1st available, ultracheap, and gifted with many games and great apps, and easy to use.

You might need to know the following on the Archie :
- There are no memory to memory transfer instructions in the ARM2 (early generation of Archies) instructions set : it is always memory to register or register to memory
- The ARM2 can only deal with :
+ 32 bit words or series of consecutive 32 bit words (1 register (1 time 4 bytes) ; n registers (n times 4 bytes) )
with the LDR / STR and LDM / STM (load / store register and load / store multiple registers)
or
+ one byte
with LDRB / STRB (load / store one byte).

As I said earlier maybe my technique can be of interest, most probably for the Falcon becuse it uses chunky modes.
Before giving you more infos I'd like to know if there is some interest, and as I do not see the interest of reposting everything here, I give you some links to listen to, or read, to know more.
https://youtu.be/2gr2YhaXYsk Steve Harrison presenting his raster manager and then me trying to explain my sprites routines
Then you have the link I gave at the beginning to the stardot forum ... sorry for the not so good English.
http://www.stardot.org.uk/forums/viewto ... s+plotting

Links validated.

[troed]

Top off my head, this is what demo coders on STs without blitter did (and was covered in the thread it seemed).

Code generating code that dynamically analyzed the graphics to be drawn, as well as possible shortcuts depending on position on screen and need for background clearing or not. The generated code would directly draw the graphics (no extra graphics lookup needed). This of course wastes enormous amounts of memory, but is always the fastest.

[Zarchos]

Please moderator delete the multiple copies.
The site kept saying me that there was an issue with the page, so I resent many times.

[troed]

On the ST, the most limiting factor is that there are only bitplane modes available. You're unable to address a single pixel in any effective way, and while there are some tricks to address blocks of 8 through the movep instruction, most code simply works on 16 pixel (word) boundaries.

Most sprite code you'll find on the ST will thus need to take care of a lot of bitplane quirks, and that's where most of the optimization can be found. Anything that needs smooth 1 pixel horisontal movement will most likely exist in 16 copies, preshifted, for example.

[simonsunnyboy]

Chunky or not, sprite data can be pregenerated for bitplanes as well. We call this technique "preshift".
Combining preshift with creating a direct algorithmn to apply the preshifted data should be possible aswell. I also think that's the way the real-big-sprite demos on the ST do work....

[simonsunnyboy]

The Thadoss technique for Falcon was explained here: viewtopic.php?f=68&t=24462

[Zarchos]

The Thadoss technique for Falcon was explained here: viewtopic.php?f=68&t=24462

Thanks for the link provided. Will read with interest.

[mlynn1974]

I don't know if I can add more to what has been already said.

In low res (320x200) the STOS BASIC sprite command has the sprite in memory and uses the ROXL instruction to rotate the bits to reposition the sprite depending on the x position and multiply the start line by 160 for display. It then uses the OR instruction to display the sprite on top of the background. 13 16x16 4 bitplane sprites in 1 VBL is possible when compiled. This is nice but not efficient. STOS Extensions like Misty give you the option to display 1 bitplane sprites and uses a table of y-offsets to avoid the multiplication.

For horizontal scrollers a 4 pixel preshift is sufficient. If you double buffer the display this can provide a nice effect of the scoller moving 4 pixels per frame despite the 16 pixel per word limit. Clipping might have to be dealt with differently. Also displaying sprites "behind" other sprites in games and demos would require a sprite\tile arrangement where the display priorities change.

The ZX Spectrum game Skool Daze require real-time positioned sprites due the number of sprites displayed on screen at once and memory limitations.

[Anima]

Cho Ren Sha for the Atari Falcon 030 uses the DSP to support the sprite drawing to reduce the bandwidth needed to clear (restore) the screen.

[Zarchos]

Cho Ren Sha for the Atari Falcon 030 uses the DSP to support the sprite drawing to reduce the bandwidth needed to clear (restore) the screen.

Thanks, it is going to be an interesting read for sure.