ID:2189407
 Dec 21 2016, 1:31 am (Edited on Dec 21 2016, 1:40 am)
(See the best response by Lummox JR.)
|
|
Is it better to use less or more dmi files to organise graphics?? And how many are usually used and at which point do they become bad for performance?
| |
Thanks for the explanation, btw since I use large icons I noticed that graphics crash when having many icon states in a dmi file. is there an icon_state limit per dmi dile??
And is there a total limit on graphics regarding disc space or icon_states?? | |
What's crashing, exactly, and how?
There isn't an explicit limit of icon states, except that the underlying structure has a specific integer size. I can't remember if it's 4 bytes or 2, but if you hit over 64K states in an icon file something has gone very wrong. | |
Honestly, the best thing to consider for grouping up icons is icons that are similar looking or have similar colors, to improve on the file size for lower resource downloads.
Other then that, plan ahead, base your icon grouping around the concept that at some point multiple people will be assigned to the task of spriting, and managing conflicts when two spriters modify the same dmi is a pain. | |
MrStonedOne wrote:
Honestly, the best thing to consider for grouping up icons is icons that are similar looking or have similar colors, to improve on the file size for lower resource downloads. This is probably the best recommendation. If you can keep the entire icon (including all frames of all states) to 256 colors or less *total*, I believe BYOND automatically switches to PNG's palette format. Ignoring variance from PNG's zlib-compression of the image data chunks, this basically reduces your file size by a factor of 4. (One byte per pixel versus four bytes per pixel.) It is much faster for you to display something to yourself than for you to send a file to 100 people and then for them to have to display it themselves. If you only have to send 1/4 the data for the same resources, then you're doing something right. | |
I don't think we do the palette thing anymore, although it would make sense in Dream Maker.
| |
A DMI I have from DM was saved in palette mode, though I can't say when it was created. It's one of the ones I use as a test case for a current project, which is the only reason I'm so sure of its pixel format storage.
| |
About the crash I have an animation of 40 images 540x450 in dimensions. If I include 2 such animations in an icon at run-time the object will have no graphics. Also on another occasion I have 1750x1750 images in one icon if I import 3-4 such images in runtime they wont appear like the graphics doesn't load or something. Even if these images only use 4-5 colors.
And another problem I noticed is when I import new graphics my map editor messes up the newly imported graphics and I have to close and open again dream maker. | |
Damn it seems I'm the only guy here that uses large images. Basically I render my images from 3d models using Blender.
So is there anything I should bear in mind using large images?? | |
Yeah, don't. There's a reason games that use stuff like that have to break it down into much smaller pieces and load them on-demand.
| |
In Dream Seeker's case, what happens with each icon is that the file is loaded into DS, and split up by icon state and frame. DS keeps a list of states for each icon, by name and whether it's a moving state or not. When it looks up what icon to use, it goes through and looks for the best match it can get. In files with a large number of states (over 100 IIRC), it creates a binary search tree so it can search faster for a good match. The lookup time is usually pretty negligible either way; the binary search was only added for dealing with cases where someone literally built an icon with thousands of states (for lighting).
Of special note is the fact that icons which aren't displayed more than once or twice per frame, like for instance a mob icon, aren't going to have as big an impact on your performance as something like a turf icon.