[Video Tutorial] Love Tutorial ~45min

[bartbes]

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

EDIT: Btw, you do know that setColor accepts tables too (they have to use numerical indices though, iirc).
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.)
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])?
EDIT4: Why imgs["background"] instead of imgs.background? Also, game.load isn't needed in love.load, and enemy_rate-0.01*enemy_rate = 0.99*enemy_rate. Last thing (for now) is your use of table.remove in an ipairs loop.
EDIT5: What about doing l.g.draw(stuff, x*scale, y*scale) instead of storing the x and y scaled?
EDIT6: What's with all the magic numbers? If 12 is half of the player size, why not use player_size/2?
EDIT7: One of the slides is titled "game.lua:splash.draw", that should be splash.lua, of course.

[josefnpat]

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

Thanks for the clarification.

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

News to me! Totally going into rev 2

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.)

I will make sure to say this properly, cheers.

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])?

Lovely idea, will make it happen.

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

Code: Select all

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

Awesomeness...

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

No need to init it twice, good point.

enemy_rate-0.01*enemy_rate = 0.99*enemy_rate.

That's a good line, much clearer.

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

Mark for destruction, then remove later.

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

Might be clearer, i'll see what I can do.

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

Yep, this is something that threw me off too as I was recording it. Intended to fix this.

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

Yay, typos!

But seriously, thanks Bartbes. Will have lots of fun stuff for v2.0

[Santos]

This is awesome! Thanks so much for making this.

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

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.

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. 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.

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

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

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

Mark for destruction, then remove later.

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

[Jasoco]

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.

[Santos]

Ah, I see! Thank you!

[josefnpat]

This is awesome! Thanks so much for making this.

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

Thank you Santos, I'm glad you liked it.

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.

I was originally going to title them "Ogv",but changed my mind as the wikipedia page referenced them as the "Ogg container format".

What if I used "Theora/Ogg video" ?

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.

I agree, and I had a lot of production issues. Pitivi seems to really like jpeg compression for some reason, so the quality goes right down the shitter. I need to get a better workflow. The ogv on the site is actually 720 x 576, but for the next version, I will concentrate on getting a better output size.

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.

I was using google docs for this, so it didn't offer much highlighting. Maybe I can copy paste code from codepad.org or something. I like this idea very much.

As for courier, I hate it too, but it was the only real monospace font google docs would allow. Next revision: no google docs.

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

I agree with you, even though main.lua is a filename. I think I will use an em dash (—) instead of :

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

You're right. will have to update the code for that.

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

Mark for destruction, then remove later.

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.

Thanks Jasoco!


Thank you very much Santos, your critique was neither subjective or "not-very-useful".

[trubblegum]

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.

Unless you are doing table.remove() break, which is a lot quicker and easier if you only have to remove once.
And since no-one is going to notice a split-second delay between hitting and dying .. did I just say that out loud?


Nice tutorial .. you have a good voice for it.

[Reef]

I skipped around through the video and it seems like just what I need to finally get started with LÖVE. I'm eager to watch the new version with all the suggested changes.

Thanks for taking the time to make this!

[n30]

mediafire link not working!

[Mogex]

Profiled.