XSpr is a fast sprite plotter, made by me. It comes in module and AOF format, with source code suitable for use with extASM/extAOF, and C header files.

The current version is 1.01, and has the following features (Or, what I can remember ):

* 8bpp,16bpp,24bpp masked/unmasked pre-shifted sprite formats (Giving 6 in total)
* Built-in sprite conversion code
* Can plot to virtually any screen size
* Support for transparent drawing on most formats (5 out of the 6 IIRC)
* Plain subtract-one-from-each component fade for 8/16/24bit rectangles on the screen
* Fractional fade (out of 256) for 16/24bit rectangles
* 9-pixel mean based blur for 16/24bit rectangles
* 'Plasma' effect for 16/24bit rectangles (Based on some dodgy blur code)
* Plain rectangle copy for 8/16/24bit rectangles
* Simple sprite pixel editing functions

Note that some of those features may have been ones I've put into the next version I'll be releasing (V1.10). I'll update this post when I check

Definate features for the next version (1.10) will be:

* Plotting to virtually any position in memory (E.g. clipping to an area on screen, plotting into another sprite, etc.) (Done)
* Any bug fixes for bugs I find (Done?)
* Compressed 24bit sprite support (Working...)
* Perhaps 8/16bit compressed formats as well

I'll update this thread as I work on XSpr.

If you want a copy, then for now just drop me a mail:

phlamethrower@hotmail.com

Of course, you lot can post here if you have found any bugs/have some features you want adding

Firstly I was thinking it might be an idea to look into swapping from ExtASM to another assembler. Depending on how much you've used ExtASMs extended features this could be tricky but (and I know it's still some way off) I very much doubt ExtASM will be updated to cope with XScale and the like unless the developer has picked it up again.

A very good assembler which is still be actively developed is Nick Roberts !ASM. The downer is that it doesn't have commands for automatically repeating instructions (ie like #rept) and it isn't likely to get them as I've asked in the past and apparently it's not easy (possible?) to add it due to the way the assembler has been written. It doesn't have a DIV command either. It does however have structures if you've used those.

You can find out more from

http://www.argonet.co.uk/users/tigger/programs/progs.html

and choose miscellaneous. The manual is available for separate download.

Secondly how about optimised plotters for plotting common fixed size sprites? I'm thinking 8x8, 16x16, 32x32 and 64x64. These would be remarkably useful for people plotting tiled backgrounds.

Apart from that I can't see any reason why I couldn't convert to it, since I haven't used any 'special' features apart from macros. Any command in extASM that uses a form of #end is clobbered by extAOF, which means that stuff like the repeating code and conditional assembly is impossible, so I haven't used any of those.

As for fixed size sprites, I'm wondering whether these have such a speed increase associated with them. It may be more trouble than it's worth to implement 24 extra sprite formats (4 sizes, 3 colour depths, masked/unmasked). The only thing I could think of that would help the speed any amount would be loading more than one line into memory at once, e.g. an 8bpp 8x8 sprite would only take 2 words per line, so about 2 or 3 could be loaded at once. This may well muck up my current system of plotting though.

I might add some other tiled system, e.g. plotting X sprites in a row would be a lot quicker than one by one.

I'll get a copy of XSpr 1.01 sent to you, and probably start noting down the addresses of people who want copies, so they can get upgrades easier

If you haven't used many of extASMs extensions then fair enough. I only mentioned it because sometime ago I converted from ExtASM to ASM and it took me aaaaaaages.

As for whether the fixed sprite sizes would speed things up, normally I would say yes but thinking about it now the usual trick of unrolling loops and such like doesn't work so well on cached machines does it? Doh!!

However loading multiple lines of data at once will definitely speed things up. Whether you'd see a huge increase though I'm not sure.

I look forward to having a play

This means that sometime in the near future, we'll all have some proper bots to play Pain Keep against! Yay!
[/shamelessplug]

What will be in though should be:

* Bug fixes (mainly for the C code I think, as it isn't quite kosher)
* Plotting to any memory location (e.g. clipping to a certain area on screen)
* Perhaps another blur type, such as weighted values for each source pixel (thanks for the idea, Andy!)
* Maybe convert the example programs to use the module version, or merge them all into one to cut down on download size (Or rather my uploads )
* Fix the module version number (I forgot to change it to 1.01!)

[shamelessplug]
I tried merging the PK and frogbot source, but gave up
Now instead I'm working on Coffee's Tutor bot, which although a bit simpler than I hoped looks like it's simple enough to understand.
[/shamelessplug]

[Edited by Phlamethrower at 16:12, 23/1/2001]

[shamelessplug]
Email me if you want a copy of the first version of the PK bot!
[/shamelessplug]

Secondly, XSpr V1.10 should be out in a couple of days. I've done a bit more on the compressed code, so it may be in there in some form or other.

Luckily quite a few were easy to fix, but there are a couple stubborn ones remaining. Also I can't get one of the test programs to work with the C compiler, so that one will have the C++ source instead. The compressed 24 bit sprite code is in, but isn't tested and there are no conversion routines for it yet. V1.10 should be out in a couple of days.

In other news, the PK bot can now use all the Pain Keep weapons, but there is still quite a bit to do. I must get round to telling a Quake/Bot news site some time...

I've fixed all the bugs that I know of, but still haven't tested the 24bit compressed sprite code.

There might be another little bug or two crawling around, and I could do with re-writing the documentation a bit so there may be a V1.11 out in a while, before I get back on track with the compressed sprites again.

This release is really just to remove all the fatal bugs you may find, really high quality programming on my part