vovkiv/resolution_solution

Yet another scaling library. Currently in maintenance-only mode.

Я вже доволі давно не користуюся цим кліктім, і коли я це і робив, то була піратська копія, яка не завжди була актуальна, тому я навряд-чи б зміг постійно тримати цей переклад у гарному стані.

За основу перекладу я узяв якийсь китайський фанатський переклад, оскільки кліктім це дуже стара (вже десь 30 років) програма, яка була створена за часи віндовс 95. Через це вона дуже прогнила і стала максимально не зручною для модифікацій та перекладів.

Наприклад, англійська мова самого інтефейсу знаходиться не у окремому файлі типу "english.json" бо щось подібне, ні. Вона прописана в сурсах самої програми. Тому щоб їх знайти, треба копатися у бінарниках. Це доволі не зручно.

І навіть якщо опустити цей момент, є інші проблеми. Наприклад, більшість вікон які вспливають у програмі, мають свій власний переклад. (навіть кнопки типу "окей" і "скасувати"). І в бінарниках вони підписані як "dialog_82928423". Навіть не зрозуміло де саме їх шукати програмі треба.

І найскладніше це додатки/розширення. Майже усі вони працюють по такому ж принципу. Оскільки вони є скомпільованими програмами, їх текст так само вписаний в бінарники, де їх так само треба діставати. Саме тому я і узяв за основу китайський проект, оскільки там вони змогли дістати усе потрібне у більш-менш нормальний вигляд.

Тому я і не завершив цей переклад. Мені просто не потрібна ця програма більше.

Тому, якщо хтось, колись, знайде цей репозиторій, то можете спробувати завершити мою справу...

resolution_solution's Issues

Window mode switch?

Should library deal with window states?
For example, be able to switch to windowed/maximized/fullscreen with built-in functions?
Also should it save state of window? Should it be updated at rs.resize()?

Additional coordinates [suggestion]

Maybe i should add coordinates, to save you from manually calculating them and simple use out-of-box?
e.g: rs.gameCenterX which will mean basically rs.gameWidth / 2?

shaders api/interface support?

There exist library called moonshine, that can chain shaders. It might be good idea to implement support for it out of box and, possible, include "default" implementation.
Maybe user could refer to rs.moonshine moonshine library?
I should have take a look into source of moonshine.

New Structure

Changelog, documentation, demo now will be moved from source file to different files:
documentation.md, changelog.md, demo.love

rs.drawBars

At moment, rs.stop() is tied to rs.drawBars to draw black bars, if turned on.
I need to untie it.
Maybe check if function exist and then call it?

Documentation

While library itself was designed to be documentation, it might be handy to include separate documentation.md (or pdf) file.

love.graphics.setScissor support?

Other scaling libraries use scissors to cut visible area. My solution do this by drawing black bars on top of scaled images. And while draw bars can be disabled via rs.bars and user can write own implementation on top with scissor, it would be nice to provide my own implementation, so if it suits user, then we should allow it.
Also, maybe i should provide "rs.cropMethod" where user could write or change crop method?

Resolutions handling? (pun not intendent)

At the moment, library simply use game width and height to scale to. So, if you use 1 resolution in your game, then you don't really need to do anything, but, if not... you kinda on your own, kid. If you, for example, want to support e.g 1920x1080 as 16:9 standard, 800x600 as 4:3 or even several resolutions for same aspect, e.g 1280x720, 1920x1080 then you need to manually craft list of resolutions, manually store somewhere, and manually decide what the nearest suitable resolution game can give as default.
So, i propose next:
Ditch rs.setGame() approach and use list with available resolutions, that you can fill with supported by you resolutions. Then, you load them with something like rs.setResolution(aspect, size) where aspect will correspond with aspect table, e.g {[1] = "4x3", [2] = "16x9"} and size with sub-table value with width and height. This will make selected resolution as current, and it will be used to scale to.
Also there will be tons of functions, to deal with list of resolutions, for example, to get list of all available 4:3 sizes, check if resolution is equal window/monitor size, so you could show user a message "This resolution is not match you monitor, continue anyway?" (tho, this sounds very annoying, so implementing this might sucks ass)
And, maybe very useful, include built-in timer, as games do: after changing resolution, lib will put 15 seconds timer and return old settings if options was not confirmed. But i also doubt that this will make into library, because i'm not sure how to approach this without love.update (since library now updates in love.resize)... maybe add separate function as rs.updateTimer(dt)? it sounds really ugly to put 2 update functions for something that could be done at 1...

non integer xOff and yOff

non integer xOff and yOff in pixel perfect scaling mode result in pixel bleeding. It's fine for non pixel perfect modes, so i need to patch it somehow...

Code sorting

Sort functions and variables names in sane way in source code

Add license file

Add library license text in library file

local function to make rs.init less cluttered

Currently, i copy and paste lines of code to check table with options. It's soo hard to add new checks and just looks bad. I need come up with better solution

window resizability?

Should library provide function to quickly allow/disallow window resizing as built-in solution?
In love. window is not resizeable by default, but to change it, user should use conf.lua or love.window.setMode(), which is long to type manually. Library might provide something like:
rs.windowResizeSwitch(). If you don't provide argument, it will simply act like switch, meaning it set true to false and false to true, internally using love.window.setMode(). If you provide true or false, then library will simply put that value.
Also, provide rs.init(options) argument for resizeability, to set true or false, or if nil then don't do anything.

Draw bars on canvas during rs.resize

Maybe I should draw bars on canvas during rs.resize() and draw single canvas during rs.stop().
Benefits:

• Less draw calls during rs.stop(). Single canvas draw vs 4 love.graphics.rectangle
• To draw bars, library would unpack rs table 16 times in love.draw(), which is 960 unpacks per second. Luajit probably optimize this, but, still, this is not good idea to do so. If we would move this to rs.resize, then when window is not resized, there will be 0 calls per second.

Downsides:

• Design of this library suck ass, and drawing bars literally on top of game to hide content behind it is stupid, but here we are.
  At least, users can easily change drawing method instead of built-in:

-- Scissors method 
rs.bars = false -- to disable bars rendering

And then during drawing scaled content:

rs.start()
 -- get scissors that were before
 local x, y, w, h = love.graphics.getScissor()
 love.graphics.setScissor(rs.getGameZone())
 -- draw stuff

 -- Return old scissors.
 love.graphics.setScissor(x, y, w, h)
rs.stop()

And done. To change color of "bars" you can simply change background color.

And for canvas:

rs.bars = false

local game_canvas = love.graphics.newCanvas(rs.gameWidth, rs.gameHeight)

love.draw = function()
  love.graphics.setCanvas(game_canvas)
  love.graphics.clear(0, 0, 0, 0)
  -- draw stuff
  love.graphics.setCanvas()
  rs.start()
    love.graphics.draw(game_canvas)
  rs.stop()
end

In overall, I think this small performance boost doesn't bring any downsides...

love.window.setMode result in failed love.resize

When called love.window.setMode, window do not update it size, so library will fail to update itself?
Probably will be good idea to wrap setMode into library and update it afterward to fix non updated window

[Docs] Add usage example with gamera/hump.camera

It would be appreciated if you documented on how to make this library work with gamera or hump.camera. There is a snippet of code on the forums that shows how to do this, but it didn't seem to work with the latest version of this library, to be specific, setting camera position doesn't work.

Nearest filtering as built-in function?

Provide function that allow to set filtering to nearest or linear simplier, then manually typing love.graphics.setDefaultFilter("nearest", "nearest")?
Maybe rs.setDefaultFilter(filterType)?