## A few more questions

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Santos
Party member
Posts: 383
Joined: Sat Oct 22, 2011 7:37 am

### A few more questions

More questions about trivial details, yaaay!

It seems that drawing a quad conceptually works like this:
• Scale the image to the reference width and height.
• Crop the image using the viewpoint.
I don't quite understand the scaling part, and I have a few questions:
• Why doesn't scaling work like love.graphics.draw, with sw and sh being what the width and height are multiplied by, rather than the new width and height values?
• Why only scaling, why not rotation and shearing too?
• Why is it required? Couldn't a quad use a viewport on any image without having a reference width and height?
Is PO2 ever a problem anymore? Even for Canvases?

A couple of things I found slightly strange about ParticleSystems were that they have a position, and that they begin started, instead of stopped. Is there a reason why they have a position instead of just drawing it at a position with love.graphics.draw? And is there a reason why they're started by default? (I guess it prevents people from thinking "hey, where's my particle system?!?")

If there's an easy explanation, why can't LÖVE functions be easily overwritten?

This doesn't work:

Code: Select all

_print = love.graphics.print

function love.graphics.print(s, x, y)
print('This gets output once')
_print(s:upper(), x, y)
end

function love.draw()
love.graphics.print('Test', 10, 10)
end
The following works... until the stack overflows.

Code: Select all

function love.draw()
_print = love.graphics.print

function love.graphics.print(s, x, y)
_print(s:upper(), x, y)
end

love.graphics.print('Test', 10, 10)
end
Does anyone know why Concept:Current doesn't seem to work on the wiki? The definition seems to be "Since::≤080", but Framebuffer for instance doesn't seem to have a Since property, but is still displayed on love.graphics. Anyone have any ideas about this? If this can't be made to work, would removing parent::s of stuff removed from the API work?

Boolsheet
Inner party member
Posts: 780
Joined: Wed Dec 29, 2010 4:57 am
Location: Switzerland

### Re: A few more questions

Santos wrote:
• Scale the image to the reference width and height.
Uh. I don't think the reference width and height were ever meant to do "image scaling". The width and height are needed to calculate the vertex texture coordinates and giving wrong values distorts the image. It already came up once that this doesn't have to be exposed and could be calculated in the drawq call, but that means "wasting" precious CPU cycles.
Santos wrote:Is PO2 ever a problem anymore? Even for Canvases?
It is actually possible to support framebuffers but not non-power-of-two textures. There won't be many implementations with that of course, but... *bets on Intel*
(Edit: The image wrapping behaves slightly different for auto-padded images. The padding will be visible in a repeated pattern for example.)
Santos wrote:A couple of things I found slightly strange about ParticleSystems were that they have a position, and that they begin started, instead of stopped. Is there a reason why they have a position instead of just drawing it at a position with love.graphics.draw? And is there a reason why they're started by default? (I guess it prevents people from thinking "hey, where's my particle system?!?")
I'm assuming you're asking why the emitter position isn't used for the draw origin. The particles are in their own little 2D system and when you draw the ParticleSystem you kind of draw that space. Makes it easier to manage things behind the scenes.
I guess the default on thing was a design decision.
Santos wrote:If there's an easy explanation, why can't LÖVE functions be easily overwritten?
I don't think the problem is with LÖVE.

Code: Select all

local _print = love.graphics.print

function love.graphics.print(msg, ...)
print('This gets output once')
function love.graphics.print(msg, ...)
_print(msg:upper(), ...)
end
_print(msg:upper(), ...)
end

function love.draw()
love.graphics.print('Test', 10, 10)
end
And about the wiki stuff. Well, lovers might still be using 0.7.x and the wiki is kind of the only documentation so that's why it's still up there. Personally, I don't like the current way of putting different version on the same page, but I also don't know enough about the wiki markup to make or propose a change.
Last edited by Boolsheet on Sat Nov 03, 2012 5:30 pm, edited 1 time in total.
Shallow indentations.

Santos
Party member
Posts: 383
Joined: Sat Oct 22, 2011 7:37 am

### Re: A few more questions

