Page 16 of 18

Re: Post-0.10.0 feature wishlist

Posted: Wed Dec 07, 2016 10:27 am
by 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

Re: Post-0.10.0 feature wishlist

Posted: Thu Dec 08, 2016 7:04 am
by raidho36
You could just use a stack for this, no linked list needed. And it is faster still.

Re: Post-0.10.0 feature wishlist

Posted: Thu Jan 05, 2017 9:34 am
by 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.

Re: Post-0.10.0 feature wishlist

Posted: Thu Jan 05, 2017 10:07 am
by zorg
drunken_munki wrote:(...)
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.

Re: Post-0.10.0 feature wishlist

Posted: Thu Jan 05, 2017 2:05 pm
by 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.

Re: Post-0.10.0 feature wishlist

Posted: Thu Jan 05, 2017 3:23 pm
by Ulydev
kikito wrote: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.

Re: Post-0.10.0 feature wishlist

Posted: Thu Jan 05, 2017 4:05 pm
by 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!

Re: Post-0.10.0 feature wishlist

Posted: Thu Jan 05, 2017 4:47 pm
by 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.

Re: Post-0.10.0 feature wishlist

Posted: Thu Jan 05, 2017 5:03 pm
by kikito
slime wrote: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 ^^

Make Shader:send not throw an error, but return a status instead.

Posted: Thu Jan 05, 2017 9:50 pm
by 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.