Total Newb Confused with Simple Test (More Issues)

[bartbes]

I'd like to note that the toggle function in your post is unneeded and inefficient, this works:

Code: Select all

textToggle = not textToggle

As for why the love.draw example was "wrong", it's because the purist view says draw should really only draw, and not do any "thinking", specifically not mess with anything not directly related to drawing. In this case, the draw code only needs to know if something is drawn, and isn't "supposed to" care about when that happens, just if it happens.

EDIT: Ninja'd, this applies to MarekkPie's post.

[MarekkPie]

I'd like to note that the toggle function in your post is unneeded and inefficient, this works:

Code: Select all

textToggle = not textToggle

As for why the love.draw example was "wrong", it's because the purist view says draw should really only draw, and not do any "thinking", specifically not mess with anything not directly related to drawing. In this case, the draw code only needs to know if something is drawn, and isn't "supposed to" care about when that happens, just if it happens.

EDIT: Ninja'd, this applies to MarekkPie's post.

Clever on the toggle.

To get slightly off topic, then how would you go about doing any toggling of drawn images? To me, love.draw() is thinking in both of these scenarios:

Code: Select all

function love.draw()
  -- Scenario A
  if toggle then
    love.graphics.print(...)
  end


  -- Scenario B
  if love.keyboard.isDown("p") then
    love.graphics.print(...)
  end
end

Both scenarios have an if statement. Both scenarios must check a boolean. Once you break that barrier, any more thinking doesn't make it any worse, in my opinion.

The alternative would be:

Code: Select all

function love.update(dt)
  if love.keyboard.isDown("p") then
    textToggle = true
  else
    textToggle = false
  end
end

function love.draw()
  if textToggle then
    love.graphics.print(...)
  end
end

But to me, that's going WAY out of your way to do something just to follow some made-up convention. If you decided to run some huge algorithm inside love.draw(), I understand, but , I mean, c'mon. (bartbes: you used quotes around wrong, so you might not agree with the purist viewpoint. But I'm just trying to understand why.)

[tentus]

But to me, that's going WAY out of your way to do something just to follow some made-up convention. If you decided to run some huge algorithm inside love.draw(), I understand, but , I mean, c'mon. (bartbes: you used quotes around wrong, so you might not agree with the purist viewpoint. But I'm just trying to understand why.)

I believe that the general idea in separating draw and update is that you want everything to be "caught up" when you draw it. You don't draw some stuff, work through some physics, and then draw some more stuff. You separate heavy logic and rendering apart, so that the render gives you as close to an instantaneous snapshot as possible. Working through some booleans is close to free on a modern computer, but running AI and physics... well, that could cause things to get out of sync.

[bartbes]

You example is again inefficient:

Code: Select all

function love.update(dt)
  textToggle = love.keyboard.isDown("p")
end

function love.draw()
  if textToggle then
    love.graphics.print(...)
  end
end

Anyway, I agree in this case the difference isn't that big, however, one could argue that putting all checks in the same place(s), makes it easier to change a key. What if you hardcode this check in love.draw now, and you decide you want to turn it on with something else? You'll have to modify love.draw, if for some reason this was a complicated check, you now have 'thinking' in your draw function. If it's just a boolean somewhere, your complicated code can set that boolean, and things will just work.

[kikito]

... What if you hardcode this check in love.draw now, and you decide you want to turn it on with something else? You'll have to modify love.draw ...

Well said!

[MarekkPie]

Sorry to keep this on the offtopic, but what exactly do you mean by "hardcore"? (Only started programming three months ago.)

[Ellohir]

Not "Hardcore", "hardcoded". http://en.wikipedia.org/wiki/Hard_coding (you can check the link tomorrow). It's when you make something that works but will be difficult to modify (like opening files with the filename strings everywhere instead of declaring a string variable with that filename and use the variable).

Anyway, separating draw and logic should be done. Rendering full frames at low FPS is bad; but rendering half of the things, then a thinking pause, then the rest... Seems horrible. Being organized pays off

[Robin]

Sorry to keep this on the offtopic, but what exactly do you mean by "hardcore"? (Only started programming three months ago.)

It's hardcode, and it's basically the programmer making assumptions that might not hold later.

For example, if you hard-code the window size of your game as 800x600, you mention those numbers all over the place in your code, and if you want to change the size of the window later, say you think "with the size that current monitors have, the window could be larger". Then you have to do a lot of work to make it work.

But if you define a WINDOW_WIDTH and WINDOW_HEIGHT (for example) and use that all the time, you'll have much less of a problem changing the resolution later.

[kikito]

It's "hardcode", not "hardcore" . And it's a verb, not an adjective - the adjective is "hardcoded".

Strictly speaking, something "hardcoded" is something which "that you can only change by editing the source code". The opposite example would be "data driven" or "parametrized".

A typical example: a game that you have to recompile to change the player speed (for example), then that it "hard-coded". If you can change that behaviour by modifying a config file, then it's "less hardcoded". And if you can modify it using the game's interface, it's not harcoded at all. (I'm aware that in LÖVE and Lua the line that separates a "config file" or a "data file" from a "source file" is very tenuous).

Nevertheless, I'm seeing "hardcoded" being used as "programming in an inflexible way" these days. The typical example is when you use numbers instead of variables in your code. For example, on the following code, "2.5" and "0.5" are "hardcoded".

Code: Select all

function moveLeft(player, dt)
   player.x = player.x + 2.5*dt
end
function moveUp(player, dt)
   player.y = player.y + 0.5*dt
end

They represent horizontal and vertical player speed. They are very likely to be used in other places. Better give those numbers a name:

Code: Select all

horizontalSpeed = 2.5
verticalSpeed = 0.5
...
function moveLeft(player, dt)
   player.x = player.x + horizontalSpeed * dt
end
function moveUp(player, dt)
   player.y = player.y + verticalSpeed * dt
end

There are several reasons for this. First, these numbers are likely to be used in other parts (trajectory calculations, etc) so it makes sense to have them in one place, so you can change one line and that changes everything. But also it makes the code more readable for humans.

With the old meaning, the player speed is still "hardcoded" - you still have to modify the source to change the player speed. But the code itself can be very easily, and flexibly - it's "less hard to code", or less "hardcoded" in the second meaning of the word.

On your code the "hardcoding" happened because to two parts of your code - key pressing and player logic - that where unnecessarily coupled. Using a boolean decouples them; now more things can move your player, for example, gravity, or a cutscene. With a little change, you can use that same code to move enemies around, too.