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.