ID:189170
Sep 25 2003, 8:00 pm (Edited on Sep 25 2003, 9:38 pm)
|
|
(From TomB) Lummox JR wrote: I think next I might try to figure out exactly how .dmi files are formatted, then try to make a utility to convert .bmp files directly .dmi. Ooh, don't dig around in the .dmi binary file; that's just asking for headache! I can provide the format if you want, but it might be easier to just provide a utility since the dmi uses some "weird" compression that isn't that easy to follow. Come to think of it, I may even have this utility in the archives somewhere, as another user requested such a thing in the past. I can look into that once get this next release behind us this week. FYI, the format will be changing to support larger sizes and 24-bit color, but that's at least a few months down the line. Ideally I wish we could just use a standard format for everything, but because of the need for directions we needed something customized. We'll at least support PNG fairly soon so that movies can be imported with ease. And remember, in the map editor at least you shouldn't have to go through dmis at all if you just want to input large bitmaps. Just assign the bmp to the large object of choice (generally a turf or an area) and click your way to big pictures! The utility sounds great. Welcome aboard! Meh, I have had my nose in that format for quite some time, and have figured out about half of it.. and now you say you'd provide it? -_-... I myself am trying to create a utility for LINUX users to create and modify DMI files.. since you guys were so kind to release a linux compiler, the task didn't seem so huge.. Of course map editing would take forever since it reads from compiled data (or source scripts)... And also, it seems that you are going to release a new .dmi format, which basically will make my monthes of work useless -_-... Is there any way that I can get the new formats from you so I can provide acceptable linux alternatives, and/or is there a way I can prove that I can do what I claim? I have been in and out of the byond scene since april 2001, and eagerly await the new byond.. But I guess my unnecesary comments about byond in the past gave me a bad impression -_-.. sorry if it did.. Well if you cannot give out the format, that is fine, I will once again decode the new format with my trusty khexedit and gcc tools.. But hey, theres no harm in hoping :) |
In response to Lummox JR
|
|
Icon: Well I was reading ur thing and decided too look at one of my own .dmi files and see if I can find each peice of the .dmi format and how it fits together and were it goes. Every thing was going ok intell I reached the above part and got all confused. I understand the Icon ID im guessing it just counts up per icon state and such in the .dmi. The part I dont understand is bellow that. I think the .dmi file is compressed because in the # of runs for run-length encoding it has 47 as one of its bits. But from there Im just confused as I said earlyer. Could you please explain what the other information is doing in morte detail. Thank you for any help. |
In response to Green Lime
|
|
Non-compressed: I was digging through this recently myself, and I think there is a bit of compression here. Rather than being '1 byte each', I think they still use the above compression formula to determine how much space they take up. For example, if your icon uses 7 colors, that would give a formula of: y = (n+k)*x/8 So, rather than taking up a fully uncompressed 1024 bytes, the colors section will only take up 384 bytes. Each of the 1024 pixels will be assigned a numeric value based on it's color's position in the color listing at the beginning of the icon. There are some cases I haven't figured out yet, and I haven't even tried to pull the colors out of that mess since I don't need them for what I'm trying to do. |
In response to Flick
|
|
Flick wrote:
Non-compressed: > y = (n+k)*x/8 So, rather than taking up a fully uncompressed 1024 bytes, the colors section will only take up 384 bytes. Each of the 1024 pixels will be assigned a numeric value based on it's color's position in the color listing at the beginning of the icon. So with that formula your basically finding y = the number of bytes the encoding takes up. But what about the encoding its self. Is there a way too see what colors are in what pixel? & instead of 1024 pixels you should use the run-length incoding they gave above for compressed icons. Right? Thanks for any help. |
Lummox JR