Minimenu Art Repository


DaveC

Internal Development
Joined
Mar 4, 2004
Messages
9,208
Here is a post where icons for Minimenu launcher can go. Anyone wanting to make these the built-in preview pic in the PND feel free to use. Otherwise users can use these as override images.

I will post mine here as they get finished. Just grab and re-name.
Menu Example:
minimenu0007.png


Icons will be 60 x 60 px, previews are 285 x 180 px. These will fill the space unscaled.

Preview pics: (go in large box to right)

picodrivepvw0.png


snes.png


uaepvw0.png


hatari131dpvw0.png


c64.png


atari2600.png


atari7800prev.png


psxw.png






ICONS:
AtariST
atarist.png


Amiga
amigaicon.png
 

Attachments

  • minimenu0007.png
    minimenu0007.png
    278.3 KB · Views: 102
  • picodrivepvw0.png
    picodrivepvw0.png
    52.6 KB · Views: 115
  • snes.png
    snes.png
    55 KB · Views: 99
Nice Icons and info-Pix, Dave. :)
BUT I think they are way to large from the file Size. If we have hundreds of them, I think we should make them smaller than 55kB. I prefer graphics as small and effective as possible. Loads faster and don't need to many SD Space.
I think 8-Bit PNG is fine too. Here, Same Pic but only 19kB.
unbenannt1lf.png


And your Amiga-Icon has 64 Bits/Pixel! :blink: Heavy. :D
 
fusion_power said:
Nice Icons and info-Pix, Dave. :)
BUT I think they are way to large from the file Size. If we have hundreds of them, I think we should make them smaller than 55kB. I prefer graphics as small and effective as possible. Loads faster and don't need to many SD Space.
I think 8-Bit PNG is fine too. Here, Same Pic but only 19kB.
unbenannt1lf.png


And your Amiga-Icon has 64 Bits/Pixel! :blink: Heavy. :D
Great, thanks! Now I can finally use my 100 kiB SD card!

But seriously though, trust me when I say that PNG sizes won't be a problem; no need for drastic recompression measures.

Also, I might contribute with some previewpics and icons myself, because I'm no fan of photo-like icons and blue gradients ;) (disclaimer: personal opinion of course)
 
Last edited by a moderator:
dflemstr said:
Great, thanks! Now I can finally use my 100 kiB SD card!

But seriously though, trust me when I say that PNG sizes won't be a problem; no need for drastic recompression measures.

Also, I might contribute with some previewpics and icons myself, because I'm no fan of photo-like icons and blue gradients ;) (disclaimer: personal opinion of course)
Don't compromise. Optimize! ;)
I also know Homebrew projects that still use uncompressed .BMP and .WAV files. :lol:
 
Last edited by a moderator:
fusion_power said:
Don't compromise. Optimize! ;)
You're right! Let's not compromize and recompress the pictures, let's optimize instead an dinvent a completely new image format ;)

BTW: the AppStore, mmenu, pmenu, etc, all use different prviewpic sizes... I wonder what we should use as the defualt size? Or is only the aspect ratio important?
 
Last edited by a moderator:
I think the _skins_ are what care; mmenu doesn't care, and probably pmenu as well. mmenu can be configured to scale-up (or leave floating centered), and will always scale-down to fit the specified cell (to avoid madness).. but really doesn't care or enforce too much.

Given that people can go skin-happy and make for giant or tiny preview areas, is there much we can do? (Or can we expect skinners to stick to a 'preview spec')?

Palm (and old Mac OS) did an interesting trick where you have a virtual file ("family"), and based on needs, the 'best choice' would be used. ie: You'd say "preview pic 1", which in fact woudl be any number of files and the lib woudl be responsible foer finding best-fit. I don't see us going that route, but given any number of previews can be included in a pnd-file or pxml-app-dir, it coudl be lkeft up to the consuming app to fin the best match in the same way. (mmenu, being quickly made, just uses the first preview pic ifd present, and ignores subsequent.)

(and mmenu makes override preview pics just as easy as overriding icons and everything else; just name the file right and poof, the override is used.)

jeff
 
MDave said:
It be cool if .pvr images were used :) if only to minimize the overhead of loading PNG images, uncompressing them etc.
skeezix uses SDL + SDL_image so pvr can't be used (→ the format can only be used via OpenGL afaik?)

