Best way to manage alot of icons

[Toadcop]

I want to know what would be the best practise to load/load off (?) dynamicly alot of different icons. for example i have a game in which i have thousands of icons (for items, spell w/e) and i want to load them only if i need to. the first problem is imageset as i understand it's a layer between image and cegui ? so if i would create icons separately i would need a imageset for every icon ? wouldn't it be "slow" and overhead in memory ?
so i am searching for efficient way for handling alot of image data in CEGUI. (coulnd't find something similar)
and the second question is about placing the images http://www.cegui.org.uk/wiki/index.php/ ... ageButtons it also seems to be kind a overhead O_O isnt there any "generic widget" in which i could just change the "image" and "it's done" ? i don't know much about CEGUI but "if it's so", it's a huge backdraw of CEGUI system.

useful links are appreciated.

[Jamarr]

I want to know what would be the best practise to load/load off (?) dynamicly alot of different icons. for example i have a game in which i have thousands of icons (for items, spell w/e) and i want to load them only if i need to.

This does not really pertain to CEGUI. Anyway, why not just use an icon-manager that manages icons based on how often they need to be rendered? Keep the icons that are rendered often in memory and load the others as-needed from disk, unload icons that are no longer referenced. Determine the number of icons you can afford to keep in memory using some heuristics (available memory, hd access speeds, etc).

the first problem is imageset as i understand it's a layer between image and cegui ? so if i would create icons separately i would need a imageset for every icon ? wouldn't it be "slow" and overhead in memory ? so i am searching for efficient way for handling alot of image data in CEGUI. (coulnd't find something similar)

You would not need to have a separate Imageset for every icon. That is your decision to make as an end-user; use what fits your needs.

The purpose of Imagesets is to improve texture performance by improving locality of images; ie to decrease texture switching, loading/off-loading data from the gfx card, etc. Think of it like reducing cache-misses but for imagery. If instead you define Imagesets which only hold a single-image, then you are defeating their purpose; and so yes, in that case, you may be introducing extra overhead. Would it be slow? That depends on the application.

Kulik has created a utility specifically for amalgimating images and generating a .imageset file for the collection. If you group your icons wisely, this could significantly improve your performance.

If on the other hand you want to maintain separate image data for each icon, or just want to avoid Imagesets, I would suggest looking into RTT (Render To Texture) techniques so that you can render whatever you want onto the texture associated with a window. You still need to define a single Imageset/Image for each rendered icon-area, but no more. There are already many, many threads on this in these forums.

Or you could probably go even further and implement your own window-renderer that bypasses Imagesets entirely.

and the second question is about placing the images http://www.cegui.org.uk/wiki/index.php/ ... ageButtons it also seems to be kind a overhead O_O isnt there any "generic widget" in which i could just change the "image" and "it's done" ?

Where did you search, and what did you search for, to only turn up ImageButtons? Have you looked at CEGUI::StaticImage? You can also define your own light-weight widgets fairly easily. Such topics already exist on this forum and elsewhere.

i don't know much about CEGUI but "if it's so", it's a huge backdraw of CEGUI system.

code is code. a library cannot accommodate everyone all of the time. and for a free, open-source library this is a pretty good one. sometimes you have to get your hands dirty

useful links are appreciated.

Unfortunately I do not have very many links for these topics off hand. However, I do know that if you take the time to search the available resources you can find information on everything I have mentioned.

[Kulik]

Also, CEGUI 0.8 gets rid of the Imageset class and we only have Images in it! So that should make it more comfortable in these cases.

[Toadcop]

Jamarr thanks for a proper answer ! <3
so i am waiting for 0.8 =) and hope there is no too much to rewrite in rendermodule...

[Kulik]

So far the renderers were left intact AFAIK.

[Jamarr]

Also, CEGUI 0.8 gets rid of the Imageset class and we only have Images in it! So that should make it more comfortable in these cases.

I am curious to know the motivations behind that decision and what the implications are for v0.8 in regards to images

[Kulik]

Jamarr: Imageset is now just a convenient file format to create a lot of images, instead of a strictly enforced concept inside the library.

It has many really nice advantages, the whole thing got more dynamic and adaptable, you can now implement anything that is flat and somehow confined to a rectangular shape as an image (so SVG, webpage, ... can be an image now! and you can skin windows with it). It has some unpleasant implications though, especially for the editor I am writing, I can't just reload an imageset, I have to collect all images from it, destroy them and load the imageset again.

[Jamarr]

Jamarr: Imageset is now just a convenient file format to create a lot of images, instead of a strictly enforced concept inside the library.

It has many really nice advantages, the whole thing got more dynamic and adaptable, you can now implement anything that is flat and somehow confined to a rectangular shape as an image (so SVG, webpage, ... can be an image now! and you can skin windows with it). It has some unpleasant implications though, especially for the editor I am writing, I can't just reload an imageset, I have to collect all images from it, destroy them and load the imageset again.

I see. It sounds similar to what CE did with the Rendering sub-system: abstract the high-level concepts and allow different sub-systems to provide their own implementations. Eg how systems should be written