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.
uLove Proposal
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
uLove Proposal
"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
Networking with UDP uLove Proposal CCG: Gangrene
Re: uLove Proposal
Great idea! But wouldn't it be good to use only one image format for simplicity (just png no tga)?
Good bye.
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: uLove Proposal
Well, tga is uncompressed, yet very easy to implement, so it is not like png at all.. it's hard..
Re: uLove Proposal
Great proposal!
As an addition, some sort of input device abstraction would be nice, though I don't know how that would look like.
As an addition, some sort of input device abstraction would be nice, though I don't know how that would look like.
Re: uLove Proposal
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.
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.
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: uLove Proposal
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.
- Robin
- The Omniscient
- Posts: 6506
- Joined: Fri Feb 20, 2009 4:29 pm
- Location: The Netherlands
- Contact:
Re: uLove Proposal
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.
Re: uLove Proposal
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.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.
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.
(and similar comments)Luiji wrote:Great idea! But wouldn't it be good to use only one image format for simplicity (just png no tga)?
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)
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.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'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
Networking with UDP uLove Proposal CCG: Gangrene
Re: uLove Proposal
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.
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.
All code published with this account is licensed under the Romantic WTF public license unless otherwise stated.
Who is online
Users browsing this forum: Semrush [Bot] and 13 guests