And if you want optimizations like that, well... are you sure you want to be using a GUI at all? Because decompressing PNG files isn't a heavy operation; switching tabs in the actual application a couple of times will add up to about the same overhead, so by your reasoning you definitely shouldn't switch tabs ever, that would be too much overhead! ;)
 
Last edited by a moderator:
skeezix said:
Given that people can go skin-happy and make for giant or tiny preview areas, is there much we can do? (Or can we expect skinners to stick to a 'preview spec')?

(and mmenu makes override preview pics just as easy as overriding icons and everything else; just name the file right and poof, the override is used.)

jeff

Well the "preview spec" for Minimenu is 285 x 180. If someone is going to make pics just for this it would be best to use this resolution to avoid some ugly scaling artifacts.


@ Fusion I will look at reducing the bitplanes, I just saved the pictures I didn't know the spec varies so much. I did look at you example pic and the reduction in quality is a little noticeable to me but not too bad. I will see how it looks with the others.
 
Last edited by a moderator:
dflemstr said:
MDave said:
It be cool if .pvr images were used :) if only to minimize the overhead of loading PNG images, uncompressing them etc.
skeezix uses SDL + SDL_image so pvr can't be used (→ the format can only be used via OpenGL afaik?)

And if you want optimizations like that, well... are you sure you want to be using a GUI at all? Because decompressing PNG files isn't a heavy operation; switching tabs in the actual application a couple of times will add up to about the same overhead, so by your reasoning you definitely shouldn't switch tabs ever, that would be too much overhead! ;)

Well, I thought it was called minimal :D and speed is the main attraction here! Where everything just happens near instant. Snappy. No fuss. Would be nice though!

I wouldn't mind using no GUI, I'd have to run things the old fashioned way like when I had my first ever computer that had DOS on it! Now that's nostalgic to me. Could that be made a boot option? Just a terminal? :D Going off-topic now ...

If that image format can't be used with the current setup, how about something like zipped up TGA images? They actually compress better then PNG's when in zip files, and have low overhead loading the image format. TGA is just as easy to edit as PNG, supports the same pixel formats as PNG including 8-bit images.

I know this from working with Quake 3 :) Made quite a difference. Though I guess that's because there's a multitude more images to load then there would be menu graphics :p Unless there is a lot of PND's to load ...
 
Last edited by a moderator:
DaveC said:
@ Fusion I will look at reducing the bitplanes, I just saved the pictures I didn't know the spec varies so much. I did look at you example pic and the reduction in quality is a little noticeable to me but not too bad. I will see how it looks with the others.
Without smooth gradients in the Background, nobody should see the difference. I would be also happy with less colours but only for you I kept 256 colours for the best look. ;)

Uh, why is the Image format actualy 285 x 180? this is not a multiplier of 8 like it always should be for computer graphics and resolutions (IMHO) 256x128 for Example. or do you need these values because the preview-frame itself has the right size for a multiplier of 8?
 
Last edited by a moderator:
mdave -- I had about a week or two to write the thing, so I fell back to SDL pretty quick -- works with and without X, and makes things trivial. I certainly did not want to get into an GLES app with such a timeframe,. and more to point -- you then depend on the driver for GLES to work, and I figured it woudl be safer to _not_ go there :) minimenu should work fast, do the job, use zero RAM,and work most anytime, so SDL is win.

Really, I may switch it to /dev/fb so it runs a bit faster (in non-VRAM modes) and has zero dependancies, but using the TTF font lib in SDL is pretty convenient.. makes you lazy :)

jeff
 
fusion_power said:
Uh, why is the Image format actualy 285 x 180? this is not a multiplier of 8 like it always should be for computer graphics and resolutions (IMHO) 256x128 for Example. or do you need these values because the preview-frame itself has the right size for a multiplier of 8?

I noticed that my program is set to 8 bit PNG, not sure how it ended up to be more.

285 x 180? it is just what will fit. 256 is too small and 320 would be too big. The 180 came from the ratio that matches Pandora screen (Pandora specific stuff). It is not like this is an emu screen where we will be running games from it. It will just contain art to depict the systems or some game screens etc.

More previews added (although not for dflemstr, they have photo realism and blue gradients :p )
 
Last edited by a moderator:
Bump.

Now that some Pandoras are in the wild maybe you could use these pics I made for icons and preview pics.

Many before didn't need them but now maybe they are more useful.
 
Back
Top