I wonder if someone can clarify for me the "correct" use of different
resolution sprites. (Or alternatively point me at some relevant
documentation) Starting with the application sprite. I believe you can
provide some or all of:
- !Sprites (mode 15?)
- !Sprites22 (mode 20?)
- !Sprites23 (what mode?)
- !Sprites11 (defined as what?)
(From RO4 onwards you can use 256 colour sprites - so what "mode" should
they be?) The OS decides which file to use when you do a standard
"IconSprites !Sprites" call.
Moving on to loading your own sprites for your own sprite icons in your
own windows, how does this work? Are all the different sprites the same
"physical" size despite the mode/dpi? Or do the icon sizes need
adjusting? What should you test for before deciding to load
Sprites22/11/xx? Should you free and reload the sprites on a mode
Thanks a lot for any insights!
Adam Richardson Carpe Diem
> I wonder if someone can clarify for me the "correct" use of different
> resolution sprites. (Or alternatively point me at some relevant
> documentation) Starting with the application sprite. I believe you can
> provide some or all of:
> - !Sprites (mode 15?)
> - !Sprites22 (mode 20?)
> - !Sprites23 (what mode?)
> - !Sprites11 (defined as what?)
> (From RO4 onwards you can use 256 colour sprites - so what "mode" should
> they be?) The OS decides which file to use when you do a standard
> "IconSprites !Sprites" call.
dpi 16cols 256cols 32K/16M
!Sprites 90x45 12 15 new format
!Sprites22 90x90 20 or 27 21 or 28 new format
!Sprites23 (obsolete hi res mono mode 23)
!Sprites11 180x180 new format new format new format
Use the above mode numbers, or the new sprite format at the given dpi
and colour depths. Don't use alpha format for non Select only
And Stricly speaking if you use 256cols sprites, whether
they are for the Filer (in !Spritesxx) or internal
to your application (in Sprites usually), always give them
a palette even if it's the standard one, cause there
is a bug pre-RO4 versions of the sprite redrawing
which tends to overwrite memory locations of other modules
and leed to sudden machine freeze or 'Filecore in use'
kind of error.
Thanks druck, that answers some of my questions. Presumably the
different resolutions need different sizes too.
When it comes to choosing what type sprites to load from inside your
program (and presumably when the mode changes), what test should you?
> When it comes to choosing what type sprites to load from inside your
> program (and presumably when the mode changes), what test should you?
Apparently Wimp_ReadSysInfo with r0=2 returns the sprite suffix.
Hmm, I just tried that here (RO 4.39) and for my normal mode
(1280x800x16M) I got "22" but for modes 12 and 15 I got "24"! What
mode/resolution would I try to get one of the 180dpi modes? How does the
screen size relate to the dpi in the sprites?
Playing with the E values in the mode string gave me even more confusing
results. My normal mode, but with E2s gave 44 and the same with E0s
>Hmm, I just tried that here (RO 4.39) and for my normal mode
>(1280x800x16M) I got "22" but for modes 12 and 15 I got "24"! What
>mode/resolution would I try to get one of the 180dpi modes? How does the
>screen size relate to the dpi in the sprites?
From memory, !Sprites and !Sprites24 are equivalent. The second digit
refers (IIRC) to the number of OS units per pixel on the y axis. The
first is the number per pixel on the x axis.
I think the logic goes: if there is a suffix with the right values for
the mode, then use that. If not, the use !Sprites. By tradition,
!Sprites is therefore the lowest denominator (i.e. Mode 12/15).
>Playing with the E values in the mode string gave me even more confusing
>results. My normal mode, but with E2s gave 44 and the same with E0s
I've not had a play with this, but isn't it what you'd expect?
Presumably E1s give you a '22' suffix?
The Eigen factor works as follows (I think):
E0 1 OS unit = 1 pixel
E1 2 OS units = 1 pixel
E2 4 OS units = 1 pixel
Happy to be corrected by anyone who actually knows what they're
Well, not really - but only because I'm pretty clueless! ;) It's all
becomming clearer now though. So could druck's table be extended:
SWI Returns EXEY
Sprites n/a 12
Sprites22 22 11
Sprites11 11 00
n/a 44 22
> From memory, !Sprites and !Sprites24 are equivalent. The second digit
> refers (IIRC) to the number of OS units per pixel on the y axis. The
> first is the number per pixel on the x axis.
Astounding! For years I have wondered what the relation between the
spritefile suffix and their meaning was, thinking it had to do with
screen mode numbers (!Sprites22 for screen mode 22 etc).
Now suddenly all is revealed!
Can anyone clarify what the size in pixels for icon bar icons should be
for each type of !Sprites file?
And is there a description somewhere of which !Sprites files should be
supplied with an application to make it look good under all
circumstances? (The Style Guide is a bit out of date, as far as I know.)
Erik G http://www.xs4all.nl/~erikgrnh
== 'From:' address is a spam trap. Do not use
== See web site for email address
Theo added druck's table to the riscos.info wiki, and I added what I /
think/ should be the icon dimensions.
I thought that too. But Sprites23 is rather out of place as far as this
numbering scheme goes. But it was intended for mode 23 (high-res 1bpp mode).
And mode 22 /was/ a high resolution mode (was it 320x256 in a 640x512
multisync mode?) introduced for visually impaired people, which would have
benefited from high-res sprites.
Interestingly googling my own website (!) tells me that Arthur had a mode 22
which was a high-res mono mode, but it was removed in RISC OS 2. I'd
imagine the resolution would be more like mode 23 (1152x896) which is a
cunning ploy that sends each 4bpp VIDC pixel as four 1bpp pixels - the gory
details of how it works is here:
So I suspect it was originally based on screen mode and then 'retrofitted'
to be the eigenvalues of the transformation. Though from this post (which
mentions Sprites24) it sounds like it was retrofitted in 1991:
Normal icon sizes for 90x45dpi be 34x17 rather than 34x16. You might
also want to mention small icons, of 17x9, 17x17 and 34x34.
Then theres the recommendation to use full 256 colour palleted format,
rather than the old VIDC 256 colour numbered modes, for all !Sprites22
and !Sprites11 (not !Sprites as thats only likely to be used on very
old machines). This gives the best trade off between number of colours
and data size, with some degree of backwards for machines which dont
support 32K or 16M icons, or use in 256 colour or less modes.
> I think the logic goes: if there is a suffix with the right values for
> the mode, then use that. If not, the use !Sprites. By tradition,
> !Sprites is therefore the lowest denominator (i.e. Mode 12/15).
Having had a think about this... if this were the logic used, then in a
180x180dpi mode, wouldn't an application without a !Sprites11 file end up
having its Mode 12/15 sprites used, even if it did have a !Sprites22 file?
Is this actually what happens? (Sorry I'm not in a position to check...)
No, Sprites22 is always used in preference for any other square pixel
modes, only falling back to !Sprites if its a rectangular pixel mode,
or there is no other sprites files.
If 180x180dpi use !Sprites11
If square pixels use !Sprites22
Else (rectangular pixels) default to !Sprites
I've left out any mention of !Sprites23 and mode 23, as I don't know
if its in any post RISC OS 3 OS.
Just to complicate or is it simplify matters, you can just use a
!Sprites file for your square pixel sprites and not provide a
!Sprites22. In the vanishingly unlikely occurance someone actually
uses a rectangular pixel mode the Wimp will automatically scale the
sprites. They wont look as good as hand designed ones, but who will
actually waste time making them these days anyway, you'll just use
a program to scale.