LÖVE

Posted: **Wed May 30, 2012 10:28 pm**

Question one:

Okay, so...

viewtopic.php?f=4&t=8957

There's an explanation here about dt, by timmeh, and I wanted to be sure that I understand this...

So dt's value is always 1/current fps, so, okay, let me give an example...

Code: Select all

if love.keyboard.isDown("left")
   then player.x = player.x - 200 * dt
        end
if love.keyboard.isDown("right")
   then player.x = player.x + 200 * dt
        end

So...if the fps was 30, the speed would be 200 * 0.0333333333, which would be 6.66666666, and if fps was 60, the speed would be 200 * 0.0166666667, which would be 3.33333334...

Now, here comes the part that kinda confuses me...

Since the speed on 30 fps would be 6.66666666 and speed on 60 fps is 3.33333334, and now, I'm guessing there's some kind a boost by fps involved here...I'm not sure how to calculate it, but if the 6.66666666 was an absolute speed for 30 fps, and 3.33333334 was an absolute speed for 60 fps, that would actually make character move faster on 30 fps, than on 60 fps, and that's just absurd.

What I am wondering is...how does the speed even out in the end?

Does 6.66666666 get divided by 2 on 30 fps, while 3.33333334 on 60 fps just stays the same? so it's about the same speed, only 0.0000001 faster on 60 fps? or is there just something else in "dt", other than 1/fps?

EDIT:

question two:

Okay, another thing I'm wondering about...

Code: Select all

player = {}
player.x = 50
player.y = 50
player.speed = 200
player.pic = love.graphics.newImage("images/player.png")


function player_draw()

love.graphics.setColor(255, 255, 255)
love.graphics.draw(player.pic, player.x, player.y)


end
function player_move(dt)
if love.keyboard.isDown("left")
   then player.x = player.x - player.speed
        end
if love.keyboard.isDown("right")
   then player.x = player.x + player.speed * dt
        end




end

Ok, there's a code that is called in my main with require. What I'm wondering is...why is "player = {}" necessary to require this code in my main code? The way I see this, it's just an empty table, right? If the variables that are under it, were actually inside, it would make some sense to me...but like this, I just don't get it...why do I get an error when I delete "Player = {}"? Why is an empty table needed in this code for require to function properly?

EDIT2:

question three:

I've also been trying to make it so that i get the speed of the player shown at all times, and change, as it changes, like 0 when not moving, and whatever the speed is when moving. I'm guessing it goes something like showing the fps, but I don't know how to do that, either, well...I didn't really search for this, but since I'm asking questions here, might as well put this here...

I tried using

Code: Select all

love.graphics.setColor(0, 255, 255)
love.graphics.print(player.speed, 400, 400)

in the update function. Didn't really think it would work, but gave it a shot xD

so I was wondering how would I show speed at all times, or anything, really...like if a player had a bunch of stats, like strength, health...and so on, and make it update, as you get items/level up or distribute stat points, in case it's that kind of a game.

Posted: **Thu May 31, 2012 12:13 am**

Hi!

1)
I'm still trying to figure out delta times for myself, but I think I can partially answer your question. When your game runs at 30 FPS, the object moves 6.666... pixels 30 times in one second. At 60, that is halved so the object moves 3.333... pixels 60 times in one second. They both move the same amount in the end.

2)
player={} is needed to make space in memory to hold a table. When lua sees "player.x = 50", it looks for the memory location the variable "player" is associated with, and adds an entry to it. If it can't find anything attached to the name "player", it'll error. Almost all programming languages require you to declare variables before using them. If it still bothers you though, you can always specify variables in the parens like so:

Code: Select all

player = {
x = 50,
y = 50,
speed = 200,
pic = love.graphics.newImage("images/player.png")
}

This does the exact same thing as the first 5 lines do in your code.

3)
This is a little vague to me, but it sounds like you want a way to display variables live. You already did it in your code! Whenever the variable "player.speed" changes, it will be reflected in the drawn text immediately.

