Adding an aiss_GetBitMap() function like this : struct BitMap * bitmap = aiss_GetBitmap( struct aiss * button, ULONG state, struct TagItem * tags )
could have made the library more usefull (as you know Bitmap class can use struct BitMap instead of loading them itself from disk)... if only it was not 68k only (coded in AB3)
it could even be more useable if we could have something like : Class * bitmapClass = aiss_OpenAsBoopsiClass(CONST_STRPTR filename, uint32 x, uint32 y);
where bitmapClass would be a bitmap.class object constructed by the library with all three states
I hope there is no toolbar.library out there yet...
I think such name is not suitable: you are basically focusing on applying dynamically effects on images and not on handling toolbars - I'd say something like imageseffects.library is more appropriate. Sure, your library could be used for images in toolbars, but that's a whole another story: it could also be used, for example, for icons or by applications to apply those effects to their images even for reasons other than GUI. Basically, I think you'd better aim for a general-purpose image processing library (and yes, it is perfectly OK if you start implementing simple, GUI-oriented effects).
As regards toolbars, instead I hope that sooner or later a proper class is added to Reaction.
The idea with this Library was not to "route" the AB3 functionality to the outer world. I don't think that somone would make use of such a library as an image-processing library, unless he codes in Amiblitz and then he doesn't need a library. If you code in C, you don't want to use a 68K Library for main things.
The idea is to complete AISS by having an interface to access the images. Not everybody is firm in laoding and blitting images with alpha channel. There are a lot of glitches if you want to make it work 100% correctly on OS4, MOS and OS3. The library provides scaling and caching, so that two programs won't load the same images 2 times. The images processing is just a gimmik for those who feel they want to manipulate the images. The most important here is to make the selected state easily identifiable, e.g. with a glow effect or a color change with tinting or background., and do the background/foregroudn composing for you like Mason suggested with the Aqua bubble. It really should be something that deals with your GUI images. I think e.g. of a filemanager, that can display the icons scaled to the fontsize next to the filename etc., or has different views like the windoze explorer with different icon sizes.
I know that this is no real magic, but the library can do this for you in high quality and you dont have to fiddle around with datatypes, icons and scaling code.
I never programmed Reaction, so I dont know how to this and I dont know how to write boopsi classes. It will anyway not be accepted unless it is "native". So I think the most flexible is to provide the BitMap that can be used for further processing.
The idea with this Library was not to "route" the AB3 functionality to the outer world. I don't think that somone would make use of such a library as an image-processing library, unless he codes in Amiblitz and then he doesn't need a library. If you code in C, you don't want to use a 68K Library for main things.
The idea is to complete AISS by having an interface to access the images. Not everybody is firm in laoding and blitting images with alpha channel. There are a lot of glitches if you want to make it work 100% correctly on OS4, MOS and OS3. The library provides scaling and caching, so that two programs won't load the same images 2 times. The images processing is just a gimmik for those who feel they want to manipulate the images. The most important here is to make the selected state easily identifiable, e.g. with a glow effect or a color change with tinting or background., and do the background/foregroudn composing for you like Mason suggested with the Aqua bubble. It really should be something that deals with your GUI images. I think e.g. of a filemanager, that can display the icons scaled to the fontsize next to the filename etc., or has different views like the windoze explorer with different icon sizes.
I know that this is no real magic, but the library can do this for you in high quality and you dont have to fiddle around with datatypes, icons and scaling code.
Sorry, in my previous comment I overlooked the caching aspect. Still, your library is naturally not stuck to GUI stuff. Basically, you have: image loading, image processing, image caching. These are general purpose functions that can be used for anything, not just GUI elements. Your idea could implement a nice service for the OS - the more I think of it, the more I'm convinced AmigaOS and its applications would greatly benefit from an easy to use, efficient, flexible way for handling images.
As regards AmiBlitz, well, that's good for a proof of concept / starting up, but in the long run a native solution is certainly desirable.
Quote:
I never programmed Reaction, so I dont know how to this and I dont know how to write boopsi classes. It will anyway not be accepted unless it is "native". So I think the most flexible is to provide the BitMap that can be used for further processing.
Precisely: you provide the layer for images handling (as said, loading, processing, caching), the rest is built on top.
BTW: I did not mean to ask you to make a toolbar Reaction class - that was just a think-aloud request
Dunno, perhaps the composition engine (cairo) of OS4.1 already can do all of the stuff mentioned here. Or at least should be used for something like this.
Yes, an Amiblitz Library would do it for OS3.9 and a proove of concept. OS4 and MOs would have to re-write it if they want it native, but the 68k lib works there are well for a first try. Cairo could surely be used for some speedup of the operations. But the main point is not the image processing thing. The main point should be to make easily nice GFX Buttons available for programs. (nevermind if they use GadTools, MUI, Reaction, Feeling or whatsoever) E.g. you write a little gui for de-compressing or something. If you write everything from scratch, you spend hell more time on coding and debugging the button code than on anything else. Result is usually a GUI with text buttons. That should be different with this lib, when an image button gets nearly as easy as a text button. Or displaying some Icons or images, just for fun or more informative gui, e.g. place a nice, alpha-blended logo in the About requester.
Dunno, perhaps the composition engine (cairo) of OS4.1 already can do all of the stuff mentioned here. Or at least should be used for something like this.
You are right: Cairo could be it (at least from the little I read on Amiga forums).
But the main point is not the image processing thing. The main point should be to make easily nice GFX Buttons available for programs. (nevermind if they use GadTools, MUI, Reaction, Feeling or whatsoever) E.g. you write a little gui for de-compressing or something. If you write everything from scratch, you spend hell more time on coding and debugging the button code than on anything else. Result is usually a GUI with text buttons. That should be different with this lib, when an image button gets nearly as easy as a text button. Or displaying some Icons or images, just for fun or more informative gui, e.g. place a nice, alpha-blended logo in the About requester.
This was already clear. What it is not clear to me is why you think that your library would (need to) be bound to GUI stuff only. Your library basically provides easy access to images. These images can be then used for GUI purposes, but also for anything else (f.ex. the glow effect could be used for an "on-fire" effect applied to a sprite in a game). The bottom line should be that what images are used for is none of the library's business. That's why I originally said that "toolbar.library" would not be suitable - BTW: here's another suggestion: easyimage.library
The idea is to complete AISS by having an interface to access the images. Not everybody is firm in laoding and blitting images with alpha channel.
Of course you don't have to do anything like that yourself in any of the usual AmigaOS GUI systems (ReAction, MUI, Feelin, ...). It would only help in programs not using a GUI system but manually drawing something in a window instead.
Quote:
The library provides scaling and caching, so that two programs won't load the same images 2 times.
At least on AmigaOS 4.x it would only add scaling, and maybe computed effects for the selected and ghosted images instead of loading 3 separate images, but not caching since the intuition #?BitMap(Source|Instance)#? functions used by classes like bitmap.image cache the images and share them between multiple users already.
I see. i didnt know that, since I don't use ReAction and MUI. The initial idea I had was that you load the image with your favourite GUI Toolkit, but add an optional size, and the file will be created on the fly if it doesnt exist. Also the look could be created on the fly, accoding to user-preferences (Background, Gow-Effect, Size, Shadow, Embross/Grey for ghosted etc.)
Like (peudo Code)
LoadBitmap(TBImages:cut24x24);
or
LoadIcon("MyIcon.info",24,16)
would load the icon in the specified (maximum-)size. You, as the application developer dont care about it's actual size. This is very handy for toolbars and everywhere you display Icons, when you want to force them to have uniform sizes. But that would require some kind of Handler or Pipes thing. So I decided to put it into a library. But if MUI and Reaction access the images by themselves, this only has a benefit if you need the resizing and/or effects.
would load the icon in the specified (maximum-)size. You, as the application developer dont care about it's actual size. This is very handy for toolbars and everywhere you display Icons, when you want to force them to have uniform sizes.
On AmigaOS 4.x it would only add the scaling for images, not for icons since icon.library does support scaling icons itself. It's used for example in the new AmigaOS 4.1 Workbench text mode.
Quote:
So I decided to put it into a library. But if MUI and Reaction access the images by themselves, this only has a benefit if you need the resizing and/or effects.
For both it would have to be a BOOPSI image class. Although you can use old style struct Image images as well they have several limits, they are not only at most 8 bit palette mapped ones without alpha but a struct Image is of course only a single image and even if you can add 3 different struct Image images to a button like for example in buton.gadget (BUTTON_RenderImage, BUTTON_SelectImage and BUTTON_DisabledImage) it's still incomplete compared to a single image class image which can have more states, which you could compute from a single source image: IDS_NORMAL IDS_SELECTED /* for selected gadgets */ IDS_DISABLED /* for disabled gadgets */ IDS_BUSY /* for future functionality */ IDS_INDETERMINATE /* for future functionality */ IDS_INACTIVENORMAL /* normal, in inactive window border */ IDS_INACTIVESELECTED /* selected, in inactive border */ IDS_INACTIVEDISABLED /* disabled, in inactive border */ IDS_SELECTEDDISABLED /* disabled and selected */
Using a 32 bit ARGB struct Bitmap returned by your library with the bitmap.image class and the image created by bitmap.image in a button.gadget would make it possible to use true colour images with alpha, but it wouldn't solve the problem of the additional states, bitmap.image is limited to 3 sources for 3 states (BITMAP_BitMap or BITMAP_SourceFile, BITMAP_SelectBitMap or BITMAP_SelectSourceFile and BITMAP_DisabledBitMap or BITMAP_DisabledSourceFile) as well.
Dunno, perhaps the composition engine (cairo) of OS4.1 already can do all of the stuff mentioned here. Or at least should be used for something like this.
It doesn't matter if graphics.library, Cairo or another library like the one proposed here is used for scaling the images, adding computed effects, etc., for a GUI such low level graphics functions are useless, you need an image class which supports these features and can be used as replacement for the current image classes (bitmap.image, etc.). Such an image class can use Cairo or toolbar.library internally, but they can't be used directly in BOOPSI GUIs.
Yes, OS4.1 might have scaling for icons, as well as AfA OS 4.2 does. But what's the use of it if you are an app programmer? Do you want to limit yourself to OS4.1? I don't want to cause a flame war now, but I like my apps run everywhere. (it's a pain that I can't compile for x86 AROS). If OS4.1 would be the majority of people, and if I could run it on my machine, I would say ok. But for now the systems are too wide spread. That's why my library offers a bit mask as well, in case you are using 256 colors or AGA. You don't have fancy alpha effects then, but the program doesn't refuse to work, just looks a little less nice. The code in my library is tested on OS4, MOS and OS3.x (RTG & AGA). I will probably use it to give Buttons to TuiTED, so everybody can enjoy it. That's the way to go, at least for me.
Yes, OS4.1 might have scaling for icons, as well as AfA OS 4.2 does. But what's the use of it if you are an app programmer? Do you want to limit yourself to OS4.1?
AmigaOS 4.x, icon scaling was supported by the AmigaOS 4.0 icon.library already, AmigaOS 4.0 just didn't use it itself yet like the AmigaOS 4.1 workbench does.
Quote:
I don't want to cause a flame war now, but I like my apps run everywhere.
For that you either have to implement everything 4 times, especially the GUI parts (AmigaOS 4.x ReAction, MorphOS MUI4, an AROS GUI for AROS, and either ReAction if you only want to support AmigaOS 3.5+, but still different to the AmigaOS 4.x ReAction GUI because of missing features and bugs in the old AmigaOS 3.5/3.9 classes, or even something completely different for AmigaOS 3.0+), or you only use the common AmigaOS 3.1 API and it's crap everywhere (gadtools GUI, no support for charsets other than ISO-8859-1, no mouse wheel support, etc.).
Yes, I know. I'd love to run OS4.1, but I can't (we dont want to discuss the details in this thread, I guess). Still waiting for better days. Till then, I am stuck with the greatest common divisor, and that's the OS3.1 API "pimped" up with a picture.datatype V43 and AHI.
Therefore, I have to implement things often twice, or find an elegant way that works everywhere. As GUI Toolkit, I implemented "TUI". It works on OS4 and MOS too, and it has Alpha transaprent buttons. E.g. HD-Rec uses that, as well as most other progs from me.
more styles will be added. So the App programmer can the user select the style. There is still the "lowlevel" interface to manipulate the images individually, but they can't be cached and it is much more work...
I am surprised how seemless you can mix icons and AISS images. The icons are much larger in their original size (46x46).
I improved the zoom quality (no false-shadows at the borders), and now most of the images look like as if painted at this resolution. Try to compare this with a usual scaling algorithm in your favourite GFX program, it will screw up.
The largest aqua bubble in the example uses 46x46 icons. The bubble sizes are automatically adjusted to the "en-bubbled" image. The aqua bubble image itself is 64x64 bitmap and zoomed to the needed size. Doesn't need to be an aqua bubble though, any background/forground can be used.
The very small images (e.g. 14x14) could operate as listview images, while the medium ones (e.g. 24x24) can be toolbar images of large toolbars. If your toolbar has only a couple of buttons, the icons' size (e.g. 36x36) would be nice.
Only downscaling works well, of course. upscaling gets either blurry or blocky. One could think about another algorithm, like X2, but downscaling is usually easier since destroying information is easier than creating. That's why it would be cool to have the AISS images larger. downscaling can be always performed.
Maybe Mason could provide a test-image in 48x48 and 24x24, and we can compare the manual drawing 24x24 and zooming from the 48x48.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
