Resolution Solution [library]

[GVovkiv]

Resolution Solution
Yet another scaling library.

Video demonstration:


Github page

What it can do:
It have 3 scale modes and you can switch between them at any time:
1 Aspect scaling mode - creates black lines/bars on sides, will provide same width and height scale for pixels, result in more clean look.
2 Stretching - stretch game to fill entire window.
3 Pixel Perfect - will scale, using only integer scale factors and adds black bars if it can't. Useful for pixel art.

[GVovkiv]

Also, i come up with this name long time ago, when i was using clickteam fusion 2.5
i developed there example, where i show how you can add similar functionality to CF2.5
yeah, good old days

[Gunroar:Cannon()]

Nice work cleaning it up into something better (also now makes sense why you put [trash] by aspect.lua, maybe it should be [outdated] or something )
The name is also pretty long, but I guess it's okay if it gives nostalgia.

[GVovkiv]

Nice work cleaning it up into something better (also now makes sense why you put [trash] by aspect.lua, maybe it should be [outdated] or something )
The name is also pretty long, but I guess it's okay if it gives nostalgia.

nope, [trash] tag make more sense since i literally deleted all related to aspect.lua files, github page

[Gunroar:Cannon()]

Oh, yeah. Definately,

[AlexCalv]

I'm having an issue with my game scaling in 16:9 resolutions. The scaling works fine in 4:3 and if my resolution is like 1279x720. But if it's in a 16:9 resolution and not 1920x1080 everything is off screen. I've looked at your example and I don't think I'm doing anything differently from your image drawing. I've provided my .love file as well.

[GVovkiv]

I'm having an issue with my game scaling in 16:9 resolutions. The scaling works fine in 4:3 and if my resolution is like 1279x720. But if it's in a 16:9 resolution and not 1920x1080 everything is off screen. I've looked at your example and I don't think I'm doing anything differently from your image drawing. I've provided my .love file as well.

This library solve 1 specific problem:
If you need to render game, lets say, on 800x600 it's not very conveniently for end user to play in unresizable 800x600 window
So this library allow you to scale game to window with any size
800x600 game to 1920x1080 window and vise versa
So end user may play in your game with that window size, that they want

But i doesn't mean, that game will magically render properly itself, if you, for example, hard coded game for 1920x1080, you can't expect it to work if you set it to 800x600
You still should to deal with manually adding, for example, configs for 1920x1080, 1280x720, 800x600
This applies to: scrolling, camera, objects that should be in players vision regardless of resolution, etc

Also, just advice, create 2 separate functions to change game RENDERING resolution and actual window size

[togFox]

I found something that is not really a bug but something that is definitely inconvenient.

Using your RS library for the first time, I tried to draw a simple circle on the screen. When executing, it flashes the circle at the start and then it disappears. The draw loop was working - but the circle wasn't being drawn. After about 10 minutes of investigating and looking at your sample code, I fixed it with this:

Code: Select all

	love.graphics.setColor(1, 1, 1, 1)          <--------------
	love.graphics.circle("fill", x, y, 10)

I had to use setColor to see the circle. Something in your library is using 'black' (probably the background/bars) and making draw calls invisible unless someone thinks to manually set the colour back to white. I'm not sure if you can capture the 'default' colour and then return to that colour when your library exits? If you can't, then I would have to call setColor far more times than I normally would. I don't think ASPECT had this problem (?).

Maybe, for now, you can document this in your github and sample code?

Thanks for the library!

[GVovkiv]

I found something that is not really a bug but something that is definitely inconvenient.

Using your RS library for the first time, I tried to draw a simple circle on the screen. When executing, it flashes the circle at the start and then it disappears. The draw loop was working - but the circle wasn't being drawn. After about 10 minutes of investigating and looking at your sample code, I fixed it with this:

Code: Select all

	love.graphics.setColor(1, 1, 1, 1)          <--------------
	love.graphics.circle("fill", x, y, 10)

I had to use setColor to see the circle. Something in your library is using 'black' (probably the background/bars) and making draw calls invisible unless someone thinks to manually set the colour back to white. I'm not sure if you can capture the 'default' colour and then return to that colour when your library exits? If you can't, then I would have to call setColor far more times than I normally would. I don't think ASPECT had this problem (?).

Maybe, for now, you can document this in your github and sample code?

Thanks for the library!

Ah, i remember that
When i was rewriting "stop" function, i was asked myself "do i need make library to restore colors or let user do that manually?"
Because "if it restore original colors (that was before stop function) do i need restart other graphical states such as shaders, scaling, etc?"
But because love2d.org/forums doesn't exist, i was unable to ask others what they think about "how library should deal with that case"

so, tl;dr:
What for your taste is better:
Just point out "hey, don't forget to "love.graphics.setColor"!
Or just take care that by library?
(Since i still can't decide, lol)

[togFox]

I totally think you should set the colour back to the way it was. That's my humble view. A self-contained module/library should not impact the main code/project in unexpected ways like this. I'm not sure about other graphical states - are there many?

If you can't/don't reset back, then document the github, library and sample code to save other people a lot of heartache. Thanks.