Thanks Boolsheet!

Aaah, right, so quads aren't as simple as "go to x, y, and draw until width, height".

I'm still not completely sure about the ParticleSystem position though...

These seem to be equivalent I think, but I also think I may be missing something.

Code: Select all

ps:setPosition(0, 0)
x, y = 400, 300
love.graphics.draw(ps, x, y)

Code: Select all

ps:setPosition(400, 300)
love.graphics.draw(ps, 0, 0)
I still couldn't get that printing example to work correctly though, I was trying to make love.graphics.print print to the screen in uppercase, but it still doesn't seem to work and the console message still only gets output once.

Boolsheet
Inner party member
Posts: 780
Joined: Wed Dec 29, 2010 4:57 am
Location: Switzerland

### Re: A few more questions

Santos wrote:and the console message still only gets output once.
I thought that's what you wanted to do.

Oh... I see. From the LÖVE source code:

Code: Select all

	love.graphics.print = function (...)
if not love.graphics.getFont() then
love.graphics.setNewFont(12)
end
love.graphics.print1(...)
love.graphics.print = love.graphics.print1
end
I guess that means "use love.graphics.print1". If nothing shows up, you probably need to set a font yourself.
Shallow indentations.

Santos
Party member
Posts: 383
Joined: Sat Oct 22, 2011 7:37 am

### Re: A few more questions

Magical!

Code: Select all

function love.load()
love.graphics.setNewFont(12)
end

function love.graphics.print(msg, ...)
love.graphics.print1(msg:upper(), ...)
end

function love.draw()
love.graphics.print('Test', 10, 10)
end
Thanks again!

the_leg
Prole
Posts: 25
Joined: Sun Sep 05, 2010 3:43 am

### Re: A few more questions

Boolsheet wrote:
Santos wrote:
• Scale the image to the reference width and height.
Uh. I don't think the reference width and height were ever meant to do "image scaling". The width and height are needed to calculate the vertex coordinates and giving wrong values distorts the image. It already came up once that this doesn't have to be exposed and could be calculated in the drawq call, but that means "wasting" precious CPU cycles.
Hi Boolsheet. Would you mind explaining how you would calculate the reference sw/sh in the drawq() call?

Boolsheet
Inner party member
Posts: 780
Joined: Wed Dec 29, 2010 4:57 am
Location: Switzerland

### Re: A few more questions

The width and height don't need to be calculated. It would just call Image:getWidth and Image:getHeight (or their C++ equivalents) for you and then calculate the texture coordinates.
Shallow indentations.

Santos
Party member
Posts: 383
Joined: Sat Oct 22, 2011 7:37 am

### Re: A few more questions

Would the performance difference for drawq automatically using the Image vertices be significant?

I don't know anything about anything, but looking I'm through the source, and I'm wondering whether Image::drawq could make a vertex to send to drawv from the vertices of the quad as well as the Image's vertices from its vertices array, and if so, if it would have a significant impact on performance.
Boolsheet wrote:I'm assuming you're asking why the emitter position isn't used for the draw origin. The particles are in their own little 2D system and when you draw the ParticleSystem you kind of draw that space. Makes it easier to manage things behind the scenes.
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?

the_leg
Prole
Posts: 25
Joined: Sun Sep 05, 2010 3:43 am

### Re: A few more questions

Boolsheet wrote:It would just call Image:getWidth and Image:getHeight (or their C++ equivalents) for you and then calculate the texture coordinates.
Ah, I see, but then you couldn't use texture wrapping.

Boolsheet
Inner party member
Posts: 780
Joined: Wed Dec 29, 2010 4:57 am
Location: Switzerland

### Re: A few more questions

Santos wrote:Would the performance difference for drawq automatically using the Image vertices be significant?
Probably not. It already spends some time on the transformation for scaling, rotating and skewing so 4 divisions and 2 additions won't be significant.
Santos wrote: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.
the_leg wrote:Ah, I see, but then you couldn't use texture wrapping.
I don't see the connection.
Shallow indentations.

### Who is online

Users browsing this forum: Google [Bot] and 10 guests