LOVE 0.2.1

[rude]

Yay release!

So we've finally released 0.2.1 ... the reason this took so long is that we simply had to spilt up the code into multple SWIG-modules (this wasn't really planned).

Overview:

• It's now possible to save files to a "safe" dedicated directory on the user system via love.filesystem.
• Improvements to ImageFont. (Mike: please elaborate)
• Better interface for primitive rendering.
• Added image optimization and padding functions. This makes sprites prettier when scaled, rotated or drawn in floating point positions.
• Added love.timer.sleep.
• Added love.graphics.getWidth/Height.
• Added functions for drawing sections of images.
• Escape does not close window. (Try Alt+F4).
• Added functions for setting the mouse position.
• Changed getFps to getFPS.
• love.filesystem.include has been renamed to love.filesystem.require. (Include now does something else. Keep reading).
• + forgotten changes. 8-)

Here's what you should know with respect to changes:

The different modules (love.graphics etc) are now actual SWIG-modules. This means that when accessing the functions in a module, a dot should be used in place for the comma:

Code: Select all

-- Old:
love.graphics:draw(image, 50, 50)
-- New:
love.graphics.draw(image, 50, 50)

Another major change is that the love.objects "device" has been removed. Objects are now created by their "logical" devices:

Code: Select all

-- Old:
img = love.objects:newImage("yay.png")
-- New:
img = love.graphics.newImage("yay.png")

Where objects are created should be obvious, but if it isn't:

• love.graphics.newImage
• love.graphics.newAnimation
• love.graphics.newFont
• love.graphics.newImageFont
• love.graphics.newColor
• love.audio.newSound
• love.audio.newMusic
• love.filesystem.newFile

To observe the effect of the image optimization function, download this 0.2.1-demo. Look closely on the sprite to the left, and you'll see white flashing along the edges when it moves. In the optimized sprite to the right, this effect is reduced (or removed).

imageopt.love

(2.84 KiB) Downloaded 400 times

And there are new filesystem features too. Not going into too much detail; there's more information in the docs.

Code: Select all

function save_highscore()
  local file = love.filesystem.newFile("highscore.lua", love.file_write)
  love.filesystem.open(file)
  love.filesystem.write(file, "highscore = { jane = 500, bob = 1000 }")
  love.filesystem.close()
end

function load_highscore()
  if( love.filesystem.exists("highscore.lua") then
     love.filesystem.include("highscore.lua")
  end
end

Note that love.filesystem.include has been changed:

Code: Select all

-- This always includes. (Useful if you actually want to replace certain tables in Lua).
love.filesystem.include("file.lua")

-- This includes only if the file hasn't been included already.
-- (Should perhaps be named "include_once", but everyone hated the name)
love.filesystem.require("file.lua")

Enough for now.

Development on 0.2.2 has begun. Main focus for next release will be error handling, <pun>in-LÖVE</pun> console and development experience. Much of this is done already, so it will probably be out soon.

[mike]

ImageFont changes include variable spacing, variable line heights (works for "normal" fonts as well) and a bunch of fixes. Before, in the old days, ImageFont would ignore the spacing color between the characters but now it is taken into consideration and can be changed:

Code: Select all

faunt = love.graphics.newImageFont("imgfont.png", " ABCD", 2) -- the spacing will the twice as much as normal
faunt = love.graphics.newImageFont("imgfont.png", " ABCD", 0) -- no spacing
faunt = love.graphics.newImageFont("imgfont.png", " ABCD", -1) -- the characters will move "into" each other, a nifty little effect

Line height is also variable (a request by rude):

Code: Select all

font = love.graphics.newFont("fontfile.ttf")
font:setLineHeight(2) -- twice as much line height
font:setLineHeight(0) -- no line height (all lines merge into each other)
font:setLineHeight(-1) -- negative values work too (this will draw the lines from the bottom up)

Also did some fixes including letting you draw ImageFonts at floating point positions. There is probably more things I have done, but nothing that you can see.

[Merkoth]

Just finished downloading, nice work guys

Glad to see filesystem methods, a shame getpixel/putpixel didn't make it, but I don't want to sound like a feature whore, so thanks a lot

[rude]

Thanks.

The reason getPixel didn't make it is because Mike and me couldn't decide on a nice way of indicating that an image should stay in memory. It would have to be something like:

Code: Select all

image = love.graphics.newImage("awesome.png", love.image_unlock)

-- Get pixels.
pixel = image:getPixel( x, y )
-- etc

-- Change pixels.
image:setPixel( x, y, color )
- etc

-- Send image to OpenGL.
image:lock()

-- setPixel/getPixel do nothing at this point.

Mike didn't like this. Neither did I.

However, I just got this evul idea:

Code: Select all

pixels = love.graphics.newPixels("awesome.png")

-- Pixels is a table with all the pixels:
-- pixels = { r, g, b, a, r, g, b, a, r, g, b, a, etc }

-- Do whatever you want with the pixels.
pixels[500] = 255
pixels[0] = 0

-- And then later, create a LÖVE compatible image:
image = love.graphics.newImage(pixels, width, height)

Take that, Mike!

Does that float your boat, Merkoth?

[Merkoth]

I'm pretty sure it'll float my boat no matter what way you end up implementing it. Two comments:

1) you might want to provide a way to convert an image in a pixel array and
2) you might also want to use a 2d table instead of an array

