The Bounding-Box-Control-Dwords in the COF files explained

This is the place to discuss all issues relating to the manipulation of graphics/animations, sounds, music and cinematics within Diablo 2.

Moderators: Nefarius, Necrolis

Post Reply
User avatar
Nefarius
Retired Admin
Cherub
Posts: 11607
Joined: Sat Jun 15, 2002 8:13 pm
Location: Where the blood forever rains
Contact:

Hand-picked

The Bounding-Box-Control-Dwords in the COF files explained

Post by Nefarius » Wed Apr 02, 2003 11:55 am

Well, after reading the COF file descriptions available I always saw that the four dwords (often looking random) in them were always said to have no logical pattern, well I discovered what they are used for :)

01 14 08 14 00 FF 00 00 7F FF FF FF 80 00 00 00 7F FF FF FF 80 00 00 00 01 00 00 00 01 01 01 00
05 68 74 68 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

7F FF FF FF 80 00 00 00 7F FF FF FF 80 00 00 00

There is a simply formula to create the correct values,

hbound > dword 1 = FF FF FF FF - (image_width_px)
hbound > dword 2 = 00 00 00 00 + (image_width_px)

vbound > dword 1 = FF FF FF FF - (image_height_px)
vbound > dword 2 = 00 00 00 00 + (image_height_px)

This is why the above cof has changed so drastically:

7F FF FF FF 80 00 00 00 7F FF FF FF 80 00 00 00
128 = 80, 80 - FF FF FF FF = 7F FF FF FF. This makes it use the entire image for the bounding box.

(quote from a PM I sent to Alkalund to verify if this was known already)
Hey there, I discovered something about COF files, that from reading older posts is not yet known, but I may have overlooked something so im asking you if its known already, the 4 dwords in a COF file, with two being negative and two being positive, I discovered the pattern used for them! I also know what they are used for.


Just for a note, this is what I refer to:
Code:
01 14 08 14 00 FF 00 00 91 FF FF FF 6E 00 00 00 91 FF FF FF 6E 00 00 00 01 00 00 00 01 01 01 00
05 68 74 68 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01


91 FF FF FF 6E 00 00 00 91 FF FF FF 6E 00 00 00

IF you look correcty at this you will see FF FF FF 91 + 00 00 00 6E = FF FF FF FF, now This controls the BOUNDING BOX of the sprite (the area of selection when you scroll over a monster), I ran into a small mistake when I changed dword 1 to FF FF FF FF and dword two to 00 00 00 00 that made my monsters unselectable (well nearly, only on 0x/0y of the offsets)

now my animations were 128 px high, vert offset was 110 (6E) the positive dword is the VERTICAL offset aka 00 00 00 6E (rev byte order would be 6E 00 00 00) and hence controls the uselectable area: 110-128px while FF FF FF 91 (91 FF FF FF) controls the selectable area: 0-109px

I think one dword is dealing with horizontal bounds, but I dont know which of them. (instead of offsets it may refer to the whole animation.)

Another note, if you look at non-selfmade cofs you will see the values mostly dont equal FF FF FF FF, this is because unlike the converted d1 animations the d2 animations have different offsets for each direction, this remaining value seams to be the px different between the directions.

EDIT, im now fully positive on it, the first two dwords are for horizontal bound and the second two for vertical bounds.

dword 1 controls the covered area, dword 2 controls the starting area so 00000000 FFFFFFFF would techincally make the entire animation (in my case 128x128) into the selection area, while FFFFFFFF 00000000 would make it negative and only the stuff below the offset line 110px will be selectable, Now I really hope I haven't been wasting my time on something that is known already.
Last edited by Nefarius on Wed Apr 02, 2003 11:56 am, edited 1 time in total.
''(...) The game can basically be considered unhackable. '' - Blizzard Entertainment (30th May 2000)
Black Omen Productions | MetalStorm: Progress Report | Screenshots

User avatar
Joel
Retired staff
Dominion
Posts: 6921
Joined: Mon May 27, 2002 7:19 am
Location: Orsay
Contact:

Hand-picked

Re: The Bounding-Box-Control-Dwords in the COF files explain

Post by Joel » Wed Apr 02, 2003 8:15 pm

i'm totally lost with your formulae (and so does Paul ...)

can you give a betetr example .... (with an ingame existing animation)
"How much suffering, mortal, does it take before you lose your grace?"
Shadow Empire (coming soon) | forum

User avatar
Paul Siramy
Retired staff
Principality
Posts: 2828
Joined: Sat May 25, 2002 2:39 pm
Location: La Garenne Colombes (near Paris)
Contact:

Hand-picked

Re: The Bounding-Box-Control-Dwords in the COF files explain

Post by Paul Siramy » Thu Apr 03, 2003 12:29 am

Ok, I finally got it. I needed to make several tests, but I got it.

Each DWORDS is a position, they're delimiting the selection bounding box as Nefarius said. It's working like that :

check this image

The Heart for understading is that all positions are relative to the sprite pivot (the blue cross). This sprite pivot is what DCC Offsets are used for (I won't go into more details about offsets, I assume they're already known).

