LF2 Bitmap Loading Algorithm

[A-Man]

So I was pretty confident I knew how it was done, until today I saw a grid which was parsed and displayed in LF2 correctly, when according to what I "knew", shouldn't have.

Here was my theory:
-- The width of the grid is divided (and probably floored ceiled ) by the X in "row: X".
-- Similarly, the height of the grid is divided by the Y in "col: Y".
-- Multiples of the result would act as the top-left coordinate of the clip in the grid.
- e.g:
- 700x500 sheets loaded with "row: 7 col: 5"
- 700/7 = 100. The clips/dirtyrects' left coordinates are multiples of that (7 of them, since row: 7): 0, 100, 200, 300, 400, 500, 600
- 500/5 = 100. and since col: 5: 0,..400
-- Now what sets the width and height of the clips recangles are the width and height specified in the "w: h:" tags.
-e.g:
- "w: 99 h: 99" would extend the rectangles from their left-top position to the right-bottom by 99 pixels, leaving out the 1 pixel lines. A value of 95 would leave space for a 5 pixel line and so it works.

Now here is the grid I came across:


Original size: 1776x856

Code:

file(190-239):       sprite\sys\One_Piece\luffyts_3.bmp w: 175 h: 160 row: 10 col: 5

What I thought was the algorithm would kill the chances this would display correctly at step 1. Any idea how LF2 does this?

[STM1993]

-- The width of the grid is divided (and probably floored) by the X in "row: X".
-- Similarly, the height of the grid is divided by the Y in "col: Y".
-- Multiples of the result would act as the top-left coordinate of the clip in the grid.
- e.g:
- 700x500 sheets loaded with "row: 7 col: 5"
- 700/7 = 100. The clips/dirtyrects' left coordinates are multiples of that (7 of them, since row: 7): 0, 100, 200, 300, 400, 500, 600
- 500/5 = 100. and since col: 5: 0,..400
-- Now what sets the width and height of the clips recangles are the width and height specified in the "w: h:" tags.
-e.g:
- "w: 99 h: 99" would extend the rectangles from their left-top position to the right-bottom by 99 pixels, leaving out the 1 pixel lines. A value of 95 would leave space for a 5 pixel line and so it works.

The w: and h: is for the sprite, not for the grid. So you should be adding rather than subtracting, thus your sprite sheet should be at least 700x500 + 1*(10-1)x1*(7-1) = 709x506.


This is a sprite grid with row: 4 col: 3, each sprite is w: 10 h: 10.
The total size of this spritesheet is 43x32

[A-Man]

I understand the w: and the h: is for the sprite clip and not the whole grid of course.

thus your sprite sheet should be at least 700x500 + 1*(10-1)x1*(7-1) = 709x506.

Where did the 10 and 7 come from? And how did you come up with the 1 you're subtracting these?
Can't I parse a 700x500 grid containing 7 by 5=35 sprites by using "w:99 h:99 row:7 col:5"?

This is a sprite grid with row: 4 col: 3, each sprite is w: 10 h: 10.
The total size of this spritesheet is 43x32

This should be shown correctly parsing it with the way I described.

43/4 = 10.75 -> ceil -> 11 ; left values are 0, 11, 22, 33 (multiples of the result, 11)
32/3 = 10.6` -> ceil -> 11 ; top values are 0, 11, 22 (multiples of 11)

The width for every clip is what's specified in "w: 10 h: 10":

[STM1993]

Where did the 10 and 7 come from? And how did you come up with the 1 you're subtracting these?
Can't I parse a 700x500 grid containing 7 by 5=35 sprites by using "w:99 h:99 row:7 col:5"?

Ah, my bad, I read this thread as a spriting question rather than a programming question
The math I used is for my own grid-drawing use when spriting. The 10 and 7 came from the row and col respectively, the -1 is to take into account that the rightmost and bottommost border of the grid isn't actually needed. But I digress.

Anyway,

If I'm reading it correctly, aren't you assuming that the sprite sheet has no wasted space for the logic to work? Where did the 700x500 come from otherwise? Shouldn't grid calculation be done independent of the bitmap's size and entirely based on w: h: row: col:? LF2 doesn't care if a bitmap has the correct size as long as the bitmap file itself exists, otherwise every single one of LF2's sprites would actually be parsed wrong because all of them have excess pixels.

For the luffy case:
1776x856 is the size of the spritesheet.
1776/10=177.6 -> ceil -> 178 which is wrong.

w: 175 h: 160 row: 10 col: 5
In reality LF2 would only use 1759x804 of the spritesheet.
1759/10=175.9 -> ceil -> 176 which is correct.

[A-Man]

1. specify:dimensions of the frame, how many rows, columns, border in px

And there was where I realized my mistake. Seems LF2 will calculate a constant width of 1 pixels for a border whether you like it or not :\. But I tested, and it confirms it. Thanks!

If I'm reading it correctly, aren't you assuming that the sprite sheet has no wasted space for the logic to work? Where did the 700x500 come from otherwise? Shouldn't grid calculation be done independent of the bitmap's size and entirely based on w: h: row: col:? LF2 doesn't care if a bitmap has the correct size as long as the bitmap file itself exists, otherwise every single one of LF2's sprites would actually be parsed wrong because all of them have excess pixels.

For the luffy case:
1776x856 is the size of the spritesheet.
1776/10=177.6 -> ceil -> 178 which is wrong.

w: 175 h: 160 row: 10 col: 5
In reality LF2 would only use 1759x804 of the spritesheet.
1759/10=175.9 -> ceil -> 176 which is correct.

Ah I see now. Even though I just checked and Davis's don't seem to have any extra pixels on the right/bottom (800x560), you're right. LF2 doesn't really seem to care about the width. My farfetched algorithm requires the grid's only excess space to be for the borders(but you could have a border that is as big as you like). Thanks!

[NightmareX1337]

I would just add there is no ceiling process, it's a simple integer division and floating part is completely discarded as you already know... You may get wrong results while using negative values if you do ceiling.

But... My instincs say I'm missing something...

[A-Man]

But... My instincs say I'm missing something...

That there is no division in the first place XP.

Seems LF2 just takes the ("w:"+1) multiples "row:" times, and ("h:"+1) multiples "col:" times for the top-left coordinates. The width and height values are then simply "w:" and "h:" respectively. Its very similar to how a sheet generated by flash is like; the only difference being that it adds 1 for every sprite for the border.