Posted: **Thu May 31, 2012 12:31 am**

Skygrinder wrote: Since the speed on 30 fps would be 6.66666666 and speed on 60 fps is 3.33333334, and now, I'm guessing there's some kind a boost by fps involved here...I'm not sure how to calculate it, but if the 6.66666666 was an absolute speed for 30 fps, and 3.33333334 was an absolute speed for 60 fps, that would actually make character move faster on 30 fps, than on 60 fps, and that's just absurd.

What I am wondering is...how does the speed even out in the end?

The answer?
It evens out

Think about this. The whole goal of this code is to cause the change in FPS to have no effect on the speed the player moves.

So your question, why does 30 fps cause a faster speed then 60 fps?
Because, there is less frames per second that ultimately causes there to be less updates per second. Because the program can read that, it will say, because there is less updates, the player will need to move faster so that he maintains the same rate as when there is more updates.

Look, here's an example:

suppose, at 60 fps I get a speed of 2.5. Then at 30 fps I get a speed of 5.
Why did this happen?
In one second, you get 60 updates from 60 fps, so it has to cut the speed in half so that when at 30 fps your going at 5 you still have the same overall speed.

player = {}
player.x = 50
player.y = 50
player.speed = 200
player.pic = love.graphics.newImage("images/player.png")

All these values ARE inside the table

Your probably thinking of:
player = {x = 50, y = 50, speed = 200, pic = love.graphics.newImage("images/player.png")}
But, they are the equivalent.

love.graphics.setColor(0, 255, 255)
love.graphics.print(player.speed, 400, 400)

Not exactly sure what player.speed holds, but this should work.
EDIT:
If you want it to update, just make sure it's in the love.update callback.
Oops, should have thought about that before I said it

You should put it in love.draw not love.update. love.update will cause it to not show up!

You could use a formula similar to Eulers method:

speedx = x2 - x1
speedy = y2 - y1

Posted: **Thu May 31, 2012 12:42 am**

Edit : Seems I took too much time writing, the 10$man answered before me

Hi.

I'll try to do my best to answer you.

So... Answer 1 :

Your calculation is right. With 30fps, speed would be 6.6666666 and with 60fps it would be 3.333333333.
Which means that, each frame, your player will move by 6.666666 or 3.3333333 so it will make something like... 200 in 1 second (3.33333/frame with 60 frames/sec = 200). Did you get it ?

If you don't use dt, your player will move by 200 every FRAME. So in 1 second it would move by 6000 with 30fps and by 12000 with 60fps.
I don't know if I made myself clear or if I could be wrong myself but anyway.

Answer 2 :

You have to know that this :

Code: Select all

player = {}
player.x =  0
player.y = 0

equals this :

Code: Select all

player = {x=0, y=0}

By doing some "variable.key = value" you just add something into the variable table. If you don't have any table, you can't add anything.
Once again, I'm not sure I made myself clear (I'm pretty sick today) but anyway I tried to :p

Answer 3 :

You just have to put your code in the love.draw() function. Not in the update() one

Hope I helped.

Posted: **Thu May 31, 2012 1:11 am**

Thank you for your replays

and I understand.

30 * 6.6666666 = 200
60 * 3.3333333 = 200
75 * 2.66666666 = 200
...and so on, I get it, it always evens out on your set speed.

That explained it perfectly.

As for the table, I was kinda expecting something to end it, and since it was like { (Opened) and } (closed) right away, I figured that it's empty. It still doesn't make sense why would they even make it possible this way, rather than actually writing the stuff in the brackets. I guess it looks cleaner like this.

Though, still, one part is still unclear to me. Why is table even required for me to require this code in the main.lua? Since when I delete player = {}, I get an error.

Also, another question comes to mind...so, is everything under "Player = {}" in the table, while everything above it, is out of that table? What I'm wondering is, if you add a table like that there, is it even possible to create a variable that is not in that table anymore, and how would you do it?

