Specifically, the third-party libraries love uses on Windows are built using CMake when love is built, but SDL's new joystick code which includes better Switch Pro controller support doesn't get compiled in when you build SDL with CMake. I'll need to modify SDL's CMake generator file to fix it.

Wine probably isn't a good platform to test graphics on - emulation layers come with all sorts of their own graphics problems which don't exist on the real deal.

The window is automatically created by default in love 11. Your love.conf has the line "t.window = nil" in it, which stops that from happening. If you remove that line it should be automatically created. You can also call love.window.setMode to (re)create the window in main.lua (before calling any l...

It never worked to use love.graphics without a window, since the window has always created an OpenGL context (partly since an SDL OpenGL context requires a window to be created in the first place - because on various platforms an OpenGL context and a renderable backbuffer are tied together, and the ...

Great. So I should just stick to 11.0 for now? (I don't have 11.1. Just 11.2 which ignores vsync no matter what value I use because of the bug) 11.0 has worked perfectly for me so far. If 11.1 still works, where can I find that? (I keep every Löve version I download for testing older projects when ...

Is there no way to implement (in future Löve version) an option to globally set a DPI scale? Not really for the backbuffer, since on some operating systems it's either off (and behaves as described above, with the OS doing scaling itself) or completely on, with it always using the size and units pr...

my main issue is that DPI scaling is a confusing abstraction you can't disable on one platform for some reason (why is it just android, anyway?) SDL hasn't implemented DPI-scaling emulation on Android yet (whereas it has on iOS and macOS). When highdpi is disabled, the backbuffer itself (and all un...

To round to the correct pixel, avoiding rounding issues, rather than using fromPixels(round(toPixels(value))) every time. I can see some potential use cases for pixel snapping, but also some use cases that are better solved different ways (for example extruding / padding sprite sheets.) What do you...

In what situations - aside from sending coordinates to shaders that use the pixel coordinate argument and operating on imagedata - do you need to operate on pixels instead of DPI-scaled units? (the PixelDimensions set of functions/methods are handy for those cases.)

It's not arbitrary, your OS and device manufacturer chose it for all apps and they expect your app to respect it as well. It also allows your app to look consistent across different devices with different DPI scale factors.