Upcoming features for LOVE 0.6.0
Re: Upcoming features for LOVE 0.6.0
I've started, though it's by no means complete. I'll keep updating.
Re: Upcoming features for LOVE 0.6.0
This looks (more) awesome.
I haven't done much in love lately, but I'm really looking forward to 0.6.0.
Thanks for your hard work and dedication!
I haven't done much in love lately, but I'm really looking forward to 0.6.0.
Thanks for your hard work and dedication!
Re: Upcoming features for LOVE 0.6.0
I like the more intuitive file-handling, for sure. Although I'm still of the personal opinion that "love.filesystem.newFile" indicates the creation of a file, not a file handler. But I'm probably thinking about it wrong.
We don't borrow, we don't read, we don't rent, we don't lease, we take the minds!
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Upcoming features for LOVE 0.6.0
We thought about changing that, but it didn't work out, the internals relied on the old system too much.
Re: Upcoming features for LOVE 0.6.0
It's a matter of semantics anyway.
We don't borrow, we don't read, we don't rent, we don't lease, we take the minds!
Re: Upcoming features for LOVE 0.6.0
Hey, thanks alot for that.rude wrote:I've started, though it's by no means complete. I'll keep updating.
A question though, why was love.native created? What problem is it meant to solve? I'm just slightly confused on its usefulness, why have C code compiled at runtime when you can compile librarys and link them?
And, please, I think alot of people would agree that the spritebatch/vertex buffers would be awesome to have. I know they would help speed things up remarkably in my current framework. I was actually thinking about trying to write a batch sprite deal myself. I just don't know why love.native is so important is all.
Also, won't moving the callbacks (draw,load,update,ect) to lua slow down the game a bit? Wouldn't it be better to just keep them C/C++ side?
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Upcoming features for LOVE 0.6.0
Love.native has an advantage over compiled libs, cross-platformness. Anyway, I already replied in the thread about that.
And maybe moving the main loop (yes, that's all that has changed, just the main loop) will slow it down by a TINY (oops, wrong size ) amount, this won't be performance-critical and allows the user/developer to change it, providing more flexibility.
And maybe moving the main loop (yes, that's all that has changed, just the main loop) will slow it down by a TINY (oops, wrong size ) amount, this won't be performance-critical and allows the user/developer to change it, providing more flexibility.
Re: Upcoming features for LOVE 0.6.0
In regards to the physics changes, how are you dealing with auto scaling? Are all units of measurement pretty much use pixels? Is there also conversion with the x/y axis? If so, will there be an option to use the native unit of measurement and axis? I'm just curious as I've been using unit space for the objects and then converting it to pixel space just during rendering. I'm trying to anticipate any changes that need to be made once love 0.6.0 arrives. I also assume it's using the latest box2D version? :p
Also for vertex buffer, I'm guessing the interface is pretty much the way it works with 3d api? Where you create a buffer; stuff it with position, color, and texture position; then on render, register it in the gpu along with what texture to use; and finally provide it with a matrix transformation...? Just curious.
Thanks for the update, all of them are quite..."love"ly
Also for vertex buffer, I'm guessing the interface is pretty much the way it works with 3d api? Where you create a buffer; stuff it with position, color, and texture position; then on render, register it in the gpu along with what texture to use; and finally provide it with a matrix transformation...? Just curious.
Thanks for the update, all of them are quite..."love"ly
Re: Upcoming features for LOVE 0.6.0
Awesomeness, can't wait!
Re: Upcoming features for LOVE 0.6.0
Scaling is done by specifying the factor between Box2D's meters, and whichever unit you're going to use in all love.physics functions. You can for instance, as you suggested, feed in pixels, so it fits directly your drawing routines. The default factor is currently 30 pixels for one meter. You'll be able to change this, but keep in mind (quoting Box2D's doc):Igmon wrote:In regards to the physics changes, how are you dealing with auto scaling? Are all units of measurement pretty much use pixels?
So, with default factor, between 3 and 300 pixels.Box2D is tuned for MKS units. Keep the size of moving objects roughly between 0.1 and 10 meters.
Not sure what you mean by "Is there also conversion with the x/y axis?"
"When in doubt, use brute force." Ken Thompson
Who is online
Users browsing this forum: No registered users and 12 guests