Upcoming features for LOVE 0.6.0

[rude]

I've started, though it's by no means complete. I'll keep updating.

[Tabasco]

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!

[Xcmd]

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.

[bartbes]

We thought about changing that, but it didn't work out, the internals relied on the old system too much.

[Xcmd]

It's a matter of semantics anyway.

[Zorbatron]

I've started, though it's by no means complete. I'll keep updating.

Hey, thanks alot for that.

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]

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.

[Igmon]

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

[ecliptic]

Awesomeness, can't wait!

[Tenoch]

In regards to the physics changes, how are you dealing with auto scaling? Are all units of measurement pretty much use pixels?

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):

Box2D is tuned for MKS units. Keep the size of moving objects roughly between 0.1 and 10 meters.

So, with default factor, between 3 and 300 pixels.

Not sure what you mean by "Is there also conversion with the x/y axis?"