Note that this is not an official list of things we will definitely do, just some of my own personal thoughts at the moment. Also, many of them aren't very fleshed out and their details will probably change over time, and some would take a lot longer to implement than others.
LÖVE's developers only work on it in our spare time, and some topics interest us more than others (e.g. I'm more of a graphics guy than an audio guy) – code contributions and such on Bitbucket are always welcome!
• Mobile-specific APIs for in-app-purchases and ads, as optional extensions (e.g. through require). I don't do any Android development, so if I were to implement part of this I still couldn't do all of it.
• Improved development experience on iOS. It needs more documentation and tutorials, and I want to try to put LÖVE on the App Store eventually (although it might not happen due to the App Store rules.)
• Better APIs for mobile accelerometers and gyroscopes. The current "accelerometer-as-joystick" deal in 0.10.0 is a bit of a hack, and doesn't expose the device's gyroscope (rotation rate sensor) at all. Ideally I'd implement new APIs in SDL2 for this, and then use the new SDL APIs in LÖVE.
• Accelerometer and gyroscope APIs in Joystick objects. There are a fair number of gamepads and other joysticks that actually have those sensors in them now, but LÖVE (and SDL) don't allow you to get that information. That'd be another thing that I would add to SDL2 itself, ideally.
• Apple TV / tvOS support. I don't own a new Apple TV, but I did already port most of SDL2 to it. tvOS has a restriction where you can't do plain filesystem writes though (everything must go through the cloud), which is a major thing to have to design around for a LÖVE port.
• LuaSec or another SSL/TLS API (issue #363). LÖVE has http support through luasocket, but no built-in https / tls capabilities yet, and HTTPS is becoming basically ubiquitous.
• Other video formats. Ogg Theora isn't exactly the best video format, but there aren't many that have open-source implementations that are patent free. VP8/VP9 (webm) might be an option, and possibly an h.264 implementation only on mobile devices.
✓ Improved handling of high-dpi / retina (issue #1122). The way it is right now, it's hard to figure out how to handle it properly without doing some testing on devices that support it. I'm sure LÖVE could be made to handle some of the annoying bits itself, but I have to figure out what the best way to do that is without adding too many surprising corner cases.
• A "virtual backbuffer" (issue #1101) that would be automatically used in some situations. This would let LÖVE use different resolutions when fullscreen-desktop mode is used, and together with some improvements to SDL it would allow highdpi mode on Windows. It would also let gamma correction work properly on Android.
• Shape and line (batch) objects (issue #891). These would be similar to Text objects and SpriteBatches – although filled shape batch objects will be much easier to implement than line batches in that manner, so filled shapes might come first.
The main reason to add something like this is mobile performance – with SpriteBatches and Text objects you can get pretty great performance on mobile devices when you render a lot of sprites and text, but the current shape drawing functions, while easy to use, are pretty slow if you want to draw a lot of shapes.
The API could be something like:
Code: Select all
shapes = love.graphics.newShapes()
shapes:addCircle(x, y, radius)
shapes:addRectangle(x, y, w, h)
shapes:addPolygon(x1, y1, x2, y2, ...)
love.graphics.draw(shapes)
I want to make love.graphics.newScreenshot and Canvas:newImageData be asynchronous so they don't stall everything when they're called. I also might want to merge love.graphics.clear into love.graphics.setCanvas somehow (related to the next point too), and see if I can find a way to eliminate some API uses that make things slow for reasons that are only apparent if you know graphics drivers (there's an example in the Bitbucket issue report.)
• Reducing the global state in love.graphics (see this thread for some discussion) – but without making the graphics APIs less simple to learn and use. A lot of experimentation will probably have to be done for this.
✓ Optional usage of newer GLSL (shading language) versions in code, while keeping the current GLSL 1.20 / GLSL ES 1.00 as the default. Some people implementing advanced rendering techniques with LÖVE have need of more recent shading language versions which expose more features, but those versions don't work on some graphics cards (on mobile devices especially) that LÖVE supports.
Unfortunately supporting both older and newer GLSL versions at once like that is harder than it seems, especially since I want to prevent code written for GLSL 1.20 that accidentally only works on systems that support newer GLSL versions, but I'm investigating some options.
✓ Support for different Image and ImageData pixel formats, including floating-point formats (e.g. storing arbitrary number values in pixels). This can be useful for advanced rendering techniques and similar things, but said formats aren't always supported by all of the graphics hardware that LÖVE supports. Also, LÖVE's APIs are all designed for "byte" color components that are in the range of [0, 255], so it's a bit awkward to add things that require different value ranges now.
• Easier-to-use audio APIs. Right now audio data is tightly coupled with actual positional playback (aside from Source:clone), so playing a Source multiple times at once is less intuitive than it could be, for example. The audio API in general is also thinly documented and some of it requires trial-and-error to figure out.
✓ Audio effects / filters (issue #173). OpenAL-Soft's EFX API has some unfortunate restrictions with this (but at least it's exposed), and I have a hard time reasoning about APIs for it that would be simple and useful.
✓ Custom streaming / queuable audio sources (issue #1017). This would be useful for procedural sound generation and maybe for the next point:
✓ Microphone input (issue #1). Ideally I'd want a microphone API that's actually useful/usable for real world use cases, which I have no experience with.
