LÖVE

What is the incentive for DPI scaled units by default instead of pixel units ?

I don't understand this choice, I expected the API to use pixel units because these parameters are not designed to be resolution independent in the first place. When we write "800x600", it doesn't hold any meaning about the screen size in meters. That's the role of the DPI/PPI (dots per inch / pixels per inch).

This way of doing things implies that 100 pixels have an implicit size in meters (or relative to readability, perceived distances), which may be true for a set of devices, but is probably the cause for many issues people experience with desktop managers / apps / games today. It may also bias algorithms relying on the true resolution if the developer is not aware of this feature (ex: rendering less details). I think drawing operations should never rely on pixels for size related things (like readability).

As an example, is the font system DPI scaled by default ? Or the device will lose quality on displayed text when the DPI increases ?

Edit: I was using an old LÖVE android version, so I thought it wasn't possible to disable this feature, but it's fine on 11.3. Thanks for the option.

I guess the idea is to develop using fixed numbers for the units, e.g. make a certain button always 40 units high, etc. and let the engine adapt that to pixels. I'm not too sold on it either, to be honest.

Pretty much all the major operating systems settled on the same way to expose keeping consistent spacing and sizing for apps when different devices of the same class have completely different pixel densities - that way is DPI scaled units, and it actually has little to do with real physical sizes in meters aside from being consistent. There has been some discussion about it here previously, and it's documented on the wiki, and developer guides for different operating systems eg macOS and iOS have explanations and rationales as well, if you're curious.

Imagic wrote: ↑Sat May 16, 2020 7:09 pm As an example, is the font system DPI scaled by default ? Or the device will lose quality on displayed text when the DPI increases ?

Font sizes are DPI-scaled, so they will appear crisp and sharp on a high pixel density display.

Thanks for the details.

To me, this should only be done at the application/user level and not at the engine level, so I would be stuck without the option to disable it. Just to say that it matters to give that freedom, whatever the consensus.

Imagic wrote: ↑Sun May 17, 2020 10:08 pm To me, this should only be done at the application/user level and not at the engine level, so I would be stuck without the option to disable it. Just to say that it matters to give that freedom, whatever the consensus.

You've always been able to use pixel units when needed through love.graphics.getPixelDimensions and friends, and to explicitly set the DPI scale of any asset (images or canvases or fonts) to whatever you want.

high dpi in general is also entirely opt-in (when you don't opt in, the OS deals with it completely on its own) - except on Android where SDL unfortunately doesn't properly support not opting in right now. When you opt in, you will need to support DPI scaling in some form or your app will look broken on different devices from your own - even if love didn't automatically do anything.

Old versions of love used to not automatically do anything, and it was not a very good experience for people who didn't have a variety of devices of different DPI scales to test on, because love was essentially broken by default when you opted in to high DPI (or ran on Android). Now it does the right thing by default most of the time, and you can easily opt in to doing a custom thing when you know you need to (via custom DPI scales for assets and canvases, for example). I think doing the right thing for the majority of situations by default is a good philosophy for a tool to have.

Of course, most people aren't used to thinking in terms of scaled units and are only really aware of pixels - but modern devices don't work like that anymore. Documentation and tutorials could certainly be improved for DPI scaling, but since love does the right thing by default for most situations, people don't have to think about it as much as they would need to otherwise (for shipping a game to real devices).

As a very simple example, the no-game screen doesn't need to have any explicit code for DPI scaling but still looks correct across all devices. It also loads high resolution images on high dpi devices which still have the exact same proportional sizing as low resolution images, with nothing more than a number changed in a table.

I still have bad memories of some older (non-love) games being barely usable on my retina display because they didn't know DPI scale existed and therefore had extremely tiny UI and buttons, despite opting into support of full retina resolution. These days there shouldn't be any excuse for a game being like that.

slime wrote: ↑Sun May 17, 2020 10:49 pm You've always been able to use pixel units when needed through love.graphics.getPixelDimensions and friends, and to explicitly set the DPI scale of any asset (images or canvases or fonts) to whatever you want.

Yes, but it increases the overall complexity for no benefits in my case.

slime wrote: ↑Sun May 17, 2020 10:49 pm you will need to support DPI scaling in some form or your app will look broken on different devices from your own - even if love didn't automatically do anything

I think the problem is more complex than a global DPI scale; that's why some games allow you to scale the GUI for example. Having it too big or too small are both an issue. I even had troubles getting good scaling of text/icons with Chromium and X11 while tweaking DPI stuff, probably why they added internal options for the text size (but it doesn't solve all the problems either).

I appreciate that LÖVE is easy to use by default, but can also be used in advanced ways (it's the philosophy I love about projects like Lua and LuaJIT). I probably would not have created this topic if I knew from the start that it was possible to disable this feature.