LÖVE

I'm starting now a project that will be quite serious, something that will probably be put on Android Market someday. I'm just wondering what graphics techniques I should be using, based on when and how well they will be implemented in love-android. So basically I'm wondering

1. Will framebuffers be implemented? And if so, is this a high priority? Will it be fast/efficient?
2. Do SpriteBatches work now? If not, will they be implemented? Is so, when? And will they work well?

Drawing everything from scratch every frame kind of sucks. Especially for a cell phone.

Since the native-c love-android is making good progress i'm currently not working on the java-based version (apk download)
As far as i know the native-c version will have all the standard love features available as soon as compile & opengl/library issues are resolved.
(not sure on box2d physics and luasocket, since they are external libs)

SpriteBatches : java : i checked, currently not implemented.

When you say "all standard love features", does that include SpirteBatches and/or Framebuffers? Because Framebuffers aren't supported on all computers even, it depends on the OpenGL implementation.

I just want to know what methods I should use in my game. I'm leaning towards SpriteBatches but it'd be nice to hear an "official" word on which method is the most supported one, or whatever.

Native-love:
Framebuffers should be supported, the code is ported but I am not sure if we tested it already.
OpenGL ES is version 1.1 for now, so we cannot support shaders for now. Maybe I will port the code to 2.0 if necessary or if it is required to add some cool features.
lua-sockets should be supported (requires Internet-permission).
Box2D should be supported.
Since SpriteBatches are a standard feature, they should work.

Please check all features you need as soon as we release a native-love-android, so that we are able to fix all things that do not work. We aim to support all features of Love, but we might have some limitations, e.g. many embedded GPUs require texture sizes to be power of two (which is only true for exotic PC hardware like old Intel GPUs).

I'm not sure what love source you are using, but 0.8.0 does automatic padding (again).

We use 0.72, we decided to start with a stable release.

Well, PO2 is kind of simple to fix. I'm worried mainly because not all computers support Framebuffers and SpriteBatches. I'm currently writing this from a netbook that doesn't support SpriteBatches.

LÖVE 0.8 also has a software fallback for SpriteBatches. If they don't work in native love-android, perhaps the fallback could be implemented.

Well, framebuffers is a standard extension für OpenGL ES 1.x and a standard feature in 2.0. Since all recent handsets support 2.0, they do support framebuffers.
SpriteBatches can be implemented by downloading all data to GPU (at least you can accelerate it a lot), so there should be a half-software work-around. This might need some shader things, but switching to OpenGL ES 2.0 should not be a problem.

Pretty much all computers do support the 0.8.0 implementation of spritebatches - without the fallback.The previous versions exploded on intel cards because intel cards required the use of something that was functionally identical but had a slightly different name.

I believe (but I'm not positive) that everything which supports OpenGL ES 2.0 will also support VBOs, which are the backend of spritebatches.

ghoulsblade wrote:Since the native-c love-android is making good progress i'm currently not working on the java-based version (apk download)
As far as i know the native-c version will have all the standard love features available as soon as compile & opengl/library issues are resolved.
(not sure on box2d physics and luasocket, since they are external libs)

SpriteBatches : java : i checked, currently not implemented.

Shouldn't luasocket be provided with the lua interpreter? Or perhaps it will have to be ported to work with Androids application framework? I'm assuming theres a port for box2D to Android, possibly that could be dropped in as a replacement with minimal code change? If not then I would think porting Box2D to android wouldn't be overly complicated seeing as Box2D doesn't have many(if any) dependencies.

I realize these are probably 2 things that aren't of primary concern right now, but I was just curious as to how it will be done. I've never developed for android so my assumptions could be completely wrong.