uLove

This page has no more real relevance to Löve. uLove is only a proposal right now, so nothing here should be considered final. You are free (and encouraged!) to add your thoughts

uLove (also known as µLÖVE) is a standard subset of functionality intended to reduce Love's binary and memory footprint, and capability requirements. it is specifically intended for targetting devices and contexts that have limited capabilities or permissions, such as portable gaming devices (Dingoo, WIZ, etc), mobile devices (Mobile phones, PDAs, Nanonotes, etc), or constrained contexts (web plugins).

Standard

While any port of love may provide features beyond those defined in uLove, it not generally permitted to remove features.

• uLove archive files are explicitly Zip files. (Rather than "nominally", as in LÖVE).
• uLove must support image fonts, it specifically may omit vector fonts (such as TTF).
• uLove must provide a default font, with a size appropriate to the target device, in the same instances that Love would provide a default font. However, this font is permitted to not be, or be named after, "Vera Sans".
• uLove must support Ogg Vorbis Audio, it may omit all other audio formats.
• uLove must support PNG, and Uncompressed Targa (TGA) image formats. It may omit all other image formats.
• uLove may omit love.mouse, love.keyboard, and love.joystick. Though a uLove host will likely provide at least one of them, none of them are required.
• uLove may omit love.physics.
• uLove may omit LuaSocket.

Implications

In addition to the above constraints, Lovers must also recognise that:

• Many devices running uLove have limited memory, often 32MB or less.
• Many devices targeted by uLove have considerably less processing power than standard systems.
• Many devices targeted by uLove lack the graphics acceleration features used by LOVE. In particular this means that many traditionally slow operations that are painless in love, are actually slow again...

• Alpha transparency other than exactly 50% (and probably transparency in general)
• Rotation not a multiple of 90°
• non-POW2 image scaling (and probably scaling in general)

• Many devices running uLove have low resolutions, in the vein of 320x240 or less.
• many uLove targeted devices will likely rely on hardware quirks and assumptions to keep performance up. in particular, you must assume that non-power-of-two images will be slow, or fail outright.
• uLove is targeted at many disparate devices, uLove games should use functions such as those in love.joystick and love.graphics.checkMode to determine the device's capabilities, and adjust themselves accordingly.
• Many devices targeted by uLove have limited controls, usually one d-pad and four face buttons (A, B, Start, Select, or equivalent) is all that can be relied on.
• Many devices running uLove entirely lack mouse support, those that do present mice have touch surfaces. bare in mind that:

• Touch surfaces usually lack precision.
• Touch surfaces do not usually allow the pointer to be moved without also generating either a click or mousedown event.
• Touch surfaces are absolute, rather than relative pointing devices. (that is, the mouse is always moved to a specific location, never by a delta).

Groundwork

These are notes of things that will need to be charged added to the default Love source bundle to accommidate uLove.

• Either the existing OpenGL backend will need to be converted to OpenGL/ES, or a new OpenGL/ES back will need to be developed.
• Defines/Compile targets will need to be defined to remove the heavier dependencies from Love (optionally replacing them with lighter dependancies where appropriate)
• A new SDL-based backend will need to be created for systems that lack OpenGL support.

See also

• uLove Compliance conf.lua