Post-0.10.0 feature wishlist

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
User avatar
slime
Solid Snayke
Posts: 3129
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Post-0.10.0 feature wishlist

Post by slime »

BobbyJones asked me to post about planned directions for LÖVE after the latest release. Now that it's out, I'll list some things I'd like to see in future versions. Feel free to add your own thoughts!

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)
• API changes to reduce the number of (accidental) graphics performance problems people might encounter (issue #1106), and as a secondary goal to make it easier to have a fancier graphics backend and make it use newer APIs like Metal and Vulkan (not that that's a high priority).
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.
Last edited by slime on Sun Jul 16, 2017 12:41 am, edited 12 times in total.
User avatar
undef
Party member
Posts: 438
Joined: Mon Jun 10, 2013 3:09 pm
Location: Berlin
Contact:

Re: Post-0.10.0 feature wishlist

Post by undef »

Hey, those are all desirable changes, but one very important is missing - a web port.
I hope someone™ will get this running entirely one day via emscripten.
twitter | steam | indieDB

Check out quadrant on Steam!
gianmichele
Citizen
Posts: 63
Joined: Tue Jan 14, 2014 11:03 pm

Re: Post-0.10.0 feature wishlist

Post by gianmichele »

I second that. These are very nice proposals and I like the directions a lot.
I have been playing with the new version on iOS a lot (incredible what holidays can do!). While the workflow is not ok for a first version, it could be a lot smoother and have less steps.
For example instead of having to copy the file thorugh iTunes or open the .love file from Safari we could send it directly via network and wi-fi. That way you don't have to have the device physically connected and testing could be done quickly and easily directly on device. Ideally this would pave the way to deploy on multiple machines at the same time as well.

As far as mobile services like ads or gamecenter, it would probably be wise to implement each API separately and leave the user to create a common wrapper if needed. Something like love.ios.gamecenter, etc.

Hope this helps the discussion a bit.

Thanks for you hard work.
User avatar
leiradel
Party member
Posts: 184
Joined: Thu Mar 11, 2010 3:40 am
Location: Lisbon, Portugal

Re: Post-0.10.0 feature wishlist

Post by leiradel »

Hi,

I'd love to see a camera module implemented in LÖVE. I've tried it myself (viewtopic.php?f=4&t=3632) but it was Windows-specific.

After that I've used libvidcap to grab frames from cameras in projects unrelated to LÖVE. I still have some source code lying around, including bindings to Lua.

I could try to implement it myself, with some support from LÖVE developers.

Cheers,

Andre
User avatar
hryx
Party member
Posts: 110
Joined: Mon Mar 29, 2010 2:28 am
Location: SF<CA<USA

Re: Post-0.10.0 feature wishlist

Post by hryx »

TLS support for sure. At this point it feels wacko to offer networking without encryption.

Outside of actual features: In my dreamland the project would move project to GitHub. I imagine that'd be a painful process, but the opportunities for visibility and new developers would probably jump way up in that environment. (Please don't slap me if this one is a FAQ.)
User avatar
pgimeno
Party member
Posts: 3541
Joined: Sun Oct 18, 2015 2:58 pm

Re: Post-0.10.0 feature wishlist

Post by pgimeno »

slime wrote:I want to make [wiki]love.graphics.newScreenshot[/wiki] and [wiki]Canvas:newImageData[/wiki] be asynchronous so they don't stall everything when they're called.
Image
User avatar
HugoBDesigner
Party member
Posts: 403
Joined: Mon Feb 24, 2014 6:54 pm
Location: Above the Pocket Dimension
Contact:

Re: Post-0.10.0 feature wishlist

Post by HugoBDesigner »

I absolutely LÖVED the 0.10.0 update, especially on the file management area. But, in my humble opinion, there's only one, single feature that, if added, would make LÖVE absolutely PERFECT: window transparency. Seriously, if you guys could pull that off, I'd code for LÖVE like 24/7 :awesome:

EDIT: Oh, opening other .love files would be really cool too, so users could have pop-up screens and such.
@HugoBDesigner - Twitter
HugoBDesigner - Blog
bobbyjones
Party member
Posts: 730
Joined: Sat Apr 26, 2014 7:46 pm

Re: Post-0.10.0 feature wishlist

Post by bobbyjones »

Opening other .loves is already possible using pure lua code. I think a more useful thing would be multiple windows support.
jjmafiae
Party member
Posts: 1331
Joined: Tue Jul 24, 2012 8:22 am

Re: Post-0.10.0 feature wishlist

Post by jjmafiae »

The audio API definitely needs some work, it took me like 2 hours to figure out how to use the positional audio. Another feature I wouldn't mind is audio compression so I can make voice chat in multiplayer games
User avatar
Rishavs
Party member
Posts: 103
Joined: Sat Oct 17, 2009 5:29 am
Contact:

Re: Post-0.10.0 feature wishlist

Post by Rishavs »

I know that you guys want to keep love as a basic framework, but i really feel that for love to be the best library for new users, it has to a "batteries included" distribution.

As such, I hope that love will have its own default modules for:
  • Tilemap support
    Scenegraph support
    Basic UI support
    Sprite based Animation support
    Camera support
    Gamestate support
    Profiling Support
This will ensure that the most important modules that are used in almost all 2d games are there and will always be supported. Of course, people can always roll their own if they want.

A good way to do is to just integrate any well used and made community module into the love code.
Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests