It's super easy when you use sspr()
sspr( x , y , w , h , dx , dy , [ dw , dh , a ] )
x -- x position to grab from spritesheet
y -- y position to grab from spritesheet
w -- width of grab
h -- height of grab
dx -- x position to draw onto game
dy -- y position to draw onto game
-- dw , dh , a are optional parameters
dw -- the width of sprite drawn
dh - the height of sprite drawn
a -- flip rotate stuff
i think in your condition,
-- considering there's 4 4x4 sprites in one 8x8 sprite -- locations of sprite would be (0,0),(0,4),(4,0),(4,4) -- let's place them next to each other horizontally. sspr( 0 , 0 , 4 , 4 , 58 , 62 ) sspr( 0 , 4 , 4 , 4 , 62 , 62 ) sspr( 4 , 0 , 4 , 4 , 66 , 62 ) sspr( 4 , 4 , 4 , 4 , 70 , 62 )
-- a methos that uses way less bytes for i = 0 , 3 do sspr( (i/2)*4 , (i%2)*4 , (58+(i*4)) , 62 ) end
if your still having trouble, then i can make a quick cartridge for you that shows how its done <3
electricgryphon: The third and fourth parameters to spr() are in 8x8 tiles, so 2,2 gives you a 16x16 px sprite.
It seems you can use fractional numbers for these values though: e.g. 1.5, 1.5 will give you a 12x12px sprite. I dunno if this is intentional so it might go away in a future version, and since the sprites are numbered in rows of 8x8 tiles I'm not sure you can address the bottom half of a tile (maybe by using negative tile sizes??)
According to zep here, sspr() is twice as slow as spr().
You can also use clip() to restrain the drawing of your sprite to a 4x4 region. So you clip just before drawing the sprite with an offset to select witch quarter you want to draw. I just tested it, and it can be slightly faster than sspr but not much. Sspr seam to cost less when there is no resize of the sprite.
[Please log in to post a comment]