LÖVE

Hi, I'm kinda new in Löve2D but I did quite a lot of coding in lua with other platforms..
I search in all the wiki but I did only found that the one and only method to modify an image's dimension is with the xScale and yScale when I draw it with "love.graphics.draw( image, x, y , rotation, xScale , yScale)"..

I think that this method is pretty bad when I want to make an image with an exact width and height so..
There is any other method to change the width and height of an image?

Thanks,
Stefano

There is not. But what's "bad" about the scaling parameters, they don't have to be integers!

bartbes wrote:There is not. But what's "bad" about the scaling parameters, they don't have to be integers!

I know, with scaling I can be quite precise, but I have to try and try and try again to find if that is the "correct scale" to match a measure..

elkiwydev wrote:I think that this method is pretty bad when I want to make an image with an exact width and height so..
There is any other method to change the width and height of an image?

bartbes wrote:There is not. But what's "bad" about the scaling parameters, they don't have to be integers!

It's 'bad' because it is a scaling factor, and not a direct size setting.

Of course it's trivial to scale to an exact size. It's simply:
edit: This actually goes back to something I was saying earlier, about the tendency of people to instinctively avoid math and look for programatic or code based alternatives. For game programming, basic math is critical. Embrace it.

bdjnk wrote:

elkiwydev wrote:I think that this method is pretty bad when I want to make an image with an exact width and height so..
There is any other method to change the width and height of an image?

bartbes wrote:There is not. But what's "bad" about the scaling parameters, they don't have to be integers!

It's 'bad' because it is a scaling factor, and not a direct size setting.

Of course it's trivial to scale to an exact size. It's simply:

Code: Select all

desiredSize / fullSize = scaleFactor

edit: This actually goes back to something I was saying earlier, about the tendency of people to instictively avoid math and look for programatic or code based alternatives. For game programming, basic math is critical. Embrace it.

Ok thanks,that was helpful...
..But now I have another problem..
Since I'm only scaling the image without any reference to the display resolution.. There will be some problems with other resolution or not?
For exemple, now I'm setting the right scale to fit the proportion of my 1080p screen.. What will happen if I test my game on a different screen? there will be glitches?

edit: Well, I guess i can do some script with your "desiredSize/fullSize = scaleFactor" with the reference on the screen size..

I just use love.graphics.scale to scale the entire coordinate system to allow for different window sizes.

What I did for my Eat It! game was I drew everything assuming a 1920x1080 viewport then used the love.graphics.scale() feature as a wrapper around this to scale it up or down to the window size using the algorithm posted above. (window width / 1920 = horizontal scale)

It then uses love.graphics.setScissor() to letterbox the content. You have to calculate the setScissor size manually though by figuring out the x and y offsets (How much of a buffer is going to be on the top, bottom, left or right) and calculate the scale * game draw area width/height. And you find out the offsets with a formula like this: offset = (window width or height - (scale * game draw width or height)) / 2

Something like this:

love.graphics.setScissor(offset x, offset y, scale * draw area width, scale * draw area height)

Or something like that.

You'll see it in action a 10 seconds into this video.

I used to have code to detect when it should scale based on vertical height instead and then use the one that makes sure the content is contained inside the window, but I forgot how to do it a long time ago.

If you draw everything to a preset canvas, it's much easier. But not everyone wants to use a canvas. So my method works for just outright drawing to the screen. However, you might encounter graphical problems if using a tile based mapping system. (Which a canvas would avoid completely)

Of course this might all not even make sense. I really need to recode Eat It! I didn't even have a proper State Stack system when I coded that.