Difference between revisions of "uLove"

(updated based on conversation in IRC)
(Edited notice to reflect on how time passes... no real work has gone into this since 6 years ago. If the snippets page does get deleted, then delete this as well, since it will be orphaned.)
 
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{| border='1' bgcolor='gold' cellpadding='10'
+
{{notice|This page has no more real relevance to Löve.
|-
+
<s>uLove is only a proposal right now, so nothing here should be considered final.
|uLove is only a proposal at this stage, feel free to [[talk:uLove|add your thoughts]]
+
You are free (and encouraged!) to {{forumlink|forum=4|topic=1623|title=add your thoughts}}</s> }}
|}
 
  
 +
[[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).
  
uLove is a proposed standard subset of functionality intended to reduce Love's binary and memory footprint, specifically for use on embedded and portable devices.
+
==Standard==
  
 
While any port of love may provide features beyond those defined in uLove, it not generally permitted to remove features.
 
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 [[Love]]).
+
* uLove archive files are ''explicitly'' Zip files. (Rather than "nominally", as in [[LÖVE]]).
* [[uLove]] ''must'' support [[image font]]s, it specifically ''may omit'' [[vector font]]s (such as [[TTF]]).
+
* uLove ''must'' support [[image font]]s, it specifically ''may omit'' [[vector font]]s (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'' 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 [http://en.wikipedia.org/wiki/Vorbis Ogg Vorbis] Audio, it ''may'' omit all other audio formats.
* [[uLove]] ''must'' support [[PNG]], and [[Uncompressed]] [[Targa (TGA)]] image formats, and is ''recommended'' (but not required) to additionally the [[Windows BMP]] image format. It ''may omit'' all other image formats.
+
* uLove ''must'' support [http://en.wikipedia.org/wiki/Portable_Network_Graphics PNG], and Uncompressed [http://en.wikipedia.org/wiki/Truevision_TGA 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.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 [[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 [[OpenGL|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&deg;
 +
:* 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-[[PO2 Syndrome|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 button]]s (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]]
  
In addition to the above contraints, [[lover]]s must also recognise that:
+
{{#set:LOVE Version=Any}}
* Many devices running [[uLove]] have limited memory, often 32MB or less
+
{{#set:Description=A standard minimal subset of features to ease porting to constrained platforms}}
* Many devices targeted by [[uLove]] have considerably less processing power than standard systems.
+
[[Category:LÖVE]]
* Many devices running [[uLove]] have low resolutions, in the vien of 320x240.
+
[[Category:Proposals]]
* [[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 depad and four [[face button]]s (A, B, Start, Select, or equivilent) is all that can be relyed 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)
 

Latest revision as of 16:35, 11 November 2016

O.png 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