Here this Bat is flying, that's why the sprite pivot is far under the frame. The white box is the frame 0. If we were drawing all frames of all directions of the BTNUHTH animation, all pixels would fit exactly in the red box. But the COF selection bounding box is different...

This selection bounding box is the area delimited by the 4 green corners. As you see, this box can be anywhere, it * don't have* to be in the red box. For this animation, the cof give us these 4 dwords :

-79 57 -86 -3 (these are the decimal values, in hexa it's FFFFFB1, 00000039, FFFFFFAA, FFFFFFFD).

The 1st dword is the horizontal displacment from the sprite pivot for the left border
The 2nd dword is the horizontal displacment from the sprite pivot for the right border
The 3rd dword is the vertical displacment from the sprite pivot for the upper border
The 4th dword is the vertical displacment from the sprite pivot for the bottom border

in summary :
dword1 = X MIN
dword2 = X MAX
dword3 = Y MIN
dword4 = Y MAX


What happen in the game here, since the left part of the selection bounding box is out of the red box ? The area between the green left border and the red left border is useless : it will never work. Now, a note about that : in fact, it's simpler than that... have you ever try to select a monster near his animation's edges, and see the name of that unit blinking ? That's because in fact the green selection box is the maximum area where the mouse can be, but in all cases, if the mouse is not in the current displayed frame, the game consider that you can't select that unit.

So in fact that cof selection bounding is not that usefull : you won't be able to select a unit far from where it's displayed on the screen, as it must be in the frame. But where it's becoming usefull is when you want to * reduce * that area : make the green box fit * within * the red box, and you'll be able to select that unit only when the mouse will be in the small green area (so, a part of the frame, not all), the area between the red box and this green box will become unselectable.

Now, here's why it's important to know that : if you're replacing an animation of a Fetish (very small) by a larger one (a beholder for instance), you'll have to increase the cof selection bounding box, else only the area where can fit a fetish will be selectable. Also, to make it more "fun" :-| : the fetish is on the ground, but the beholder is flying, so in any case you have to not only increase but also move that area.

If you don't want to be bored, just set that 4 selection box dwords in the COFs like this :

FFFFFE00  (00 FE FF FF in the file)  = -512
00000200 (00 02 00 00 in the file) = 512
FFFFFE00  (00 FE FF FF in the file)  = -512
00000200 (00 02 00 00 in the file) = 512

and you'll have a very big selection box, so what will be in fact selectable will be all the pixels of the current displayed frame, so no difference if it's a fetish or a beholder, flying or not : only the area where the current frame is will work anyway.



<<< EDIT>>>
@Nefarius : First, thanks a lot to have found what these unknow datas were used for :mrgreen: , they can be the source of troubles when converting monsters. You understand that your formulas won't work for the height of the animation : the sprite pivot is not in the middle of the sprite, and you also forgot that some monsters could fly ;)

I'm thinking of an interesting case were to reduce that selection box : if we make a monster with a large "aura" around him (like the ouragan skill of the druid), in order to not be able to select the aura pixels (on the S1 layer, with alpha blending maybe), we'll have to reduce that selection box to the body of the monster.
Last edited by Paul Siramy on Thu Apr 03, 2003 12:54 am, edited 2 times in total.

User avatar
Alkalund
Retired Admin
Throne
Posts: 7597
Joined: Sun May 26, 2002 5:54 pm
Location: Toronto, Ontario, Canada
Contact:

Hand-picked

Re: The Bounding-Box-Control-Dwords in the COF files explain

Post by Alkalund » Thu Apr 03, 2003 1:18 am

This is very nice... the monster selection problem that appeared when you replaced a small monster with big animations was annoying, with this we can finally solve that one :)

Editing the cof files by hand will be more time consuming now (unless you use default bytes as Paul mentioned), but the benefits are more than worth it.

User avatar
Joel
Retired staff
Dominion
Posts: 6921
Joined: Mon May 27, 2002 7:19 am
Location: Orsay
Contact:

Hand-picked

Re: The Bounding-Box-Control-Dwords in the COF files explain

Post by Joel » Thu Apr 03, 2003 7:16 am

I think I'll include the default BBox size in my COF generator and let the people modifying them if they see need.

Anyway THAT's explain why I can't get my beholdr to work nice ....
"How much suffering, mortal, does it take before you lose your grace?"
Shadow Empire (coming soon) | forum

User avatar
Nefarius
Retired Admin
Cherub
Posts: 11607
Joined: Sat Jun 15, 2002 8:13 pm
Location: Where the blood forever rains
Contact:

Hand-picked

Re: The Bounding-Box-Control-Dwords in the COF files explain

Post by Nefarius » Thu Apr 03, 2003 12:15 pm

Hmm, I wonder, how does it work for multi-component monsters, I never checked any of those cof files yet, As far as I can think it will use the full size of all components for the box. as there is only 1 cof file per anim logically.
''(...) The game can basically be considered unhackable. '' - Blizzard Entertainment (30th May 2000)
Black Omen Productions | MetalStorm: Progress Report | Screenshots

Post Reply

Return to “Multimedia”