A few more questions

[Robin]

Hmmm, I think I get this. So ParticleSystem:setPosition is setting the emitter position within the ParticleSystem's own 2D space? So... I guess I wonder then, is there any practical difference between setting the emitter's position as opposed to setting the draw origin of the entire ParticleSystem?

Yes, you want to be able to set the emitter position. I think there's no problem with the current design. This way, the lover can decide if he wants to translate to this position before the draw call.

IIRC ParticleSystem:setPosition only changes the emitter position, not the position of the particles that are already are emitted. Imagine an old-timey steam-powered train, The steam that comes out at the top should not move with the train as it moves, you want the train to leave a trail of steam. That's what :setPosition does.

[Santos]

Suddenly... it all makes sense. Thank you Robin!

And thanks again Boolsheet!

Maaaaaan, I love you guys. In a non-weird way. Ah who am I kidding. I love you guys in a weird way.

[the_leg]

Ah, I see, but then you couldn't use texture wrapping.

I don't see the connection.

My mistake, texture wrapping still works, but the newQuad() would now be tied to a specific image's w/h. For example, if I make a quad like this:

Code: Select all

   quad = love.graphics.newQuad(0, 0, 150, 150, 75, 75)

No matter what image I use later on in the drawq() call, I always get 4 repetitions of that image inside a 150x150 square (assuming repeat wrap mode). If however, the reference width and height are tied to the drawq()'s image w/h, then my quad's are also now tied to that image's w/h and I no longer have this flexibility.

For instance, if we omit the reference width/height and calculate the texture coordinates in the drawq() call, you'd have to do this to achieve the same result as before:

Code: Select all

quad2 = love.graphics.newQuad(0, 0, 2*img:getWidth(), 2*img:getHeight())
...
love.graphics.drawq(img, quad2, 0, 0, 0, 150/(2*img:getWidth()), 150/(2*img:getHeight()))

The scaling in the drawq() call is there to scale back my square to the 150x150 size I want. I admit this is a minor point, but thought it might provide some more insight into the reference sw/sh parameters.

[Boolsheet]

As I said, I don't think you were ever supposed to use anything else than the Image width and height. We could ask rude, but what's the chance he's going to remember such a minor detail.

[the_leg]

Agreed. It's a non-issue anyway, just was curious as to what you were thinking.

[Santos]

A few more things I was wondering about...

How can the pointer returned by Data:getPointer be used, and what could it be used for?

Other than not being implemented, is there a reason why love.thread.newThread doesn't accept a function as an argument?

love.graphics.clear restores the default coordinate system, right? I changed the wiki page to say this, but I just wanted to ask just in case I am completely confused.

[Robin]

Dunno about the other things, but:

Other than not being implemented, is there a reason why love.thread.newThread doesn't accept a function as an argument?

A function shares some contextual information with the current thread, so if it's possible at all (which I don't think) it would get really hairy.

Code: Select all

local shared = true
function whoops()
    -- some stuff
    shared = false
end
t = love.thread.newThread(whoops)
t:start()
print(shared) -- true or false?

How it works in LÖVE is that things like that are not possible, you have to explicitly ask for it to get sent information from other threads, which makes what happens a lot more obvious.

[Santos]

Aaaah, that makes sense. Thanks!

[Boolsheet]

How can the pointer returned by Data:getPointer be used, and what could it be used for?

This is a leftover from the old love.native module.

[Santos]

Ah, interesting! Out of curiosity, what was the love.native module?