Post-0.10.0 feature wishlist

[buckle2000]

Nape Physics Engine, has its own gc system.

Unused vectors are stored in a linked list, and when a new vector is needed, an old vector will be picked instead.

This implementation is really fast.

http://napephys.com/
http://napephys.com/docs/types/nape/geom/Vec2List.html
http://napephys.com/help/manual.html#Object_Pooling

[raidho36]

You could just use a stack for this, no linked list needed. And it is faster still.

[drunken_munki]

I see SpriteBatch:setColor() which I just figured out how to use in my game.

What I'm looking at, is it possible to have SpriteBatch:setBlendMode() ?

I'm thinking it's not practicle for most blend modes, but what about just "alpha", "add" and "subtract"; I mean, is there a technical limitation to prevent this from being implemented?

Cheers big ears.

[zorg]

(...)

It may or may not be practical, but iirc the colors work as (extra) vertex attributes for each defined sprite in the batch; as far as i know, you can't set the blendMode like that. (Or at the least, you can't have separate blendmodes in one draw call, which is i think what spritebatches do) This is something probably relevant that i've found.

[kikito]

I'm beginning to think that an official "love-maker" would be a good idea. There have been some heroic unofficial attempts at creating a script for doing this in the past, but it's still a pain point for me.

I also would love it very much if LÖVE was smart enough to handle .love files made by compressing a folder instead of a list of files.

[Ulydev]

I'm beginning to think that an official "love-maker" would be a good idea. There have been some heroic unofficial attempts at creating a script for doing this in the past, but it's still a pain point for me.

I also would love it very much if LÖVE was smart enough to handle .love files made by compressing a folder instead of a list of files.

Yes and yes, definitely. I think we need an official, actively supported tool for packaging. There are too many tools out there that die almost as soon as they are made.

[gianmichele]

+1

It would be great to have some sort of command line options to handle packaging properly, with all the icons (iOS and adroid alone need a lot of them) and maybe a simple initial project creation. A few examples:

love create MyProject -p ios,adroid
love create MyProject -p win,osx,linux
love package MyProject -p ios,osx

Still talking about workflow, on iOS you need to copy the love file either via iTunes or open it through Safari. It would be aweome if you could specify a network storage or an address where you could pick up the .love file you want. This way one could cut quite a few steps in the build/test process (zip the file, upload somewhere, open safari, run in love).
Even better, considering the command line tool mentioned before, something that could push changes to device via network:

love serve MyProject -ip 192.168.1.10

I believe Corona is doing something similar now: https://docs.coronalabs.com/guide/distr ... liveBuild/

Keep loving!

[slime]

Keep in mind love is open source and anyone is welcome to contribute! I don't really have the capacity to significantly improve distribution workflow myself, right now.

[kikito]

Keep in mind love is open source and anyone is welcome to contribute! I don't really have the capacity to significantly improve distribution workflow myself, right now.

I can totally sympathise. My free time has diminished dignificantly in the recent months, and my open source projects are stalling a bit.

But wishes, like love, are free

[pgimeno]

The rationale is that it's worse to have the code work flawlessly in your computer, and then crash when the program is made public (case in point), than to have a hard time debugging shader code because of a mistyped variable, because when it works, it will (in principle) work for everyone.

Also, the status code provides debuggability.