LÖVE

Jasoco wrote:Though I'm not really interested in mobile gaming anymore unless Löve iOS can access the Made For iPhone API for external controllers.

It can, actually – I recently added that to SDL as part of my work to port it to tvOS (as tvOS is based on iOS and the MFi game controller code works for both operating systems).

That said, there aren't many people who actually use a controller with their iPhone, so you can't really make an app that requires it.

slime wrote:It can, actually – I recently added that to SDL as part of my work to port it to tvOS (as tvOS is based on iOS and the MFi game controller code works for both operating systems).

That said, there aren't many people who actually use a controller with their iPhone, so you can't really make an app that requires it.

You can't make an app on the App Store that requires it. But if Löve were on the App Store, we could still make games that require a controller.

Oh, and we should set up a package managment system IMHO.
Finding and aquiring libraries is not ideal at the moment

For me, before anything : a powerful debugging library (like love.debug.*) and a good profiling lib too

Rename Scancode to ScanCode

( Disclaimer: I'm not serious )

( Just a bit )

Scancode is accepted as one word.

slime wrote:Scancode is accepted as one word.

I know, I know ... it just looks ... weird to me

Rishavs wrote: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.

Alot of those things can be done with simple libraries

Can wish but never get!
Would like next version of Love to revert to 0.9's Shader orientation.
Two wrongs don't make it right.
The original problem was that love.graphics y axes was inverted, NOT the Shader's.
Now the rest of the world's shaders don't stand a chance of working in Love.
(GLSL is not the easiest language to learn.)
As xXxMoNkEyMaNxXx said "So sad"!

There are no plans to change LÖVE from its y-down (with y=0 at the top) by default coordinate system. It's working as intended. 0.9's shader coordinate system was always y-down by default (try outputting the texture coordinate values and see where 0,0 is and where 1,1 is!), it's just the pixel coordinate value that was buggy and didn't match anything else.

I don't think I know of any pixel shader code that actually depends on the coordinate system of the pixel coordinate value in shaders being 0 at the bottom – the most important thing is that it should be consistent with the coordinate system of the texture coordinate values.
It is in 0.10.0 (and it is in non-LÖVE programs, even ones with a y-up coordinate system), but it wasn't in previous LÖVE versions so you had to do some manual fiddling to get non-LÖVE shaders working right if they used that. Now you don't (as long as you use the pixel coordinate argument to the effect() function, and not gl_FragCoord – which you should always avoid).