Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
LF2 Bitmap Loading Algorithm
#1
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:
[Image: KG7nfZg.png]

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?
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#2
(10-18-2015, 09:13 PM)Doctor A Wrote:  -- 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.

[Image: FcPXyd9.png]
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
[Image: uMSShyX.png]
~Spy_The_Man1993~
Steiner v3.00 (outdated), Challenge Stage v1.51
Luigi's Easier Data-Editor, A-Man's Sprite Mirrorer
Working on the LF2 Rebalance mod.
Avatar styled by: prince_freeza
Reply
Thanks given by:
#3
I understand the w: and the h: is for the sprite clip and not the whole grid of course.

(10-19-2015, 01:51 AM)STM1993 Wrote:  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"?

Quote:[Image: FcPXyd9.png]
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":
[Image: aHAnXYE.png]
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#4
(10-19-2015, 04:45 AM)Doctor A Wrote:  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.
[Image: uMSShyX.png]
~Spy_The_Man1993~
Steiner v3.00 (outdated), Challenge Stage v1.51
Luigi's Easier Data-Editor, A-Man's Sprite Mirrorer
Working on the LF2 Rebalance mod.
Avatar styled by: prince_freeza
Reply
Thanks given by: A-Man
#5
I had this algorithm somewhere working perfectly.

At the moment Im thinking of that


If cropping bitmap avaible in the app itself:

1. specify:dimensions of the frame, how many rows, columns, border in px
Code:
int frameWidth, frameHeight, rows, cols, gridWidth
2. Crop the bitmap to clear things out so
Code:
image bitmap = cropbitmap(oldbitmap,x=0,y=0,w=(frameWidth+gridWidth)*cols,h=(frameHeight+gridWidth)*rows)
3. Get sprite number i
Code:
int startY = math.floor(i/cols)
int startX = i%cols
int startYpx = startY * (frameHeight+gridWidth)
int startXpx = startX * (frameWidth+gridWidth)
image exactsprite = cropbitmap(bitmap,x=startXpx,y=startYpx,w=frameWidth+gridWidth,h=frameHeight+gridWidth)


Or you could simply go with cropping the spritesheets at the start

Code:
array sprites[]
int m,k = 0
until (m>(frameWidth+gridWidth)*cols && k>(frameHeight+gridWidth)*rows) do
 {
 if m>=(frameWidth+gridWidth)*cols then
   {
   m=0
   k = k + (frameHeight+gridWidth)
   }
 sprites.addelement(cropbitmap(sourcebitmap,x=m,y=k,w=frameWidth+gridWidth,h=frameHeight+gridWidth))
 m = m + (frameWidth+gridWidth)
}



[Image: NsiNMB9.png]

Help me and test my new game basis!




Reply
Thanks given by: A-Man
#6
(10-19-2015, 07:04 AM)Gad Wrote:  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!


(10-19-2015, 05:22 AM)STM1993 Wrote:  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!
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:
#7
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...
Ultimately, my constant dissatisfaction with the way things are becomes the driving force behind everything I do.
[Image: sigline.png]
LF2 IDE - Advanced visual data changer featuring instant data loader
LF2 Sprite Sheet Generator - Template based sprite sheet generator based on Gad's method
[Image: sigline.png]
There is no perfect language, but C++ is the worst.
Reply
Thanks given by:
#8
(10-19-2015, 02:10 PM)Nightmarex1337 Wrote:  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.
[Image: signature.png]
A-Engine: A new beat em up game engine inspired by LF2. Coming soon

A-Engine Dev Blog - Update #8: Timeout

Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)