LÖVE

bartbes wrote:That is, after all, the official pronunciation. ("Love")

bartbes wrote:EDIT: Btw, you do know that setColor accepts tables too (they have to use numerical indices though, iirc).

bartbes wrote:EDIT2: The update function gets called once, and exactly once for every drawn frame. (Though this isn't necessary, it's the case now, and always has been.)

bartbes wrote:EDIT3: Isn't it cleaner if you use the state either as the state table itself (so state = splash instead of state = "splash"), or use state as a table index (so states[state] or even _G[state])?

bartbes wrote:EDIT4: Why imgs["background"] instead of imgs.background?

[~]$ lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> imgs = {}
> imgs["background"] = "test"
> print(imgs.background)
test

bartbes wrote:Also, game.load isn't needed in love.load, and

bartbes wrote:enemy_rate-0.01*enemy_rate = 0.99*enemy_rate.

bartbes wrote:Last thing (for now) is your use of table.remove in an ipairs loop.

bartbes wrote:EDIT5: What about doing l.g.draw(stuff, x*scale, y*scale) instead of storing the x and y scaled?

bartbes wrote:EDIT6: What's with all the magic numbers? If 12 is half of the player size, why not use player_size/2?

bartbes wrote:EDIT7: One of the slides is titled "game.lua:splash.draw", that should be splash.lua, of course.

josefnpat wrote:

bartbes wrote:Last thing (for now) is your use of table.remove in an ipairs loop.

Mark for destruction, then remove later.

Santos wrote:Could someone please explain to me why this is a good practice?

Santos wrote:This is awesome! Thanks so much for making this.

Highly subjective and not-very-useful critique time, woo!

Santos wrote:I saw "Ogg" and assumed it was audio. Perhaps renaming it "Ogg video" or something might help people who didn't read the first post very well. Like me. Thanks for providing 7z links, it's a great format.

Santos wrote:I think that the text could be more readable. Is it possible to make the resolution 720 or 1080? Maybe changing the colours a bit to increase the contrast of the text would help too.

Santos wrote:Syntax highlighting would be amazing if you could find some plugin or something to do it for you. You could probably get away with increasing the font size too. Also using anything but Courier would benefit readability/aesthetics in my highly subjective opinion.

Santos wrote:Could "main.lua:love.load()" etc. be mistaken for Lua syntax? Probably not. Just putting that out there.

Santos wrote:Enemies don't move completely off screen before they disappear.

josefnpat wrote:

bartbes wrote:Last thing (for now) is your use of table.remove in an ipairs loop.

Mark for destruction, then remove later.

Jasoco wrote:

Santos wrote:Could someone please explain to me why this is a good practice?

Because when you use table.remove, it removes the index and then goes through the entire table to move each entry after the removal point up one. Not only is it slow, but if you are running through the table in a for loop, you end up shifting all the table entry indexes and confuse the crap out of the for.

By marking them for deletion and removing them in a separate loop you avoid conflicts and slowdown.

My method is to create an empty "removal table" at the start of the update loop (Anywhere before your update loop) then while running through your table, for instance a bullet table, you A) mark the bullet as "dead" and B) add an entry to the "removal table" with that bullets index, then after you're done, you run through the "removal table" removing all items from the bullet table with that index.

Jasoco wrote:

Santos wrote:Could someone please explain to me why this is a good practice?

Because when you use table.remove, it removes the index and then goes through the entire table to move each entry after the removal point up one. Not only is it slow, but if you are running through the table in a for loop, you end up shifting all the table entry indexes and confuse the crap out of the for.

By marking them for deletion and removing them in a separate loop you avoid conflicts and slowdown.

My method is to create an empty "removal table" at the start of the update loop (Anywhere before your update loop) then while running through your table, for instance a bullet table, you A) mark the bullet as "dead" and B) add an entry to the "removal table" with that bullets index, then after you're done, you run through the "removal table" removing all items from the bullet table with that index.