Generated code for sprites

[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 Amiga.
My technique and ideas are described here :
http://www.stardot.org.uk/forums/vie...ilit=generated

Mode 13 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 Amiga ; 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 Amiga.

[phx]

Didn't read everything, but on the Amiga you will rarely generate "Sprites" with the CPU. Either you use the Blitter or hardware sprites.

But when using the Blitter it might in fact also be advantageous to select an interleaved bitplane format, to write them with a single Blitter-start.

[idrougge]

You'll have to go to an Atari forum if you want to discuss precompiled sprites. That's their domain.

[Leffmann]

Originally Posted by 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 Amiga.
...

This would obviously have been a rare thing on the Amiga, since we weren't as lucky as you Archimedes users who had real chunky-mode graphics right from the start (IIRC), but there is a thread on this somewhere in the forums.

[Old_Bob]

Originally Posted by phx

But when using the Blitter it might in fact also be advantageous to select an interleaved bitplane format, to write them with a single Blitter-start.

As a relative Amiga programming novice, I find this rather interesting. How is the blitter repointed to the correct address in each bitplane as it works through the data? Also, wouldn't this possibly require duplicate sets of mask bits?

B

[Zarchos]

Originally Posted by Leffmann

This would obviously have been a rare thing on the Amiga, since we weren't as lucky as you Archimedes users who had real chunky-mode graphics right from the start (IIRC), but there is a thread on this somewhere in the forums.

I have read several times, including on this board, that with accelerator boards, when the CPU reaches a certain level of speed, it could be more interesting to transfer sprites, or bobs or whatever people name bits and bobs you want to display, using routines relying a 100% on the CPU.
I do not know to which extent it is or not true, but if it is, I thought, humbly as you saw I wrote from the very beginning, that it could be great to exchange ideas and share the algorithms used.

Now, of course, if the interest of this thread is annihilated by thieves like the delusional G and his juvenile behaviour, it'll be hard to do anything constructive.

[britelite]

Originally Posted by Zarchos

Now, of course, if the interest of this thread is annihilated by thieves like the delusional G and his juvenile behaviour, it'll be hard to do anything constructive.

Pot calling the kettle black...

[phx]

Originally Posted by Old_Bob

How is the blitter repointed to the correct address in each bitplane as it works through the data?

Your BOB image data and the bitplanes both have to be organised in interleaved format. Then it looks just like a single bitplane-copy for the Blitter.

Also, wouldn't this possibly require duplicate sets of mask bits?

Yes. That's the only drawback. You have to duplicate the mask for each bitplane.

[coder76]

There is a possibility on 68020+ CPUs to use bitfield instructions to plot out graphics data in planar format with BFEXTU/BFINS. With them you can place out up to 32 pixels with a single instruction in a single bitplane. You get pixel precision shifts like with blitter, but instead of working with 16 bit data, bitfields are 32 bit wide. Transparencies in objects are more limited than with blitter though as there is no mask data. Haven't seen anyone using bitfields to plot out CPU graphics objects though on the Amiga, but I made a small routine, and it does actually work.

[Photon]

Here is the current realtime Amiga OCS record for 17x17px "sprites".

Records are mostly silly and special-cased, and don't translate well across platforms. The best way to find out if yours is the best is if you can see if someone wants to compete with you on your platform on agreed terms.

Zarchos, you will have to find a way to discuss this without resorting to personal attacks, or there's a risk the thread will be closed.

[DamienD]

Thread has been cleaned.

Zarchos and Galahad; we are all getting really bored of this. Again, this stops now!!!

[roondar]

Originally Posted by coder76

There is a possibility on 68020+ CPUs to use bitfield instructions to plot out graphics data in planar format with BFEXTU/BFINS. With them you can place out up to 32 pixels with a single instruction in a single bitplane. You get pixel precision shifts like with blitter, but instead of working with 16 bit data, bitfields are 32 bit wide. Transparencies in objects are more limited than with blitter though as there is no mask data. Haven't seen anyone using bitfields to plot out CPU graphics objects though on the Amiga, but I made a small routine, and it does actually work.

That is actually quite interesting.

I don't know if these instructions are particularly fast or slow, but this should make soft-blitting easier than using seperate rotates/logic operators etc.

[coder76]

Originally Posted by roondar

That is actually quite interesting.

I don't know if these instructions are particularly fast or slow, but this should make soft-blitting easier than using seperate rotates/logic operators etc.

On a 68030 a BFINS is 12-18 clock cycles (depends on shift length, as field can overlap two longwords in memory), and source operand must be datareg. In the graphics case one can optimize away the BFEXTU with a move + shift, it will be faster.

Generally, the idea with BFEXTU/BFINS pair is that you can pick up from memory a bitfield within a 32-bit memory location and write it into a dataregister with BFEXTU. It will erase datareg, and place fielddata into it with correct alignment to LSB, and you can easily manipulate the value further. From there you can write it out again with BFINS with a different shift into another 32-bit memory location. That way it is easy to deal with bitdata of various sizes within a longword and manipulate this data without also trashing nearby data when writing it out.

Good news is that bitfields will work faster with newer CPUs, on a 68060 it will be fast, and on the new Apollocore 68080 a bitfield operation is just 1 clock cycle. Will work pretty well with planar graphics modes.