I'm guessing it doesn't even matter, since you can use any variable separately later on in the code, but I'm just being curious about how the tables work...it seems very confusing.

Posted: **Thu May 31, 2012 1:12 am**

Question one:

Here's how I understand dt...

dt is simply the time passed since love.update was last called, and it fluctuates.

: dt.png (883 Bytes) Viewed 7304 times

As an example, using the dt values shown above...

Code: Select all

player.x = player.x + player.speed * dt

The second frame after the game starts happens at 0.3 seconds. So what is really happening is...

Code: Select all

player.x = player.x + player.speed * 0.3

Assuming the player speed is 200, this will add 60 pixels to the player's x position.
At 0.4 seconds, love.update is called again, and 0.1 * player.speed (20 pixels) is added to the player's x position, which is now 80 pixels to the right of its initial starting position.

So after 1 second, how far has the player moved?
0.3 * player.speed + 0.1 * player.speed + 0.2 * player.speed + 0.2 * player.speed + 0.1 * player.speed + 0.1 * player.speed...
or, 1.0 * player.speed,
or, player.speed! It all worked out!

Of course, dt will most likely be much, much lower, and many more calls to love.update (or frames, you could say, as love.draw happens after love.update) will happen in a second, and after 1 second the movement of player most likely wouldn't be exactly the player's speed, but hopefully this illustrates how dt works.

Question two:

To access player.x, there first needs to be a table named player. Why isn't a table named player created when you try to assign a value to player.x? I... I don't know.

However, you can create a table with initial values if you want.

Code: Select all

player = {
    x = 50,
    y = 50,
    speed = 200,
    pic = love.graphics.newImage("images/player.png")
}

Questions three:

Try putting that in love.draw instead.

(Aaand I have been ninjaed. Twice!

I hope our replies help!)

EDIT TIME!

Skygrinder wrote:Also, another question comes to mind...so, is everything under "Player = {}" in the table, while everything above it, is out of that table? What I'm wondering is, if you add a table like that there, is it even possible to create a variable that is not in that table anymore, and how would you do it?

I'm guessing it doesn't even matter, since you can use any variable separately later on in the code, but I'm just being curious about how the tables work...it seems very confusing.

Conceptually you're not really "in" a table when you create it or assign values to it, unlike how you can be "in" an if statement or "in" a function.

Code: Select all

player = {}    -- A new table.
something = {}    -- Another table! These are comments by the way, because of the "--" before them.
player.x = 10    -- Setting player.x to 10
something.woo = "Woo!"
x = 123 -- This isn't the same as player.x, it's just a variable all on its own

Posted: **Thu May 31, 2012 1:44 am**

Yep, the replies help

I understood dt in my own way, when I was looking at lynesth's explanation, but looking at that graph and your explanation showed it to me in a more detailed sense, more of a...how does it actually, hm, flow, until it gets to that 200 speed.

Anyway...

So...if I called table

Bla = {}

then I would have to write

Bla.x =...
Bla.y =...
..and so on?

under it, for it to be the part of the table?

While just

x =...

would not have anything to do with the table at all?

What I'm thinking now is that it's sort of a path. I'm not sure if I should be looking at tables like this, or not, but that's how I think it is, at the moment. I look at the table as a folder, and I look at the variables as files inside the folder. So all the variables under the actual line that creates a table, seem like paths to me. For a folder, it would be "player/x.exe", while with the actual table and variable in coding, it's player(table).x(variable), but the whole thing is actually a variable, and you need to write it whole, to actually call it.

Sorry for noobish comparison, but it makes it easier for me like that.

I'm failing to find a tutorial that actually shows what are tables for...a lot of tutorials use tables, but no one really shows their functions in a way that a beginner can understand it...at least none of the tutorials that I've checked out. Lua tutorials that I find are...well, not advanced, but the way they explain things, they assume that you will understand every term that they use...and sometimes you just don't, because you've never even heard of something. It's even more difficult for me, since I'm not from US, or UK. I mean, my English is pretty good, but there are some words that, even though I understand them, I have no idea what they mean when used to explain something about coding. It's kinda hard for me to explain what I mean with that...but, I don't know...I just need a different approach to explaining, to understand something faster and better.

