Libraries

[Neon]

Robin, can you show me exactly what you mean? Can you show me what to not do, and what I should do?

[rokit boy]

Code: Select all

function Lib.displayObjects(...)
     function love.draw()
          Stuff = {...}
          for i,o in pairs(Stuff) do
               love.graphics.print(Objects.o["words"], Objects.o["xpos"], Objects.o["ypos"])
          end
     end
end

My life ends here...

What you can do:

Code: Select all

function Lib.displayObjects(...)
      Stuff = {...}
      for i,o in pairs(Stuff) do
           love.graphics.print(Objects.o["words"], Objects.o["xpos"], Objects.o["ypos"])
      end
end

then in the main code put Lob.displayObjects(trolololol,otrotl,asfd,asf,sadf,saf)

Why do you have the unlimited arguments thing when you dont use them?

[Robin]

Robin, can you show me exactly what you mean? Can you show me what to not do, and what I should do?

I edited my post with a number of suggestions.

Also, a complete rewrite.

[Neon]

I do use them, I have it so I can throw in as many things as I want. So that it can print any number.

[Inny]

Code: Select all

Lib = {}
Objects = {}

function Lib.createLabel(objname,text,x,y)
	table.insert(Objects, objname)
	Objects.objname = {words = text, xpos = x, ypos = y}
end

function Lib.displayLabel(objname)
    function love.draw()
        love.graphics.print(Objects.objname["words"], Objects.objname["xpos"], Objects.objname["ypos"])
    end
end

In this particular example, the two cardinal sins being committed here, with respect to overriding love.draw, are:

• It kills a global variable that game-developer absolutely depends on. He can't draw anything else because the library won't let him.
• Its injecting a closure into the hotloop. Not strictly bad in this minor example, but it fosters a habit of using something that Lua doesn't yet optimize.

The first point should be clear. It isn't adding a label to the list of things to draw, it's clearing out all drawing and making itself the only thing to draw.

To clarify why closures on the hotloop are bad, read this: http://lua-users.org/wiki/ObjectOrienta ... reApproach. In terms of clarity, objects built of closures are probably the most clean form of OOP, but the person who wrote that article demonstrated that there was an increased memory usage by closures over regular old tables. I've done a bunch of these tests myself as well, and came to the same conclusions. By increasing the memory load of your game, you're increasing the rate at which the garbage collector runs. If you have a lot of dynamic objects being created and destroyed (think along the lines of a particle system, or bullets in game like Gradius), then you put a very large burden on the garbage collector, and you'll negate whatever performance gains you could get from closures, and start experiencing frame rate drops and collection pauses. There's a much deeper conversation there (and I think closures are neato, I don't hate them), but Lua 5.1 doesn't optimize them, and Lua 5.2 only optimized the case where there's no upvalues in the closure.

So, Protips: don't overwrite love.draw, require the developer to call your draw function, and store things in tables if they're going to be changing frequently.