Trouble with app icons
Chris Mahoney (1684) 2165 posts |
Hi, me again :) After what seems like years of messing around, I’m finally almost ready to release my first app on an unsuspecting world. However, I’m having trouble with icons. I have a “master” PNG file, and I’ve successfully created a 34×34 icon for the !Sprites22 file by using ChangeFSI. It appears to function correctly. My problems are with the other two sizes. If I create a 68×68 !Sprites11 icon with ChangeFSI then it ends up saved at 90 DPI and appears twice as large as it’s supposed to. I can’t figure out how to change it to 180. Paint doesn’t appear to let you change the DPI of an existing sprite. I’ve also tried PhotoDesk (3.12), which provides an option to change it, but when I save the file it’s back at 90. How can I either change an existing sprite to 180, or force ChangeFSI or another PNG-to-sprite converter to output at 180? The other minor problem is the 34×17 sprite. I can create this one by dropping the 34×34 PNG onto ChangeFSI and telling it to export using mode 15 (this is the same mode used by the MinApp and Hyper example apps). The resulting icon looks correct in Paint, but results in a generic “APP” icon when viewed in Filer in OS 3.1 (under ArcEm). That’s not a huge issue, but if there’s an easy fix to get the icon showing up correctly under 3.1 then I’m listening :) Chris |
Chris (121) 472 posts |
There may be a much better way to do this, but here’s one method that I’ve used: 1. Design your app sprite as a 68×68, 90dpi version (ie twice as big as it should be). You should now have a 180dpi sprite at the right size and resolution. Be aware that Paint has a nasty bug affecting the brush tool, so save your work at Step 2 to avoid losing everything if it crashes :) As for the 34×17 case, the example you’ve given should work. Is the sprite saved within the spritefile with the correct !appname (IIRC, ChangeFSI gives it a generic name)? |
Chris Mahoney (1684) 2165 posts |
Thanks, that sounds like it’ll work :) I’ll double-check the sprite name when I get home. |
Chris Mahoney (1684) 2165 posts |
It did indeed work; I now have a nice 68×68 sprite that appears at the correct size. Thanks again. No luck with the 34×17 sprite under 3.1, but I’m not too worried about that. Edit: Never mind! I figured it out! I was under the mistaken belief that 3.1 would always use the !Sprites file, which is not the case. The mode that I was in was trying to use the !Sprites22 file, but the icon in there was only compatible with 3.5 and later. I’ve changed !Sprites22 to use an old mode (21) and it’s all working now :) |
Sprow (202) 1158 posts |
ChangeFSI can do it. There’s not currently a clicky icon to do so from the ‘Sprite output’ menu, but it is described in the documentation (CmdBasUse) – we read that, right? For example *ChangeFSI MyInputImage !Sprites11 S32,180,180would convert MyInputImage into a 16M colour 180dpi sprite. |
Chris Mahoney (1684) 2165 posts |
I did at least read the printed manual from 3.7 :) Thanks for the tip; it could be useful for next time. |
Chris (121) 472 posts |
Sorry to pull this thread up again, but a quick related question: I have a file with sprites defined in Mode 20 with 16-colour greyscale palettes. I’d like to convert them to 180dpi versions for a Sprites11 file. I’ve taken a look at ChangeFSI, but unless I’m missing something it looks like the command line usage only permits specifying dpi for >256 colour sprites. To be clear, the original files have the correct x and y number of pixels, and all that’s needed is to change the dpi so that they’ll look correct at EX0,EY0 screen modes. The reason I created them at 90dpi in the first place (ie twice as big) is that they’re based on bitmap exports from ArtWorks, which AFAICS only exports them at 90dpi resolution. I can of course go through them using the brush sprite method outlined above, but it’s cumbersome for a large file and I’m hoping there’s a better method. One day, it would nice to be able to perform this operation within Paint – I’m hoping the bounty work will implement this :) |
Sprow (202) 1158 posts |
That’s right, 15bpp (“S16,x,y”) and 32bpp (“S32,x,y”) only. I don’t believe there’s any fundamental reason for that limitation as internally they’re just passed through as pixels, but there’s no parser to decode other switches and no output writer to create the appropriate sprite header. I do have it on my (very long) list of things I might do to add the extra output format options to ChangeFSI. In the meantime if you have a lot to do you could just switch into the 16 greys EX0 EY0 mode and use some OS_SpriteOps to get what you want. |