Using love.draw

[zell2002]

how come you dont have a table/object/class with variable names and handle the draw call from there?

below example uses middleclass*

Code: Select all

global_objects = {}

function Object:initialize()
	
	self.x = 0
	self.y = 0
	
	self.rot = 0
	
	self.scalex = 1
	self.scaley = 1
	
	self.offsetx = 0
	self.offsety = 0
	
	self.img = love.graphics.newImage("woteva.png")
	self.quad = {} -- quad stuff

	self.color = {255,255,255,255}

	table.insert(global_objects, self)
end

function Object:draw()
	love.graphics.setColor(self.color)
	love.graphics.draw(self.img, self.quad,
		self.x, self.y, self.rot,
		self.scalex, self.scaley,
		self.offsetx, self.offsety)
end


-- in main.lua

function love.draw()
	
	for _, obj in ipairs(global_objects) do
		obj:draw()
	end
end

i prefer this method as it keeps main cleaner - personally
perhaps im missing what youre doing ?

[laperen]

how come you dont have a table/object/class with variable names and handle the draw call from there?

below example uses middleclass*

Code: Select all

global_objects = {}

function Object:initialize()
	
	self.x = 0
	self.y = 0
	
	self.rot = 0
	
	self.scalex = 1
	self.scaley = 1
	
	self.offsetx = 0
	self.offsety = 0
	
	self.img = love.graphics.newImage("woteva.png")
	self.quad = {} -- quad stuff

	self.color = {255,255,255,255}

	table.insert(global_objects, self)
end

function Object:draw()
	love.graphics.setColor(self.color)
	love.graphics.draw(self.img, self.quad,
		self.x, self.y, self.rot,
		self.scalex, self.scaley,
		self.offsetx, self.offsety)
end


-- in main.lua

function love.draw()
	
	for _, obj in ipairs(global_objects) do
		obj:draw()
	end
end

i prefer this method as it keeps main cleaner - personally
perhaps im missing what youre doing ?

OP here, I actually was asking about a different method, which seems like exactly(in concept) what you mentioned.
Its in my latest reply which is the post right before yours

[Positive07]

So we could think this is the best?

Code: Select all

love.draw = function ()
	for count = 1, #list do
		love.graphics.draw(unpack(list[count]))
	end
end

And yes, I would go with an Object:draw() too, looks cleaner

[laperen]

Alright then, this is what I'll be going with
Object.lua

Code: Select all

function Object.draw()
	love.graphics.draw(...)
end

Main.lua

Code: Select all

function love.draw()
	for i = 1,#objectList,1 do
		objectList[i].draw()
	end
end

[bobbyjones]

Alright then, this is what I'll be going with
Object.lua

Code: Select all

function Object.draw()
	love.graphics.draw(...)
end

Main.lua

Code: Select all

function love.draw()
	for i = 1,#objectList,1 do
		objectList[i].draw()
	end
end

Why not just use ipairs? Lol

[laperen]

Why not just use ipairs? Lol

Test 9 of this link is demonstrating for-loops.
https://springrts.com/wiki/Lua_Performance

Other than that I also prefer the fundamental for-loop, with the exception of the for-each when it's needed.

[bobbyjones]

Why not just use ipairs? Lol

Test 9 of this link is demonstrating for-loops.
https://springrts.com/wiki/Lua_Performance

Other than that I also prefer the fundamental for-loop, with the exception of the for-each when it's needed.

I'm pretty certain in luajit the difference isn't that big and it would be a bit cleaner imo.

[laperen]

I'm pretty certain in luajit the difference isn't that big and it would be a bit cleaner imo.

exactly

[zorg]

I'm pretty certain in luajit the difference isn't that big and it would be a bit cleaner imo.

exactly

Well, i did test performance between vanilla lua and luaJIT that löve uses, most of those benchmarks are useless with the latter.
Not completely my own opinion, since i did test it out.
No, i can not link you my benchmark code as it was swallowed up in my last HDD crash, but i can do you one better:
I urge you to not believe me, but also to not blindly believe those test results either; code your own benchmarks and decide for yourself.
Some helpful references which you still should not fully trust:
LuaJIT Performance Tuning
LuaJIT Optimizations
or just the wiki home page if you feel adventurous.

Also, what constitutes clea(n/r)(er) code is, of course, subjective, unless you're in a team following specific style guidelines.
That said, if performance does matter, i would not foresake a bit of ugly for a lot of non-problems in the long run.