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.

std::bad_alloc is just a generic "out of memory" message – LÖVE's internal C++ code tries to allocate some memory but either the program has already run out of memory by that point, or you're making it allocate a massive amount of memory due to the arguments you pass in to the function that's output...

Yes, thank you. :) After testing for a bit I believe this will be fixed in love 11.3 because it uses an updated version of OpenAL Soft. For anyone else reading, you can grab a WIP 32 bit build of love 11.3 for windows here: https://ci.appveyor.com/api/buildjobs/xs70l25lnyoiuqur/artifacts/build%2Flov...