uLove Proposal

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
Elvashi
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

uLove Proposal

Post by Elvashi » Wed Jun 09, 2010 11:40 pm

I've been batting this around on the IRC Channel for a little while now, so I think its about time I opened this up to the forums as well.

uLove is meant to be a minimal set of features intended to both highlight the very loviest of love's features, and to ease porting to limited or constrained contexts, such as web plug-ins, portable gaming devices, mobile phones, embedded contexts, etc, etc.

The full proposal in current form is on the wiki here.

I'd like to have your opinions on the proposal, is there something we've excluded that you think we should keep? or something unnecessary you think we can exclude? is the proposal clear enough? Please share your opinions!

Do keep in mind, though, this is a minimal set of features, excluding things is good and necessary.
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene

User avatar
Luiji
Party member
Posts: 396
Joined: Mon May 17, 2010 6:59 pm

Re: uLove Proposal

Post by Luiji » Thu Jun 10, 2010 5:55 am

Great idea! But wouldn't it be good to use only one image format for simplicity (just png no tga)?
Good bye.

User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: uLove Proposal

Post by bartbes » Thu Jun 10, 2010 11:55 am

Well, tga is uncompressed, yet very easy to implement, so it is not like png at all.. it's hard..

User avatar
vrld
Party member
Posts: 917
Joined: Sun Apr 04, 2010 9:14 pm
Location: Germany
Contact:

Re: uLove Proposal

Post by vrld » Thu Jun 10, 2010 1:39 pm

Great proposal! :)
As an addition, some sort of input device abstraction would be nice, though I don't know how that would look like.
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.

hump | HC | SUIT | moonshine

User avatar
Luiji
Party member
Posts: 396
Joined: Mon May 17, 2010 6:59 pm

Re: uLove Proposal

Post by Luiji » Thu Jun 10, 2010 8:42 pm

It's just it would be better to have only one supported format, as it would be useful to maximally minimize the requirements since some devices are very limited.

I don't think input abstraction is required. Most good games will implement both a joystick and keyboard handler. Having keyboard abstractions might be useful as a small Lua library though. I'll work on this, in fact!

Luiji's new project: input abstraction library.
Good bye.

User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: uLove Proposal

Post by kikito » Thu Jun 10, 2010 11:22 pm

I'm not sure including this inside LÖVE (separating with #defines etc) is a good idea. I suggest considering making a separate project.
When I write def I mean function.

User avatar
Robin
The Omniscient
Posts: 6506
Joined: Fri Feb 20, 2009 4:29 pm
Location: The Netherlands
Contact:

Re: uLove Proposal

Post by Robin » Thu Jun 10, 2010 11:25 pm

The way I understand it, it's more of a standard, something which is used to qualify ports of LÖVE to crippled platforms as worthy.
Help us help you: attach a .love.

User avatar
Luiji
Party member
Posts: 396
Joined: Mon May 17, 2010 6:59 pm

Re: uLove Proposal

Post by Luiji » Thu Jun 10, 2010 11:57 pm

That's what I understand to. These standards are for ports, not LOVE.
Good bye.

User avatar
Elvashi
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

Re: uLove Proposal

Post by Elvashi » Fri Jun 11, 2010 1:41 am

kikito wrote:I'm not sure including this inside LÖVE (separating with #defines etc) is a good idea. I suggest considering making a separate project.
Obviously, no one wants Love2d to become a quagmire of macros and defines, but at the same time the more porting/uLove-related changes make it into main, the more likely love is to be ported in the first place. Pragmatism on both sides is important, I think.

I am working with the code, and I do plan on submitting patches. But just as the uLove proposal is intended as a standard base for ports, my submissions will be about making sure that the code can be easily used as a common base for porting. ...but not actually porting it to anything in particular*.
Actual target-specific changes are left as an exercise for the actual port developers.

* I do plan on porting it to at least the dingoo and nanonote, but these changes won't be in my patch submissions as they don't belong in the main branch.
Luiji wrote:Great idea! But wouldn't it be good to use only one image format for simplicity (just png no tga)?
(and similar comments)

Since uLove is intended to cover a very wide gauntlet of targets with widely differing capabilities, making assumptions about what is and is not an appropriate trade off is likely to be a mistake. at the same time simply allow ports to support "whatever the hell they want" steps horribly on the uLove's secondary goal of being a kind assurance to Lovers, allowing them to make games that will run on as many uLove-capable targets as possible. having one compressed (space-efficient) and one uncompressed (processor-efficient) format is about as reasonably broad as we can be without bloating the standard.
(for this reason, I'm considering adding an uncompressed audio format (WAV?) to the standard)
vrld wrote:As an addition, some sort of input device abstraction would be nice, though I don't know how that would look like.
I couldn't think of any decently flexible and standardized way of doing this, other than perhaps love.joystick. But that would require mandating joystick support on all targets, as well as a "virtual joystick" on all targets, including Love itself (lest love be declared non-compliant). ...that seemed inappropriate.

I'm certainly open to suggestions, but I think its reasonable to leave this to individual Lovers to solve.
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene

User avatar
pygy
Citizen
Posts: 98
Joined: Mon Jan 25, 2010 4:06 pm

Re: uLove Proposal

Post by pygy » Fri Jun 11, 2010 3:54 am

For extreme portability, you may want to take inspiration from the core architecture of ScummVM.

It works on almost anything you can think of, including computers, smartphones and consoles (from the N64 on, see http://www.scummvm.org/downloads/).

Their task is actually more complex than what we have here, since they also have a plethora of engines/interpreters that run on these platforms.

The engines are built on top of a platform-agnostic API (OSystem). ScummVM provides a default implementation for most of these APIs, but it is possible for a backend to override the default if a custom solution is necessary.

Their middleware is currently undergoing restructuring as part of a Google Summer of Code task, the future architecture may also be worth watching.
Hermaphroditism is not a crime. -- LSB Superstar

All code published with this account is licensed under the Romantic WTF public license unless otherwise stated.

Post Reply

Who is online

Users browsing this forum: AdrianN and 13 guests