LÖVE

Posted: **Tue Feb 24, 2009 4:51 am**

http://lua-users.org/wiki/PlutoLibrary/
http://luaforge.net/projects/pluto/

Basically Pluto is a persistence library for saving program states so that they can be loaded back later. One of Pluto's specific uses is to make game saving/loading very easy. I was thinking that this is a basic enough functionality that it might pay to have some sort of integration into LÖVE.

Posted: **Tue Feb 24, 2009 7:57 am**

This was already mentioned somewhere on the forums, but maybe rude'll now think there are more people wanting to save their data in an easy way.
Rude, topic is all yours

Posted: **Tue Feb 24, 2009 8:44 am**

Hm, that is pretty neat. You can choose which variables you get to save and which you don't, right? If so, I'm all for implementing it!

Posted: **Tue Feb 24, 2009 7:29 pm**

bartbes wrote:This was already mentioned somewhere on the forums, but maybe rude'll now think there are more people wanting to save their data in an easy way.
Rude, topic is all yours

I've been very sceptical about this before, and I still am. You will NOT[1] be able to do this:

Code: Select all

-- Saving ...
actor = {
   x = 0, y = 0,
   image = love.graphics.newImage("awesome.png")
}

pluto.awesome.save(actor, "actor.dat")

-- Later:
actor = pluto.awesome.load("actor.dat")

love.graphics.draw(actor.image, actor.x, actor.y) -- GRAND FAILURE.

The memory address in actor.image may be stored correctly, but it will point at something else in another instance of love.exe.

[1]: Space-echo goes here.

Posted: **Wed Feb 25, 2009 12:14 am**

rude wrote: I've been very sceptical about this before, and I still am.

Could you be a bit more specific about the issues involved rude? The author of pluto is a moderator and regular poster over at the gamedev.net forums(Sneftel is his username), and I could try asking him about any issues you think it might have.

A sample of a previous question someone had for him:

Pluto: Can I use it in a commercial engine? Can it manage circular-references? Is it resistant to versioning? Can it use custom serialization(define what is serialized and what not)? Does it allow non-intrusive serialization like boost?

Yes, yes, kind of, yes, kind of. Pluto is versioning-agnostic... if an object has a particular field when it is saved, that field will be there when the object is reloaded. Handling unexpectedly missing fields due to version differences is left to client code. As for non-intrusive serialization, custom serialization routines for objects are through the metatable instead of the object itself. So you don't need to change the object's interface or its behavior, but you do need to change its metatable. (There's a way around this, but it's probably not worthwhile.)

Posted: **Wed Feb 25, 2009 12:24 pm**

I'll try to explain what rude said:
Most of the things returned by calls like newImage are userdata, userdata is basically a C pointer, so when you load it again, the pointer references to nothing, and everything starts burning, and the LÖVE unicorns start dying

So.. avoid that.

Posted: **Wed Feb 25, 2009 2:28 pm**

Simtex wrote:Could you be a bit more specific about the issues involved rude? The author of pluto is a moderator and regular poster over at the gamedev.net forums(Sneftel is his username).

I meant to disrespect to Pluto, I'm sure it's awesome.

Other than that: what bartbes said. I will add, though, that there are two types of userdata in Lua: "full" userdata, in which the Lua VM does the memory allocation, and light userdata, which is just a C pointer. Even if we converted all userdata objects to full userdata objects, then Pluto could probably handle the reading/writing of memory, but we would still be dependent on consistency with external "states", such as OpenGL and OpenAL.

Example! Image objects returned by love.graphics.newImage contain an integer value representing the texture. This integer value is determined by OpenGL. If a full userdata Image is written to disk and read back by Pluto, then that integer value does not mean anything, because the OpenGL texture is not really created on the GPU. The same thing applies even if no external hardware is present. A File from love.filesystem, for instance, will require a handle allocated by PhysicsFS.

... that may have been poorly explained.

EDIT, forgot to say: we could still add Pluto as long as this issue is made crystal clear. Use the tracker system.

LÖVE

Integrating Pluto with LÖVE?

Integrating Pluto with LÖVE?

Re: Integrating Pluto with LÖVE?

Re: Integrating Pluto with LÖVE?

Re: Integrating Pluto with LÖVE?

Re: Integrating Pluto with LÖVE?

Re: Integrating Pluto with LÖVE?

Re: Integrating Pluto with LÖVE?