A few more questions

[Santos]

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]

• 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.

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.)

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.

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.

[Santos]

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]

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.

[Santos]

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]

• 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]

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.

[Santos]

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.

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]

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]

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.

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.

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

I don't see the connection.