Incidentally, do the articles from the '32K sprite plotting routines' refer to plotting sprites from files or writing bytes to screen, I understand how to do the latter.

Anyone willing to share some code?

Incidentally, do the articles from the '32K sprite plotting routines' refer to plotting sprites from files or writing bytes to screen, I understand how to do the latter.

They're mostly about optimisation techniques, either by speeding up the plotting itself or storing the sprites in better formats.

Anyone willing to share some code?

Sure. I don't have any code to plot !Paint Sprite files directly (I prefer to convert them to a simpler format first), but I can give you some pointers in the right direction. If you need info on the RISC OS Sprite file format then I'd recommend the PRMs, or failing that the OS SWI StrongHelp manuals.

Next I guess you'd have to decide if you're going to plot the sprites directly from the sprite files, or convert them to another format first. Converting them to another format can be a good idea because it allows you to simplify the storage format (i.e. no worrying about differing source/destination screen modes), as well as to convert them to formats which are better for the type of plotting you are going to perform (compression, pre-shifting, etc.). However leaving them in the original format might be alright if you're not too worried about speed or need to be flexible.

So what kind of plotting are you looking at doing? I.e. what source and destination modes, any transformations you might want to apply, etc?

Ideally I would prefer to plot the sprites directly from the files, although speed is a concern. Gaining access to the raw sprite data would however be useful as I could then (a) plot it from assembler and (b) manipulate it for the purposes of say 'full screen' modes, scaling's too slow.

Failing that I will try using Fast Sprite but my last attempt seemed to give a constant flickering at the top of the screen, and that was with screen banking; as a result I've tried to avoid Fast Sprite.

I have looked in the PRMS but they don't specify how the structure of a sprite i.e. the bytes can be accessed from assembler.

I have looked in the PRMS but they don't specify how the structure of a sprite i.e. the bytes can be accessed from assembler.

Apart from page 1-177 (although I have to admit that you need to extrapolate a little, or look at some hex dumps of sprite files)?

I always though that the RISC OS plotter was quite good (insofaras a generic plot routine), and you can get decent results if you use sprite pointers rather than names to plot (saves all that tedious mucking about in sprite space looking for them). You basically cache all the sprite pointers when you first load the sprite file in.

The best solution will always come from converting them into your own format, though. You can do this by reading sprite files, but in the early days, I just plotted the sprite to the screen and read that because in my youth, it was easier to do!

The best solution will always come from converting them into your own format, though. You can do this by reading sprite files, but in the early days, I just plotted the sprite to the screen and read that because in my youth, it was easier to do!

This is what I do (plot to screen that is). I have a system now where I have a converter program which I modify for the job in hand. The outer Basic loop plots consecutively numbered sprites and to the screen such that their top-left corner is at the top-left of the screen. Then I can just read off the data from the screen-start in a machine-code program and store in whatever format I want.

The data that comes out can be stored as a file and just in-lined in your code when you compile. One advantage that this has is that it doesn't waste everybody's hard-disk space when you release your game.

The only time I would use sprites in a spritefile in a game would be where I wanted to accept arbritrary (ie user-supplied) sprites and speed was not critical. In this case I would use OS_SpriteOp calls for everything. The thing is, the spritefile format is a bit kludged. you need to worry about whether sprites have palettes, left-hand wastage and so on.

Another thing, all those of you who have used Fast Sprite, why do I get this 'flickering' line at the top even when using screen banking. If I get past this problem then I think I would use Fast Sprite.

Another thing, all those of you who have used Fast Sprite, why do I get this 'flickering' line at the top even when using screen banking. If I get past this problem then I think I would use Fast Sprite.

There was a discussion on csap (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=c98257d84b.chris%40freeuk.com) regarding some observations. The basic outcome of this was that it depends on your programming sequence. The optimal sequence is:

1) Plot everything
2) Swap banks
3) Wait for VSync

This isn't intuitive, as you'd expect it to be:

1) Plot everything
2) Wait for VSync
3) Swap banks

However, the bank swapping actually occurs at the *next* bank swap, rather than the current, so by the time you've done your vsync it's too late.

Not sure if that's what is going on here, but it's a thought.

However, the bank swapping actually occurs at the *next* bank swap, rather than the current, so by the time you've done your vsync it's too late.

This is interesting, and might explain some trouble I had recently when getting triple screen banking under interrupt up and running.

Do you mean that the screen bank swap occurs at the next v-sync?

Hmmm, I like that idea Tony. I've recently found out how to read sprites from the screen in assembler (I hope) and in a final attempt to try to use sprites I was wondering if anyone knows how, once the sprite file is loaded, to locate a sprite's bytes in memory, this most likely to be the system memory; do you use the address the sprite file is loaded at.

I would suggest that you load sprites into your own personal sprite area, rather than trying to use the 'system' sprite area. You can 'initialise' such an area with a Sprite_Op call. (although this doesn't seem to matter in practice). Then you can use all the Sprite_Op calls you can normally - plus some extra ones which only work for these areas. IIRC it is a simple matter of adding either 256 or 512 to the swi call number to get it recognised.
I think there is some call which returns useful information on a sprite (like the address) if you supply the name. Perhaps the 'select sprite' call.
Have a look at the 'OS' StrongHelp manual, and if you can the PRMs.

Another thing, all those of you who have used Fast Sprite, why do I get this 'flickering' line at the top even when using screen banking. If I get past this problem then I think I would use Fast Sprite.

I've seen this occasionally in games and I don't think it is what Jason was talking about. But I don't know the cause I'm afraid.

However, the bank swapping actually occurs at the *next* bank swap, rather than the current, so by the time you've done your vsync it's too late.

Do you mean that the screen bank swap occurs at the next v-sync?

Yup, that's what I meant (it was getting late that evening!)