Sprite files
6 posts, 5 voices
Andrew Hodgkinson (6)
465 posts
|
This topic has been imported from the old forum. Due to its use of fixed format text, you may need to make your browser view wider in order to see posts with the correct layout. |
Alan Robertson (52)
420 posts
|
Like most of the my requests they are mostly related to the look and feel of the desktop rather than functionality, so here goes. If ROOL decide to keep the Sprite file as the method of displaying an application icon in the filer, then it should be updated to handle sprite name of more than 10 characters. I hate having application names limited to 10 character or so, just so a sprite can be assigned to the application. Being far, far more optimistic, 2d/3d vector files would be much better for icons throughout the entire desktop, ala Vista/OSx etc. nx |
|
Andrew Hodgkinson (6)
465 posts
|
Alan Robertson (52) wrote: > Being far, far more optimistic, 2d/3d vector files would be much better > for icons throughout the entire desktop, ala Vista/OSx etc. The bare minimum hardware requirements for Vista/OS X are some way above the fastest RISC OS hardware presently available, so don't expect Aero any time soon :-) It isn't beyond reason to have the Filer understand a !Sprites file that, say, is actually a Zip or Tar file (or other archive). That could hold files using filenames defined in the same way as we currently define sprite names, in the single sprite file system. This gets around the problem of short sprite names for application icons, at least, since the sprite name is irrelevant. Care would be needed for items intended for display elsewhere on the Desktop though. Icons could be defined in various filetypes; someone (e.g. the Wimp) would need to internally cache them in sprite format appropriate to the current colour depth and resolution (including eigenvalues). This means you could use, say, Draw files, though a swift way of rendering those in a dithered, anti-aliased way would be nice and way of creating them with icon conversion in mind (e.g. line alignment to target pixel boundaries, for more on this read about icon design for the BeOS clone "Haiku") would be nicer. Such a scheme implies a development roadmap: * Internal ability to render, at high quality, arbitrary file formats; c.f. ROL's image file rendering mechanism. * Built in read/write image file systems would make a lot of sense, with ideally support for common archive types; some concern over duplication with the likes of SparkFS; is there room for collaboration? * Addition to the Wimp's concept of which sprites it uses and a cache mechanism to deal with conversion from non-native format; perhaps a new scheme rather than the current rather strained numerical suffices related to eigenvalues. * Update the Filer. |
Garry (87)
184 posts
|
While I have no objection to using a vector file format for icons, it's actually a bit of a myth that Mac OS X uses a vector file format for icons, they are in fact bitmap images with an alpha channel, nothing special really. But I do wholeheartedly agree that the sprite format should have an alpha channel like in Select, icons can be made dramatically prettier. The sprite name length is an issue too, if I wrote another app for RISC OS, it would be nice to give it the name I wanted, rather than think about character limits etc. |
Adam (47)
40 posts
|
Alan Robertson (52) wrote: > If ROOL decide to keep the Sprite file as the method of displaying an > application icon in the filer, then it should be updated to handle > sprite name of more than 10 characters. > > I hate having application names limited to 10 character or so, just so a > sprite can be assigned to the application. I don't think there is any such restriction. You can make the application name as long as you like. Just truncate the sprite name - it'll still work :) The only issue might be if some other application just happens to have the same first 10 letters as yours! But presumably the solution to that would be to get the first ten letters allocated to you as well as the whole name. One 10-letter restriction which does spring to mind is the limit in the size of SysLog names (& Wimp_ReportError?). Adam |
Richard Hallas (127)
20 posts
|
Regarding vector icons and transparency etc… When I designed the RISC OS 5 icon set for Castle in 2002, I created them with scalability and the potential use of alpha channels in mind from the outset. Indeed, RISC OS 5 was where high-definition icons (!Sprites11 180dpi sprites) were first introduced, and they were a direct result of the fact that my icons were easy to scale up nicely. In other words, the RISC OS 5 icons are all vector-based already. Admittedly, a handful of them do incorporate bitmap elements as well, but only a small minority (and that need not necessarily be a problem in any case). I had very much hoped, at the time I was doing the work, that RISC OS 5 would inherit the alpha-blending features that were then new to RISC OS Select. Maybe that will still happen eventually. Anyway, the salient points are: 1. If alpha-transparent versions of the RISC OS 5 icons were needed for a future version of RISC OS, then it would be quite straightforward to produce them. They were designed from the outset with that potential in mind. 2. If vector-based versions of the RISC OS 5 icons were needed, then I would expect it to require only a limited amount of work to produce those too, because that’s how the original sources were defined. Castle has the vector sources for the icons (or, at least, most of them). I have them all, of course, and if approached to do further work on my icons, I would be more than happy to help out. Addition of alpha transparency support, at least, is something that I’ve wanted to see ever since I conceived these icons five years ago. Richard Hallas |
