LÖVE

Posted: **Thu Feb 03, 2011 2:55 pm**

Yep, I've seen it.

But some things just completely confuse me. For example, what do I pass to Input.define()? I've been experimenting. So far, the closest I've come to getting it to work is this:

Code: Select all

Input.define('turnLeft', {'key', 'a'})

But that doesn't work.

EDIT: I found something that WORKS, but is most likely not what I should be doing:

Code: Select all

Input.define('turnLeft', {'a', 'a'})

EDIT (again): Herpaderp, took a step back to when I didn't know Lua.

I think this is how the code is intended to be used, but there has to be a shorter way?

Code: Select all

keyMap = {}
	keyMap['key'] = 'a'
	Input.define('turnLeft', keyMap)
	keyMap = {}
	keyMap['key'] = 'd'
	Input.define('turnRight', keyMap)

SOLVED:

Code: Select all

	Input.define('turnLeft', {['key']='a'})
	Input.define('turnRight', {['key']='d'})

Posted: **Thu Feb 03, 2011 9:26 pm**

Oh heck, no wonder you're having trouble. That method was only recently added, and for some reason I didn't document it right then and there. That will be fixed.

You'll probably want to look inside the physics test, as it has the use of physics, entities, worlds, the camera and all. It's not fully up-to-date with the framework (I don't think it uses Input.define for example) but it should be of help: https://github.com/BlackBulletIV/grace/ ... ts/physics.

EDIT: Taking a look at the Input.define method again, it would probably be more useful in this syntax:

Code: Select all

Input.define{'supershot', key = 'space', key = 'shift', mouse = 'l'}

Posted: **Fri Feb 04, 2011 12:45 pm**

BlackBulletIV wrote:
Code: Select all
Input.define{'supershot', key = 'space', key = 'shift', mouse = 'l'}

That won't work (brainfart, I guess ;-))

Code: Select all

Input.define{'supershot', key = {'space', 'shift'}, mouse = 'l'}

Posted: **Sat Feb 05, 2011 9:54 am**

Argh, it wouldn't, and neither would the current method in case of multiple keys. Thanks for that, I'll get onto implementing it soon.

A question (which I'll probably make into a poll), should Grace try to cover up Love with an object-oriented layer? The advantages of this are:

1. It will allow tighter integration between the classes. For example, instead of supplying an (say) Image to the Graphic class, you would just create an instance of the Image class, which would be a subclass of Graphic.
2. It would make the making of games totally object-oriented, making for a consistent presentation.

The disadvantage (so far as I see it) is this: it would add another layer of code (I'm don't think this is a big problem though).

EDIT: The new table syntax has been applied to Input.define (untested though).

Posted: **Sat Feb 05, 2011 12:00 pm**

Shouldn't the base class for Images and the likes be called Drawable?

That's the naming convention in the LÖVE source code.

Posted: **Sat Feb 05, 2011 7:41 pm**

I guess it probably should if a wrapper is created.

Posted: **Mon Feb 07, 2011 4:41 am**

Alpha 4 has been released, with a number of new things. The main thing is probably that it now supports MiddleClass 1.3, which means a big backward incompatible update.

Here's the changes:
* [Added] Color class now has the grayscale and sepia functions.
* [Added] Graphics can now have color tints as well.
* [Added] Logging to a text file to Debug.
* [Added] The quit() function, a utility to quit the game.
* [Added] Layers can now have color tints. Most useful for setting the alpha of a layer.

* [Changed] Converted to use MiddleClass 1.3.
* [Changed] New table syntax for Input.define.
* [Changed] Requiring debug.init now automatically calls Debug.enable.
* [Changed] Debug now sets the color back to what it was, rather than white.

* [Fixed] Input.define can now take multiple keys and mouse buttons.

Has anyone got any opinion on the poll I've put up there?

Posted: **Mon Feb 07, 2011 7:26 am**

Nice to see the great pace this lib is having.

Concerning the poll: While I was developing PÄSSION, I asked the same question myself. Both options seemed to have their own advantages and disadvantages, so I ended up not implementing a LÖVE "wrapper" - I concentrated on other stuff.

The same happens now. Both options seem valid, I don't have any preference, and hence I haven't voted. Sorry I can't help more.

Also, I should mention that theLinx has already implemented an oop wrapper. Maybe you can reuse some of his work, if you end up deciding for it.

Posted: **Mon Feb 07, 2011 7:40 am**

Thanks.

The changes are slowing down though, which is might be a sign of stability creeping its way into the framework.

Yeah, I think a Love wrapper is not very high priority, if I even choose to go ahead with it.

I did see that one, I'll have to check it out in more detail.

Posted: **Sun Feb 20, 2011 12:39 am**

A little bit of news. Grace now has it's own separate tests repo. This will be a collection of tests using telescope (with my own test runner so I can use it in Love) to make sure everything is working. So far I've only done most of the Grace module's functions. There's a lot to write, but this will help Grace become more stable (as it's hardly tested right now).

Alpha 5 is in the works, although it won't be done for a while; it's a huge change. I'm creating a Love wrapper, but not your usual kind. This wrapper will integrate seamlessly with the organisational functionality of Grace, not just cover over Love with classes.

LÖVE

Grace (Alpha 4) - object-oriented framework for LÖVE

Re: Grace (Alpha 3) - object-oriented framework for LÖVE

Re: Grace (Alpha 3) - object-oriented framework for LÖVE

Re: Grace (Alpha 3) - object-oriented framework for LÖVE

Re: Grace (Alpha 3) - object-oriented framework for LÖVE

Re: Grace (Alpha 3) - object-oriented framework for LÖVE

Re: Grace (Alpha 3) - object-oriented framework for LÖVE

Re: Grace (Alpha 4) - object-oriented framework for LÖVE

Re: Grace (Alpha 4) - object-oriented framework for LÖVE

Re: Grace (Alpha 4) - object-oriented framework for LÖVE

Re: Grace (Alpha 4) - object-oriented framework for LÖVE