Page 1 of 4

API Wars

Posted: Mon Dec 01, 2008 1:33 am
by rude
It's about time I list the biggest potential API inconsistencies, and/or things that possibly should be changed to make the life of future LÖVE users better.

I'm posting this so you can state your opinion, if you have one. ^^

1 Global Callbacks

Right now, callbacks reside in the global table. This should probably move to inside the love-table. Reason: having everything inside the love-table makes LÖVE cleaner and more library-like. This should not represent a problem for anyone, because (a) it involves only minor refactoring, and (b) you can control the main loop in the next version anyway. Also, load() currently conflicts with the standard load() function in Lua, which it shouldn't.

Code: Select all

-- Before
function load()
end

-- After
function love.load()
end
2 Degrees vs Radians

LÖVE currently uses degrees because OpenGL uses degrees. The problem is that the standard math library uses radians, which means that users must convert between deg/rad. Most people (including me) find degrees easier to use, but I would personally much rather use just radians than keep converting all the time. Changing the standard math library is, of course, not an option.

3 Input Device Enumeration

We need a more scalable system for multiple input devices. Currently, there's an inconsistency in how joysticks and mouse/keyboard work. Multiple devices should be supported for love.keyboard, mouse and joystick. Not sure how to handle this yet, but it needs to be dealt with.


There are many other minor things, but these are the three most important ones.

(WARNING: "Lectures" about how APIs in general shouldn't change are allowed, but will be completely ignored. :D)

Re: API Wars

Posted: Mon Dec 01, 2008 5:09 am
by Mr. Strange
1 - I trust your judgement.
2 - I very much agree with this approach. Radians across all.
3 - This hasn't been a problem for me yet, but I like the forward-looking perspective.

Go LÖVE!

--Mr. Strange

Re: API Wars

Posted: Mon Dec 01, 2008 5:28 am
by Lord Tim
I definitely support going entirely radian. It would be a lot more consistent.

And as for input devices, it would be neat if you could define a "controller" object or something, and the assign functions/callbacks to certain code-defined outputs of the controller. You would be able to easily switch between different kinds of input devices, i.e. gamepad to keyboard, and it would allow the user to easily customize their own control scheme.

Say, you have a callback called controller.up, and you could assign it to the keyboard arrow key up, and the 360 controller hat up, and then in your game, you just reference the controller.up. I'm sure you guys can figure out a less convoluted method, but I thought it'd be a neat idea.

Re: API Wars

Posted: Mon Dec 01, 2008 7:56 am
by mike
Would #3 involve removing the key/mouse-pressed/released callbacks and using a more open way:

Code: Select all

function love.controllerAction(controller#, button, x, y, etc...)
I like the simplicity of how it works now, but as we saw with the incorporation of joysticks things are a bit messy and aren't made for handling more than one controller.

Re: API Wars

Posted: Thu Dec 11, 2008 6:10 am
by TacticalPenguin
1. _G should contain nothing that isn't pure lua except for the love table. that's my opinion.
2. go radians or perhaps add an option to the conf file to make all the math funcs autoconvert so people can go all degrees
3. love.inputdevicetype[index].func instead of love.inputdevice.func, or love.input.genericFunctionThatDoesEverythingBasedOnSomeArguments()

As for the callbacks, if possible, just straightup get rid of them.

Instead of

Code: Select all

function load()
    --load stuff
end
function update(dt)
    --update stuff
end
function draw()
    --draw stuff
end
it might look like this:

Code: Select all

--load stuff
while love.hasNotExplodedOrDiedOrCrashedOrRanOutOfMemoryOrAnythingElseBad() do
    dt = love.getDeltaTime()
    --update stuff
    love.graphics.startDrawing()
        --draw stuff
    love.graphics.endDrawing()
end

Re: API Wars

Posted: Thu Dec 11, 2008 3:20 pm
by Kuromeku
LOVE NEEDS TO BE OBJECT ORIENTATED!

We need some shit like this:

Code: Select all

function love:draw()
    local color = self.color(255, 255, 255, 255);
    local position = self.position(512, 512);
    
    position:add( self.position(256, 256) );
    color:subtract(255);
    
    self.graphics:drawRectangle(color, position, 1024, 768);
end;

Re: API Wars

Posted: Thu Dec 11, 2008 5:03 pm
by mike
Kudomiku wrote:LOVE NEEDS TO BE OBJECT ORIENTATED!
By "object oriented", do you mean "object enforced"?

Code: Select all

num = love.math.newInteger(12)
num2 = love.math.newFloat(4.7)
num:add(num2)
Having vectors could be useful and I too wish to be able to manipulate colors by using the POWER OF MATH, but let's not get overboard here.

Re: API Wars

Posted: Fri Dec 12, 2008 12:48 am
by appleide
You could make vectors so that they are treated as numbers, and do v1+v2 stuff. :) In the next version of lua can even use the # operator to return the length of the vector!

Just set the metafunction "__add", "__div", ... etc of each vector object! See lua documentation for more details. Only the __len metafunction doesn't work correctly.

I like it now; don't over object enforce please... Otherwise I'd be programming in java :s

Re: API Wars

Posted: Wed Jan 14, 2009 3:01 am
by subrime
I agree with appleide - lua is more than flexible enough to accommodate any oo urges you might be harbouring, but it shouldn't be force on everyone for no good reason.

Regarding radians (which I prefer), what about a love function that switches everything to one or the other? Config options are too mysterious - this should be visible when looking in the code.

Re: API Wars

Posted: Wed Jan 14, 2009 9:09 pm
by LÖVER
1) I support it. But I do not support removing callbacks all together, to me it would just get messy and just make it frustrating.

2) I don't mind converting, mostly because C# does it in an odd way. So I offer an idea: instead of transfering all to radians or degrees add a method that will convert to or from radians/degrees. Not eveyone will want to be outputting in degrees or radians all the time, so give an option. If you do something like this, then a default output of radians would be nice.

Code: Select all

trigCalculation = math.atan2(var1, var2) -- will output in radians but you need degrees SO
love.convert.toDegrees(trigCalculation) -- or even
trigCalculation = love.convert.toDegrees(math.atan2(var1, var2))
The names are obviously just an example :oops:

3) I can't really comment as I am still new to Love.