search

keharriso / love-nuklear

Lightweight immediate mode GUI for LÖVE games
MIT License
345 stars 32 forks source link

love transforms don't work properly #9

Closed karai17 closed 5 years ago

karai17 commented 7 years ago

When using love.graphics.[translate/rotate/scale], bad things happen. Strange mask clipping, input isn't properly transformed, etc. The use case I am trying to implement is the ability to pan the whole UI around, or zoom in and out.

keharriso commented 7 years ago

Unfortunately, I'm not sure how to make Nuklear behave with the love.graphics transformations. There is no way to get LOVE's current transformation, so it's impossible to apply it to the UI.

The simplest solution would be to add separate nk.[translate/rotate/scale] functions, but even that has problems. Internally, Nuklear generates draw commands, many of which contain axis-aligned rectangles. There is no support for rotated rectangles, so nk.rotate would be difficult to implement. I think if I switch LOVE-Nuklear to render to an internal canvas, it would be possible, but would mean that there can only be one transformation that applies to the entire UI at once (which I don't think is really that big of a problem).

karai17 commented 7 years ago

I think a single set of transforms for the whole UI makes sense considering nk.draw is a single function. It would be difficult to apply several different transforms to that unless you were thinking of applying transforms in update when creating the UI elements.

However this brings up a question. Is it possible to them have two UI instances? One for static elements and one for transformable elements? Or if they as simple as 

local nk = require "nuklear"
local mk = require "nuklear"

?

karai17 commented 7 years ago

Perhaps nk.init should create an instance?

local static_ui = nk.init()

keharriso commented 7 years ago

Perhaps nk.init should create an instance?

local static_ui = nk.init()

Thanks for the suggestion, that makes a lot of sense. I'll try to have that done for v2.0, ideally alongside the transformation functions (no promises on a timeline).

karai17 commented 7 years ago

awesome, I look forward to it!

keharriso commented 7 years ago

Attached are the beta binaries for v2.0. You can create multiple contexts and apply transformations to each of them. You can see the updated example here. If you have any problems, let me know. Once any kinks are worked out, I'll make a proper release and update the documentation. love-nuklear-2.0b1-linux32.zip love-nuklear-2.0b1-linux64.zip love-nuklear-2.0b1-win32.zip love-nuklear-2.0b1-win64.zip

karai17 commented 7 years ago

These seem to be working mostly fine. We're having an issue where the coordinates are not transformed when polling them, so for instance having non-nuklear elements attack to the nuklear elements doesn't work.

keharriso commented 7 years ago

Thanks for continuing to share. Is it possible to isolate the problem as a .love file I can use to fix it?

karai17 commented 7 years ago

https://my.mixtape.moe/bbvsbo.love

In this example, I am printing out the values of the window's position. For some reason, X is coming up as nan and Y is 4 pixels off... But more notably, when you click and drag the graph around, you will note that the X and Y positions being reported do not change. This affects rotate and scale, too.

keharriso commented 5 years ago

If the problems still exist with the latest version, let me know and post an example.

keharriso commented 5 years ago

Part of the problem is you want to use ui:windowGetPosition() instead of ui:widgetPosition() (the latter adds padding pixels). About the positions not changing: if you want to do local graphics calls you should use love.graphics.translate(...) with the same arguments you give to ui:translate. Same for rotate and scale. Hopefully that helps.