LÖVE

slime wrote: ↑Sun Oct 27, 2019 3:45 pm This release contains a few new features and many bugfixes-...
...and a major performance fix ... integrated Intel GPU-based Windows systems.

Just tested on my integrated intel gpu: It is a GREAT step forward. The GPU workload is drastically reduced. Congratulations!

Keep up the good work.

Hi! It looks like liblove-11.3.so is distributed unstripped in the Linux x86_64 and i686 binaries. That's why the tar.gz and AppImage files are ~15MB bigger now than in 11.2 before:
I've checked that 'liblove-11.3.so' is ~49 MB in the Linux binaries and stripping gives me a ~5 MB file again, like the one in the 11.2 release.

phoyd wrote: ↑Mon Oct 28, 2019 4:05 pm Hi! It looks like liblove-11.3.so is distributed unstripped in the Linux x86_64 and i686 binaries.

Oops, you're completely right. I somehow managed to strip every binary except liblove. I've reuploaded the stripped (but otherwise identical) versions.

The LÖVE app on the Google Play store has been updated to 11.3 (from 0.10.2 previously): https://play.google.com/store/apps/deta ... 2d.android
Microphone recording support is disabled on the Google Play version, but it will work if the APK is used instead.

Nice! The new support for using integer/fp color values makes things a lot easier, especially getting old bits of code to run again.

One small request. Now that Raspberry pi 4 is out and the standard Raspbian uses OpenGL accelerated drivers by default, is it possible to include the armhf format as part of the standard releases? The Pi 4 is specced quite similar to the Nintendo Switch, so you would think it would be a great development target for love2d.

MachineCode wrote: ↑Wed Oct 30, 2019 5:47 am One small request. Now that Raspberry pi 4 is out and the standard Raspbian uses OpenGL accelerated drivers by default, is it possible to include the armhf format as part of the standard releases?

The ppa already contains armhf builds. Unfortunately I don't have access to a decently-specced arm machine to (regularly) build love, so AppImages, especially nightly AppImages, simply take too long to build.

Am I wrong or wasn't there an option to choose whether you want VSync to cap to 60 or 30FPS if you wanted in 11.2? I can't find it on the Wiki. Did I dream that up? Did I misunderstand? And yes I do know about the "hacky" methods where you use math to set the sleep time. I was hoping for something part of it.

Setting vsync = 0 turns vsync off, vsync = 1 syncs every monitor refresh (60fps on a 60hz monitor), and vsync = 2 syncs every other monitor refresh (30fps on a 60hz monitor).

My primary monitor is 144hz, so vsync=1 makes a game run at 144fps and vsync=2 makes a game run at 72fps, on my system.

slime wrote: ↑Wed Oct 30, 2019 9:26 pm Setting vsync = 0 turns vsync off, vsync = 1 syncs every monitor refresh (60fps on a 60hz monitor), and vsync = 2 syncs every other monitor refresh (30fps on a 60hz monitor).

My primary monitor is 144hz, so vsync=1 makes a game run at 144fps and vsync=2 makes a game run at 72fps, on my system.

Hmm because I try setting to 2 and I still get 60FPS on my MacBook Pro. I thought maybe I could force it to a lower frame rate which would have been good for some of my 3D projects that benefit from a little more than 1/60th of a second by forcing them to 1/30th to keep it smooth. A little breathing room.

Either way it's not working for me. I'm setting it through setMode with vsync=2. Using 0 does turn it off but using both 1 and 2 does 60. So I'm so confused. lol

It looks like Apple doesn't implement every-other-refresh vsync for their OpenGL vsync APIs on modern macOS. I have a memory of it working in the past on macOS, but their documentation doesn't say it will work either, so maybe it never did.