Integration OS3.1.4/3.9

[gulliver]

Originally Posted by kolla

Right, and now you are saying this is also the case for OS components distributed with OS4, which is a bit news worthy IMO.

If my guesses are news worthy, then everything is news worthy.

[kolla]

Originally Posted by gulliver

If my guesses are news worthy, then everything is news worthy.

You were not guessing, you wrote that you know this to be the case.

What I can tell you that I know of, is that unfortunately some licenses are tied to a particular platform/processor.

[gulliver]

Well you are certainly taking things totally out of context.

Everything is guesswork, except that I know for a fact that some third party software was included in AmigaOS (68k) and that it was bound by specific contracts which limited the licensee.

I gave you the example of Say, which is rather obvious, as that company (cant remember the name right now) would probably have not liked if for example CBM compited using their own IP on other platforms they already had products in. Something that is quite obvious.

I dont know a single thing about OS4 development: I never developed for it, never saw the sources, never even beta tested it, in any form or shape.

I am just another Amiga (68k) user GUESSING into why things are like they are.

[kolla]

Context was "why can Hyperion not include IconEdit of OS 3.9/4.0 in OS 3.1.4", and though you say you don't know anything about licenses of IconEdit, you know that there are licenses that are tied to platform/architecture. Context is AmigaOS, so what else than OS4 vs OS3, PPC vs 68k, can you mean? Anyways, I get now that that you don't know, so let it be at that.

[orphan264]

*sigh*

Another conversation de-railed.

[PeterK]

Originally Posted by gulliver

Yes, we definately need an IconEditor for all icon types.

It is a pitty there are good candidates, but yet we have no final solution.

BTW, the other day, I made a couple of good looking glowicons thanks to your IconLib project:

I started with PNG images, resized and color reduced them, then converted them to glowicons with your library, and then finally added the finsihing touches with IconEdit from 3.9.

Thank you for your continued work on IconLib!

One of the biggest problems of the OS 3.9 IconEdit is that it cannot display the real RGB colors on a TrueColor screen, it always maps them to the screens 256 color palette. So you never know how your icon will finally look after saving. Another problem is that the number of colors of the icons palette cannot be increased in case you need more colors and a large palette is not even displayed completely. And IconEdit has so many other bugs, but I'm not an icon designer, thus it doesn't bother me much.

Anyway, your icons are nice. Just don't put them on a white background, because ColorIcons have no alpha channel.

Btw, my work on icon.library was discontinued on the last two months and I don't have any specific plans for the future. Sometimes I'm trying this or that but there was nothing new satisfying me that could make it into another update.

[gulliver]

@PeterK

The background was temporarily set to white just to display them for the snapshot. ;-)
I use a textured tiled pattern for my workbench windows.

Yes, I noticed that limitation of 256 colors when I had to color reduce the PNG images. Sometimes I ran out of colors, so I had to plan before hand, and swap them wisely.

But I have to agree that IconEdit from 3.9 is not ideal either.

I also did some of the default 4 color icons for AmigaOS 3.1.4. In that case, I used the old icon editor from 3.1. I modified a few existing ones and created a few others from scratch. And some others were team work between a developer/tester and me.

Seems nobody cared or even noticed them.

Your icon.library has reached a point in maturity that I understand it is hard to think on planning things for its future. I can suggest you to support (if you are in the mood, of course) of some vector icon format. I believe MorphOS has recently added vector icons (SVG) to MOS 3.10.

[PeterK]

There was already somebody a few years ago asking me for vector icon support, or was it you, I don't remember who. It needs a lot of additional code and I have no knowledge and experience with vector graphics. What I don't want is to port and compile a large support library from other PC sources and add that to my code. I would need highly optimized assembler functions for the Amiga OS 3.x and all its screenmodes, not only for RTG, and I don't expect to find any code like that.

And then there is also the question about who needs to exist first, the hen or the egg, iconsets in a vector icon format with tooltypes or an icon.library to support them ??

[gulliver]

Yes, it was me. :-)

Anyway, you are right, there is no sense in adding a lot of additional code. And yes, it is a chicken-egg situation.

I am just sad to see you finishing the IconLib project for good. I believe your talent must be put to use for the amiga again, because if we get half the things you did with your IconLib somewhere else, then we all benefit.

Have you thought about embarking in another epic Amiga coding journey? :-)

[kolla]

Anyone know of a tool to read/change/set the palette for a "color icon" format icon? I am still on the quest of mass-converting old NewIcon style icons to good looking monochrome icons, by setting all "fill" colours to white, and contour colours to black

@PeterK
Maybe you can release icon.library 46.4 Final Edition?
Thanks for all the great work and time you have put into this.

Edit: I thought this was the IconLib thread, sorry for OT.

[PeterK]

Sorry for being OT again.

Originally Posted by gulliver

Have you thought about embarking in another epic Amiga coding journey? :-)

Yes, I'm sometimes thinking about starting a new project, but couldn't find anything interesting that makes more fun than causing headaches, because I'm not the fittest anymore, 3 hours coding a week would be the limit.

@kolla
No, I don't know a tool for that purpose. In the autodocs you can find functions explained like:

GetImageMask1/2, Get/SetTransparentColor1/2, Get/SetPalette1/2, Get/SetPaletteSize1/2, Get/SetImageData1/2

... but you certainly also need some sort of edge detection, which is only included in good image processing programs.

The problem with the "final version" is that always on the next day after releasing it someone sends you a bug report and you have to make another update. I'm already waiting for 7 weeks now and nobody has complained after 1400 downloads yet, but I don't dare to finish it.