LÖVE

Hey there,

For Poppy I would like to use fonts installed in the system, this would remove the need to bundle a font with good unicode coverage.
This is especially important because the game has a chat system. (And I don't like the default love2d font, it seems to not scale up properly?)

My current solution is using a symlink to the system font in the games directory, this is a bit bad because it needs the user to create this link manually, or launch the game with a shell script etc. It also does not work when bundles as a love file, and love.filesystem can as far as I can tell not create any symlinks itself.

Accessing stuff outside of the game dir is awkward.
Quickest solution is to use luas io lib to make a copy of the file and place it in your data path.
Creating the junk there tho.

And you will also have to handle a different path for each of the OSes.
Let alone dealing with what to do if that font is missing.

I think the smartest solution is to just have your game check for a font file in the data path at the start, if there is one, use it, if not use the default. That way your players can change fonts on their own.

I am already doing this, but essentially it is a bad solution, most players will get the default font that isn't that usefull.

I don't mind much about different paths, on Haiku the path is quite easy to figure out with find_paths anyhow.

I suppose the only real solution is to add a c interface to get the fonts.

Haiku <- impressed.

Other solution: There are a few libs out here that let you edit loves file access method.
Basically currently the games zip and the user data dir are composed into one root folder for all love file operations.
It is possible to add more folders to that using luajits ffi and accessing the lib that creates the composed folder: physfs.

Zorg has a nice lib for that https://github.com/zorggn/love-fml
But if your target is haiku i wonder if it will work. I used it for one of my projects and it troubles me too on some systems.

nephele wrote: ↑Sat Jun 25, 2022 10:05 am This is especially important because the game has a chat system. (And I don't like the default love2d font, it seems to not scale up properly?)

I think that's related to how you use it. love.graphics.getFont does not have arguments. I think you want to use love.graphics.newFont instead. There's also Font:setFilter if you want it pixelated.

Ah, you are correct. My usage is wrong, fixed it, thanks!

BrotSagtMist wrote: ↑Sat Jun 25, 2022 1:56 pm Haiku <- impressed.

Other solution: There are a few libs out here that let you edit loves file access method.
Basically currently the games zip and the user data dir are composed into one root folder for all love file operations.
It is possible to add more folders to that using luajits ffi and accessing the lib that creates the composed folder: physfs.

Zorg has a nice lib for that https://github.com/zorggn/love-fml
But if your target is haiku i wonder if it will work. I used it for one of my projects and it troubles me too on some systems.

I will freely admit that that's a very hackish library
Another alternative is this one: https://github.com/EngineerSmith/nativefs

That said, next löve version will relax its filesystem limitations iirc, so these won't be needed either.

A quick read lets me think that nativefs is no solution to this problem tho. lg.newFont wont accept it without hacks either.

Derail:
This limitations where odd to begin with.
While i do totally agree that by default the engine should limit possible damage it can deal by preventing messing with the entire filesystem this is undermined by the presence of luas own IO lib.
Probably we need some kind of explicit failsafe here, eg a setting that needs to be set true willingly in order to enable full disk access. That gives me at least a little less worries when starting random homebrew games.

BrotSagtMist wrote: ↑Mon Jun 27, 2022 8:48 pm Probably we need some kind of explicit failsafe here, eg a setting that needs to be set true willingly in order to enable full disk access. That gives me at least a little less worries when starting random homebrew games.

yes, that failsafe is what windows and other OS-es already implement, and i hate it; thankfully with some tinkering i can force it off.

BrotSagtMist wrote: ↑Mon Jun 27, 2022 8:48 pm
Derail:
This limitations where odd to begin with.
While i do totally agree that by default the engine should limit possible damage it can deal by preventing messing with the entire filesystem this is undermined by the presence of luas own IO lib.
Probably we need some kind of explicit failsafe here, eg a setting that needs to be set true willingly in order to enable full disk access. That gives me at least a little less worries when starting random homebrew games.

It's a bit pointless to limit access to RO system files, those can't be deleted anyway. Windows protects it's files with permissions, as does MacOS.
FreeBSD for example also has specific flags you can set on files that mark them as protected so root can't (accidentally) delete them.

on Haiku it's just impossible to delete those files because they are not really there, just mounted from a RO package file (you could probably redo this or delete them, but not directly "accidentally" delete files in random system dirs)