Animations And LÖVE (AnAL) - The animations replacement lib

[case]

Hi,

It seems AnAL forget two of the draw() arguments (the image offsets), i had to fix it like that:

Code: Select all

function anim_mt:draw(x, y, angle, sx, sy, ox, oy)
	love.graphics.drawq(self.img, self.frames[self.position], x, y, angle, sx, sy, ox, oy)
end

Even with that, the offset arguments don't behave like the love.graphics.draw() ones. I bet
it's because the animation image is slightly larger than the displayed image. I guess it would
be better if AnAL could mimick exacly love.graphics.draw() behaviour, but i've no time to
write a fix for that right know. Here is the part of my own code that show the different
behaviours ( 16,16 on one side, 8,8 on the other) :

Code: Select all

   if love.keyboard.isDown("up") then
      lm.anim:draw(lm.b:getX(),lm.b:getY(),lm.b:getAngle(),1,1,16,16)
   else
      love.graphics.draw(lm.img, lm.b:getX(), lm.b:getY(), lm.b:getAngle(),1,1,8,8)
   end

(the animation lm.anim is made of 4 frames the size of lm.img , in square)

hope this helps.

[bartbes]

Well, I did use the 0.5.0 functions as a model, and they didn't have the offset, that's why they're not in the lib. But I doubt it's the libs fault that the ox and oy args to drawq behaves differently than to draw.

[case]

My post wasn't about telling who's fault it is, just to suggest changes to makes the lib use more straigthforward...

I don't think the offsets arguments behave differently in draw and drawq, I think that the lib has to take into
account the size of the animation image and the size of a single frame and convert the offset suplied by the
user in order to make it behave like it was a single frame image...

Regards.

[bartbes]

I should've written it better, anyway, I meant to explain why this was the case, and I basically forgot to tell I added it to my todo.
About the different behavior, I think you're wrong there, the lover (as established at the Tuesday Convention) should pass the same as he would with draw, right? AnAL only serves the right quad, and tells LÖVE the offset, makes sense, because essentially image+quad=image, so should yield the exact same result, if it doesn't, there probably is some error in the quad code.

EDIT: I should explain that if it is, it's still my fault, I was responsible for the quad code (the original version, anyway)

[konsumer]

That works perfectly. Thanks!

Attached is me following your sage advice + the character can walk around on the screen. Hopefully this will help others who are trying to do something similar.I have the margin set to -10 (to enable screen scrolling.) Should I put this in the demos section?

[case]

There is still a difference when i use drawq:

Code: Select all

q = love.graphics.newQuad(0,0,16,16,16,16)

[...]

   if love.keyboard.isDown("up") then
      lm.anim:draw(lm.b:getX(),lm.b:getY(),lm.b:getAngle(),1,1,16,16)
   else
      love.graphics.drawq(lm.img, q, lm.b:getX(), lm.b:getY(), lm.b:getAngle(),1,1,8,8) -- exact same behaviour than love.graphics.draw(...)
   end

[bartbes]

Same happens when you use

Code: Select all

    function anim_mt:draw(...)
       love.graphics.drawq(self.img, self.frames[self.position], ...)
    end

?
I won't know what to do, it should just.. you know, work.

[nunix]

konsumer: you'll want to check how your code is reading keypresses. if you're walking one direction, then press another key simultaneously and keep holding both, he'll start going the new direction.. but when you let go of one of them, weird things happen. examples:

hold left, then press and hold down while still holding left.. now let go of left and he'll start walking left instead of down.

hold left, then press and hold down while still holding left.. now let go of down and he'll keep walking down.

you should definitely start a thread for it though. =D

[bartbes]

Well, new version released, contains docs and maps ox and oy. (did nothing about the above mentioned 'displacement')

[Devhochi]

thanks for aiding my request