karolek wrote: ↑

Thu Oct 11, 2018 6:56 am

Bitbucket also uses git, you know. So there's no difference in usage from console or any git client

LÖVE's repository uses Mercurial.

Most C++ classes aren't exported publicly from the dll I think. In ImageData::setPixel's case, it's actually a lot faster to call ImageData:mapPixel (from Lua) than setPixel, because that has a very fast FFI implementation.

What do you want to do in C++ with love's API?

Windows 10 version 1809 changed the behaviour of an API love uses during startup, unfortunately. There's a build with a fix here until an official release happens: https://bitbucket.org/rude/love/issues/ ... t-48155677

It was removed because it's incompatible with different types of images, it also allows love to reduce its memory usage in the future with different rendering backends. A super easy way to access imagedata given an image, with minimal code changes, would be to store the imagedata in a table using th...

You can (and have always been able to) create an image using an imagedata, and just reuse the imagedata as you see fit.

Apparently, Apple is deprecated OpenGL to force developers to move towards Metal. How will that affect Love2d in the medium and long term? Medium-longish term, not at all. Apple formally deprecated legacy OpenGL on macOS like 5 years ago, but it still works. I expect Core Profile OpenGL will contin...

Automatically batched vertices are transformed on the CPU, so TransformMatrix doesn't include the current love.graphics transform in auto-batched draws.

Indeed, almost every love API that accepts a number stores the number in something less precise than a 64 bit float. That's a lot of APIs.

I don't see what else changed that could be causing it, so it'd be nice to be able to check. The internals of love.graphics have been substantially rewritten since 0.10. It takes advantage of more OpenGL 3+ features when available than before, which runs more risk of encountering bugs inside graphi...