Learning through comparison with something that exists in reality usually makes it easier for me to understand something.

Posted: **Thu May 31, 2012 2:08 am**

Skygrinder wrote: I'm failing to find a tutorial that actually shows what are tables for...a lot of tutorials use tables, but no one really shows their functions in a way that a beginner can understand it...at least none of the tutorials that I've checked out. Lua tutorials that I find are...well, not advanced, but the way they explain things, they assume that you will understand every term that they use...and sometimes you just don't, because you've never even heard of something. It's even more difficult for me, since I'm not from US, or UK. I mean, my English is pretty good, but there are some words that, even though I understand them, I have no idea what they mean when used to explain something about coding. It's kinda hard for me to explain what I mean with that...but, I don't know...I just need a different approach to explaining, to understand something faster and better.

Learning through comparison with something that exists in reality usually makes it easier for me to understand something.

Well, I would explain them as a group of variables.
They are very very useful because you can cycle through them and control them all at once!

For example, if I had 2 enemies in a game then I could have some variables like this:

enemy_1_x = 0
enemy_1_y = 0
enemy_2_x = 0
enemy_2_y = 0

and then just update them like that, and it wouldn't be that bad.

But then, suppose you have 100 enemies in a game!

That's an x and a y value for every single one of those, so that's 200 values you have to type out for updating every loop!
That's alot of typing!

But, if I were to put them all into a table, I can create them all, and update them all, in a loop that would be less then 1/4 the size of using variables!

for example:
enemies = {}

for a = 1, #enemies do
enemies[a] = {}
enemies[a].x = 0
enemies[a].y = 0
end

That just did what this did except for 100 instead of 1.
enemy_1_x = 0
enemy_1_y = 0

Do you understand why there so easy and useful now?

Also, as a side note:
Don't worry about sounding like a noob!
Everyone has to learn somehow, and I for one don't mind helping (even if you sound like a noob

)!
This is one of the nicest communities I have seen!

Posted: **Thu May 31, 2012 2:24 am**

I completely agree with you.

Skygrinder wrote:Lua tutorials that I find are...well, not advanced, but the way they explain things, they assume that you will understand every term that they use...and sometimes you just don't, because you've never even heard of something.

This is a problem. I assume this is because a lot of tutorials are written for people who already know some programming languages, or the author has forgotten which words and concepts they didn't know before. I really like this article at Programming in the 21st Century which is about this sort of thing.

Skygrinder wrote:Learning through comparison with something that exists in reality usually makes it easier for me to understand something.

Well said, this is as very important concept I think. And your comparison to folders is actually a really useful one for tables I think.

You need to create a folder before you can put things in it.
C:/player
player = {}

C:/player/x.exe
player.x = 123

C:/x.exe
x = 456

x and player.x aren't the same "file".

You don't have to put Bla.x =... and Bla.y =... directly under Bla = {}. You can put them anywhere, just as long as the table Bla exists. You can move x.exe and y.exe into C:/Bla, as long as that folder has already been created!

(Edit: The post below this makes a really good point also. This is just a metaphor and I hope it's not misleading. It's just temporary scaffolding; eventually tables won't seem like folders or anything else, they'll just seem like tables! I've also heard the metaphor that variables are like boxes with labels, and you put values in the boxes. Are these metaphors useful? Are they misleading and/or unnecessary? Can anyone learn anything if they don't relate it to something they already know? I have NO IDEA!

)

If you are interested, I would even suggest writing down the things that you don't and didn't understand, and the questions that you have/had, and the misconceptions, and you feel you "want" to learn, and the comparisons and examples which really helped you understand. In time, all these things will be obvious, however you will now have material which you can use to create a fantastic tutorial for beginners.

Just an idea!

Posted: **Thu May 31, 2012 2:54 am**

