Mar 29 2006, 1:12 pm
|
|
Kunark
 |
Question: Will the OpenGL mean that icon procs will no longer murder resources?
|
Kunark, unfortunately not. The icon procs are all done server-side (and quite inefficiently at that). The OpenGL is client-side.
| |
So, does this mean that a 64x32 mob would move around (in a consistently connected manner) by default, or does it mean that this special "big icon" library would have to handle this? Also, would said library include support for varying density of tiles(say the top of the mob were to be non-dense, while the bottom were dense)?
For some reason, the more I think about this the more questions it poses. Are abnormal dimensions, such as 33x37 going to be supported, or would it be tiled out on a 64x64 scale? And, uh, I think I'll hold off on some questions, now, before I go overboard. ;) On a side note, this is great news! | |
Hiead - the way I read it, it just means that large icon states are broken up into 32x32 pieces, but by default you just get a scaled-down version of the image. Similar to what happens now when you use PNGs.
It would be nice if at some point there were some extra atom variables which we could use to tint graphics without the extra resource downloads... =) | |
Hiead: Right now it'sdone through the DM library that I'm working on. By default, all the parts will mimic the values of the source object. you can however toggle them each individually after the library generates them. Say you want the corners of a 96 x 96 icon to be nondense and nonopaque, you can loop through the source's parts list to find them and toggle those values off.
The library will only support multi-tile objects in tile sized chunks, so the 33x37 mob would come out 64x64. If you develop your own system for partial tile density though, you should be able to integrate it with this library without much fuss. Crispy: I agree wholeheartedly with your extra variable suggestion. I pitched something like it yesterday. ;) | |
Not sure if anyone asked about this yet, but with OpenGL, might there be a significant improvement to framerate? If so, will our DMIs be able to do more than 10 frames a second?
| |
Crispy, at some point I'd like to redo the icon format to support a sort of "meta-icon" structure, containing instructions for running icon operations at the client end. That is, to tint an icon and add a highlight you might have a metaicon structure like this:
Icon A Color #ff0000 ICON_MULTIPLY Blend ICON B ICON_ADD Blend Having icon A and icon B already loaded by the client, the meta-icon format could instruct the client how to create new icons from those. I have no idea how to do this, cache-wise. Creating and interpreting the metadata is somewhat easier. | |
Yeah, that would be very nice to have. Sort of like a mini scripting language. Caching them is a bit more involved though, especially since one needs to be able to modify these instructions at runtime.
Cue technical ramble: I guess one way to do it would be to create a new packet type that sends information about new metaicons: The filename of the icon it's based on (which needs to be sent to the client and thus cached beforehand), the sequence of instructions, and a new filename for the metaicon (which might be created by taking the base icon's filename and adding a server-generated hash based on the instruction sequence). I say server-generated because then the server can check to avoid any naming collisions. Then the client generates the new icon with the given filename and caches it as is normal. Basically it'd be exactly the same as the existing process of sending new resources, except that there's a new packet type and it depends on having an existing resource present. | |