Just some icons

Very nice!
You can try reducing the icon size by simplifying the paths, aligning the vertices on the grid, and reusing paths and shapes; your beautiful design could benefit from this in terms of size, probably it’s just too many details, so you could try removing some of them; but I guess staying under the kilobyte is more of a style exercise than a real need, so probably there is no need of what I wrote above


I create a icon of Giana Sisters Return from retroguru past hermes was port, but no one port the game to haiku.



Thank you!

Ok, I think I’ll relax a bit then :slight_smile:
Too much time already spent on this one, trying to keep it faithful to the original sprite!
One thing i miss a lot in Icon-O-Matic is a column inside each palette that showed the “cost” in bytes of each path, shape or style, and the resulting total below the icon previews. That will be really useful when deciding if its best to do things one way or another, because, as it is now, one needs to export to hvif a lot of times just to keep checking the size in Tracker.

Yeah, really sad that it didn’t ended up ported as well, to me Haiku makes a perfect home for this classic games.

1 Like

I think the problem is that it’s closed source, no matter who ported it, he wasn’t allowed to give out the source. But it would be nice to see the game on haiku. Hermes also cuts a good figure, for years :slight_smile:

The original Great Giana Sisters was easy to beat. Giana Sisters Return is much more difficult. After I got to the desert levels on my MorphOS box I got sick of it and quit playing.

Nice, if you are ready would you be willing to share it? :slight_smile:


Yes, of course!

I uploaded to Haikuports a few more icons I had already finished.
Also that Furnace icon I showed two or three months ago :sweat_smile:

WIP icons

And given that dealing with github, commits, forks and all that makes my head hurt and to drag my feet like a sloth, because it is… not exactly my forte (gross understatement), I tried to get my feet wet and also created some (maybe incomplete?) resource files and made some (surely also incomplete?) changes to recipes, though I think nothing deal breaking.
I hope I can finally see my Dukto icon appear in the depot!

I visualize whoever will be reviewing my ridiculous commits pulling out his hair right now, because my ears are starting to ring like mad.


There are some issues on HaikuPorts about packages needing icons, too:

1 Like

Well, fitting the icon in the “inode” (that’s where the file name, permissions, etc of the file are stored) does make things faster. For one single icon on a single file it may not be very noticeable, but if all app icons are large and don’t fit there, it results in a lot more disk reads than would be needed.

But besides that, I think this icon has a lot of details, which may not work so great at 32x32 or 16x16 sizes (IconOMatic shows you previews at those sizes). If I were to draw an icon like this I would probably do just the helmet, or just the sword and shield. But then, that’s just my opinion and I don’t draw this, so, do as you want, probably nobody will really worry about either the size or how the icon looks at 16x16px in the Deskbar anyway.

1 Like

With 4k blocks it makes more space for inode data actually.


Well, I do worry about that :triumph: :slightly_smiling_face:
Don’t be afraid, I go to great lenghts to ensure that the icons look good at every size, saving frequently, making constant checks in Tracker at every size available, and doing good use of the wonderful Max/Min LODs capabilities in Icon-O-Matic.

Icon-O-Matic previews

I must admit, though, that I got a bit carried away with the details on this one, but this character has such an iconic and recognisable shape at small sizes that this convinced me to keep going this route instead of something more abstract.

BeFS blocksize

Yes, but when installing Haiku the formatting defaults to 2k, and most people wouln’t even think touching this, so I think is preferable to keep doing icons with this in mind.
It’s good to know, thoug, thanks :slightly_smiling_face:
Oh BTW, what will be the icon data space available inside the inode for every one of this block sizes?
Is there a hard limit, or is it depending on the number of other things that need to be put there?
I have this nebulous concept that the limit is at around 1 to 1,5Kb, but can’t remember where I read this, the three articles I have bookmarked (“Icon guidelines”, “Why Haiku icons are so small” and “Icon facts”) don’t mention it clearly.
And, just out of curiosity, what happens when the icon data is too big to fit, where does it go? :thinking:

1 Like

Maybe zuMi can help you with that if you give the icons free on GitHub?

I thought we planned to change this based on heuristics, but it didn’t happen. I couldn’t find a bug report about this also.

1 Like

I use http://0x0.st/o0V-.iom to start with my icons, it’s a circle perfectly aligned with the grid so it weights a little less than the standard one, plus it’s in translucent black that can be reused for the shadow style

Furthermore icons require to have enough room for the outline, one for LOD <=0.375 and one for LOD >0.375, so I suggest to fit the design into a 30*30 square.

1 Like

I take advantage of this thread, the use of the LOD allows you to optimize icons for low resolutions, but the current design of IOM does not allow you to see what is being done, it would be necessary that the editing view does not processes this information, and apply this only to the previews;

Perhaps I’m going to express a controversial opinion, I think it would be nice to be able to have a second icon BEOS:MINI_ICON with a simplified design only for resolutions <24px, I believe that in this case we should renounce the axonometric projection and drawing the icon with a flat design.


The download link doesn’t work, but I tried it directly and the resulting circle is indistinguishable from the default one. Just this detail made the resulting hvif 8 bytes smaller.

The boundary for the outline is something I learnt the hard way, after having to shrink more than one icon in a fairly advanced state, with the corresponding loss in sharpness, and then having to modify a lot of the paths to regain it.
Oh, how I would have liked to find posts like yours before!
Thank you for them!

1 Like

Really odd. I’ll try again, zipped this time

(Tried downloading it from Web+, also from Chrome in my Mac just to check, and it still didn’t work, but tried with Falkon and it downloaded just fine. Go figure.)

Now I can see that you also had the circle itself slightly bigger, aligned with the 32px grid.
In my tests from yesterday I just took the default circle path and aligned only the control handlers, that were pretty close to a 64px grid point:

… instead, by transforming the circle path to make the radius grow one pixel in the 32px grid as you do, the handlers that need to be aligned are already practically touching a grid point:

Good point! (pun intended!)

Even with the resulting hvif weighting the same either way, this way achieves an even more perfect virtually perfect circle.

You have given the drawing nerd in me a moment of joy :smiling_face_with_tear:

1 Like

Yes, that’s inconvenient, I think it will be great to have a row of previews of all the various sizes used throughout the system, not just three, at the top or bottom of the editing view, that also acted as toggles to select the resolution you need to see to work on in the editing area.