Skygrinder wrote:I'm failing to find a tutorial that actually shows what are tables for...a lot of tutorials use tables, but no one really shows their functions in a way that a beginner can understand it...at least none of the tutorials that I've checked out. Lua tutorials that I find are...well, not advanced, but the way they explain things, they assume that you will understand every term that they use...and sometimes you just don't, because you've never even heard of something. It's even more difficult for me, since I'm not from US, or UK. I mean, my English is pretty good, but there are some words that, even though I understand them, I have no idea what they mean when used to explain something about coding. It's kinda hard for me to explain what I mean with that...but, I don't know...I just need a different approach to explaining, to understand something faster and better.

Learning through comparison with something that exists in reality usually makes it easier for me to understand something.

I'll explain it my way :

A table in LUA is like a list : a enumeration of stuff (almost anything can fit in a table).
For example : I have 3 different apples named apple N°1, apple N°2 and apple N°3 which cost respectivly 10$, 15$ and 20$. I want to put that in a table, here is what I can do :

Code: Select all

apple = {"10$", "15$", "20$"}

See that all values are separated with commas. To access those values, I have to get the right item in the table.
Here is a sample to get some values :

Code: Select all

love.graphics.print(apple[1], 10, 10) -- This will print the 1st value in my apple table : 10$
love.graphics.print(apple[2], 10, 10) -- This will print the 2nd value in the table : 15$
--And so on...

"apple[1]" means that you need the 1st value in the "apple" table.
"apple[2]" makes you get the 2nd value in that table.
See that I have to use [ ] to get the value. The number inside those [ ] is call the "key".

You can manually set a "key" to a value in your table so you can get it easily.
There's two ways of doing it, one is shorter though:

Code: Select all

mytable = { ["key1"] = value1, ["key2"] = value2 }

This it the same as :

Code: Select all

mytable = {}  --This creates the table
mytable["key1"] = value1  --This appends the value value1 with key1 as key to the table (see this as adding something to a list)
mytable["key2"] = value2  --This appends the value value2 with key2 as key to the table

And is the same as :

Code: Select all

mytable = { key1 = value1, key2 = value2 }

Which (finnaly) is the same as :

Code: Select all

mytable = {}  --This creates the table
mytable.key1 = value1  --This appends the value value1 with key1 as key
mytable.key2 = value2  --This appends the value value2 with key2 as key

See that in this last method you use dot to specify the key.

Then, to get a value, you can do it the 2 ways :

Code: Select all

mytable.key1 -- Shortest way
mytable["key1"] -- A bit longer to write

This means that you need the value in the table named "mytable" which corresponds to the key "key1".

As I said before, you can put almost anything in a table. Another table for example :

Code: Select all

mytable1 = { mytable2 = { key1=value1, key2=value2 }, mytable3 = { key1=value1, key2=value2 } }

--To access the second value of mytable2, I might to that :
mytable1.mytable2.key2

Now let's say that our 3 apples are green, yellow and red and that hey are call rebecca, vanessa and bianca.
I want to create 1 table with all those informations :

Code: Select all

--To make this readable, I'll first 1 table called myapples which contain all my 3 different apples
myapples = { rebecca = {}, vanessa = {}, bianca = {} }

--Then I will fill those 3 tables inside myapples with some VERY IMPORTANT (:p) values
myapples.rebecca = { color = "green", price = "10$" }
myapples.vanessa = { color = "yellow", price = "15$" }
myapples.bianca = { color = "red", price = "20$" }

--Now, if I want to know the price of the vanessa apple I can get it this way :
myapples.vanessa.price

Once again, I might not be clear in my explanations though I tried my best.

See ya

PS : Excuse my english.

Edit : I deleted my last explanation so that you don't get too confuse. I don't want to teach you tables as if it was something else (tables are totally not folders). I know that it might be easier for you to understand but you may someday make mistakes and never really know what tables are. See what I mean ?

LÖVE

About dt...(edit: and something else)

About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)

Re: About dt...(edit: and something else)