API Wars

General discussion about LÖVE, Lua, game development, puns, and unicorns.
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

API Wars

Post 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)
Mr. Strange
Party member
Posts: 101
Joined: Mon Aug 11, 2008 5:19 am

Re: API Wars

Post 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
User avatar
Lord Tim
Prole
Posts: 30
Joined: Sun Jul 20, 2008 4:07 am

Re: API Wars

Post 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.
User avatar
mike
Administrator
Posts: 364
Joined: Mon Feb 04, 2008 5:24 pm

Re: API Wars

Post 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.
Now posting IN STEREO (where available)
TacticalPenguin
Prole
Posts: 15
Joined: Thu Dec 11, 2008 5:44 am

Re: API Wars

Post 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
User avatar
Kuromeku
Party member
Posts: 166
Joined: Sun Jul 20, 2008 5:45 pm

Re: API Wars

Post 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;
User avatar
mike
Administrator
Posts: 364
Joined: Mon Feb 04, 2008 5:24 pm

Re: API Wars

Post 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.
Now posting IN STEREO (where available)
User avatar
appleide
Party member
Posts: 323
Joined: Fri Jun 27, 2008 2:50 pm

Re: API Wars

Post 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
User avatar
subrime
Citizen
Posts: 76
Joined: Thu Nov 13, 2008 6:18 pm
Location: Australia

Re: API Wars

Post 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.
LÖVER
Prole
Posts: 10
Joined: Mon Jan 05, 2009 9:09 pm

Re: API Wars

Post 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.
Post Reply

Who is online

Users browsing this forum: No registered users and 87 guests