What I don't really understand (probably because I know shit about OpenGL and the love codebase) is why the image objects remain available in memory to be able to render it again in the next frame but you can't modify them. I would expect image objects to behave more like buffers (hence being able to modify them on the fly), since I certainly doubt you're reloading all the images every frame

Anyway, maybe we should continue this somewhere else, this thread is for saying thanks to you LÖVE l337 h@xx0rz

Edit: I just noticed that print() isn't giving me the expected results (Ubuntu 8.04 Alpha, Beta or something). If this was done on purpose by the allmighty developers, I'll be getting flight tickets and a pair of huge boots ASAP

[rude]

Code: Select all

... why the image objects remain available in memory to be able to render it again in the next frame but you can't modify them.

This is what happens when you call love.graphics.newImage:

1. Pixels are read from disk into a char array.
2. Image processing functions are applied, if any.
3. An OpenGL (tm) texture is created (on the graphics card).
4. Since we have a copy of the texture on the graphics card, we no longer need the char array of pixels, and it is freed.

When you later call love.graphics.draw(image, x, y), it is the OpenGL-texture that is used to draw the image, not the char-array into which we loaded the pixels initially.

Reading pixel values is one thing, but if you want to change the contents of a texture every frame ... that's different. Hmm ... this may be the excuse I've been looking for to mess with Pixel Buffer Objects.

Code: Select all

print() isn't giving me the expected results

Christ ... this is because print() was redirected to the forthcoming LÖVE-console, and I *forgot* to re-send the message to stdout. Ah well ... we'll release a bug-fix release in a few weeks anyway.

8-)

[Merkoth]

And this is how I reveal that I have never worked without some kind of pixel buffer n_nU Thanks for the explanation rude n_n

BTW, I think I can ask this safely here: It's nice to see that ESC no longer finishes the execution, but I can't find any method to do it by hand. I know I can use the WM close button or Alt-F4 (depending on your WM) while in fullscreen mode, but a love.shutdown(ret_code) would be handy. Does something like this exist and I'm just too blind and/or stupid to find it?

[rude]

love.shutdown(ret_code)

Nope. Doesn't exist. Adding to to-do list.

[ivan]

Whoaaa, so many updates. You guys must have been pretty busy eh?

However, I just got this evul idea:

An easier solution would be what is known in DirectX as "render targets".
You create your image, set it as a render target through the "graphics" object and next time you draw primitives they will go the image instead of the backbuffer.
So it would look something like:

Code: Select all

image = love.graphics.newImage("awesome.png", love.image_unlock)
love.graphics.setRenderTarget ( image )
love.graphics.setPixel ( 100, 100, 0xFF00FFFF )

[rude]

An easier solution would be what is known in DirectX as "render targets".

Good idea, but not sure if it solves our problem.

... uh ... what is our problem? Merkoth, what did you intend to use setPixel/getPixel for? Load-time image processing? Dynamic textures? Both?

We would at least need a way of reading pixels in addition to render targets.