I'm confused by all this argument about return values vs. erroring. If you want shader:send() to return a status code instead of erroring, why not just use pcall()? Doesn't that accomplish what folks are asking for? It seems totally reasonable to me that the default behavior is to error so the devel...

Now to implement something similar for Android... Given enough effort that could show up in the next minor version. That's what I'm currently working on. Right now, I'm trying to figure out how to add the appropriate billing helper module and wrap my head around the Android dev environment. Based o...

Okay, but one could just not use the modal messagebox function, and just implement a visual one with löve itself, that way it may not block. Actually no, Apple doesn't let you do that. Presumably in order to prevent apps from making deceptive or confusing purchase dialogs (or stealing the user's cr...

Folks following this thread might want to take a look at this post I made about implementing in-app purchasing for iOS.

Is there a reason it's not a dynamically loaded library and a FFI wrapper? I don't feel like using a whole custom build just to get this one orthogonal feature. Doing IAP requires the use of native Apple APIs and frameworks, and I don't know whether it would be possible to access those through FFI ...

I recently released a game that uses my own implementation of in-app purchasing for löve on iOS. I figured other people might benefit from looking at or using my code. This is a modification of the löve 0.10.1 source code. The basic structure is a pair of new files (InAppPurchase.h/m) that define an...

@Spill you cannot do that since the graphics interface (opengl) requires the data be in an array (a SpriteBatch is basically a VBO: https://en.wikipedia.org/wiki/Vertex_Buffer_Object). How do ParticleSystems do efficient batch rendering? I was skimming through the source code and I saw that they're...

If you want it you could write a function that turns {key = value} tables into :setKey(value) calls with ease: function setAll(subject, table) for k, v in pairs(table) do if type(v) == "table" then subj["set"..k](subj, unpack(v)) else subj["set"..k](subj, v) end end en...

Yeah, it would be nice to make particle systems more flexible and less verbose, although I'm not sure what the best way to go about it would be while maintaining adequate performance. For less verbose, I think it would be nice if the API were more table-with-keywords-oriented instead of many-functi...

Interesting, thanks for testing it. I figured tables and functions would have different memory overhead, but wasn't sure which would come out on top. I do think it's fairly readable, but that's just a matter of opinion. I'm still curious how two vector implementations would compare instead of just ...