Suggestion regarding love.run

[kikito]

...

I like that code. Some nitpicks:

• if and while don't need parenthesis on their conditions. Your loop will look less noisy without them.
• You don't seem to need width,height,fullscreen or fsaa. Just replace them with underscores: _,_,_,vsync = love.graphics.getMode()
• I actually think that disallowing drawing operations inside love.update is a good idea, so I would keep the clear() between update and draw

[Azhukar]

if and while don't need parenthesis on their conditions. Your loop will look less noisy without them.

I'm aware, personal coding style.

You don't seem to need width,height,fullscreen or fsaa. Just replace them with underscores: _,_,_,vsync = love.graphics.getMode()

_ is a valid variable name just like any other, so it would perform the same number of assignments if that was your point.

Code: Select all

_ = "foo"
print(_)

I see no reason to obfuscate the return variables otherwise. For clarity I did not cut off the returns after vsync.

I actually think that disallowing drawing operations inside love.update is a good idea, so I would keep the clear() between update and draw

If there was any (optional) feedback that drawing operations were attempted in update then I would agree.

[slime]

Currently I think the default love.run has these following issues:

1. love.timer.step is called after processing events, so event calls get different love.timer.getDelta return values than update / draw.

2. First update call is passed dt equal to loading time + event processing time instead of some arbitrarily small positive value.

3. love.graphics.clear is called between update and draw.
- If trying to draw in update had some (optional) feedback, this would not necessarily be an issue.

4. love.timer.sleep is called even with vsync turned on.
- It makes no sense to cap frame rate with vsync and a love.timer.sleep call at the same time.

5. love.graphics.present is called after the sleep call.

I have 'fixed' these issues in my version of love.run

1. I'm not sure of any case where it would be appropriate to use the delta time in a callback such as keypressed, that's what the isDown etc. functions are for. calling it directly before updating ensures the most accurate value for love.update.

3. update is for logic, draw is for drawing. It might be confusing if newbies mix them up, but then they probably have bigger code problems than that.

4. I don't believe the game loop would be affected (other than adding additional complexity) if this were checked, so I don't really see the point of checking.

5. This is changed for LÖVE 0.8.1 so sleep is called after present, however there are advantages in some cases with the current method. OpenGL calls are not processed the instant you call them, they're submitted to the graphics card and it works its way down the list of things to do while the CPU is doing other things (one of the benefits of having a separate processor for graphics operations). This means that, with the current ordering, the CPU may sleep while the GPU does work. If instead it sleeps after presenting, both the CPU and GPU will be idle during the sleep, possibly wasting frame time.

[Boolsheet]

5. love.graphics.present is called after the sleep call.

This is changed for LÖVE 0.8.1 so sleep is called after present, however there are advantages in some cases with the current method. OpenGL calls are not processed the instant you call them, they're submitted to the graphics card and it works its way down the list of things to do while the CPU is doing other things (one of the benefits of having a separate processor for graphics operations). This means that, with the current ordering, the CPU may sleep while the GPU does work. If instead it sleeps after presenting, both the CPU and GPU will be idle during the sleep, possibly wasting frame time.

I did not see any performance differences, though I did only test one implementation very briefly. I don't think many lovers will see an effect and only a few will care. Most of them can and will rewrite love.run anyway.

4. love.timer.sleep is called even with vsync turned on.
- It makes no sense to cap frame rate with vsync and a love.timer.sleep call at the same time.

Actually, once the sleep is after present, it approximates the vertical refresh better, making the input controls 1 millisecond snappier.

One of the developers agreed that the simple 1 millisecond sleep is a crude frame capper, but that it does its job reasonably well. And again, love.run can be rewritten by anyone.

[Xgoff]

One of the developers agreed that the simple 1 millisecond sleep is a crude frame capper, but that it does its job reasonably well. And again, love.run can be rewritten by anyone.

not to mention, i would imagine most (nontrivial) games would have trouble reaching 1000 fps anyway

[slime]

I did not see any performance differences, though I did only test one implementation very briefly. I don't think many lovers will see an effect and only a few will care. Most of them can and will rewrite love.run anyway.

Indeed, I wasn't arguing for changing it back, simply pointing out an advantage.

[bartbes]

I'd like to note you never clear the first frame.

[Santos]

2. First update call is passed dt equal to loading time + event processing time instead of some arbitrarily small positive value.

I may be misunderstanding things, but I think this was changed in LÖVE 0.8.0. From this page:

Fixed LÖVE's startup time being in the first dt.

Testing it, it seems that the first dt is smaller than the following dts.

[Azhukar]

I'd like to note you never clear the first frame.

Can something aside from the love module itself draw into the first frame? To my understanding the first frame starts cleared.

[Robin]

I agree with kikito.

As a side note:

_ is a valid variable name just like any other, so it would perform the same number of assignments if that was your point.

Code: Select all

_ = "foo"
print(_)

I see no reason to obfuscate the return variables otherwise. For clarity I did not cut off the returns after vsync.

Using an underscore is semantically clear, it signals that the return value will not be used (in some languages this is even built in, though not Lua).

Another solution is to use select:

Code: Select all

vsync = select(4, love.graphics.getMode())