"Questions that don't deserve their own thread" thread

[slime]

Is there a way to have a spritebatch use nearest filtering instead of linear? Setting the filter mode to nearest on the texture I wish to use on the spritebatch doesn't seem to work. (ie still uses linear)

SpriteBatches are just collections of vertices. Filtering modes are only applied to textures, so using Image:setFilter will work if that image is used in the SpriteBatch.

[Whatthefuck]

Is there a way to have a spritebatch use nearest filtering instead of linear? Setting the filter mode to nearest on the texture I wish to use on the spritebatch doesn't seem to work. (ie still uses linear)

SpriteBatches are just collections of vertices. Filtering modes are only applied to textures, so using Image:setFilter will work if that image is used in the SpriteBatch.

Ah, that explains it, as I use a canvas for the spritebatch. Is there a way to apply a filter on a canvas?
EDIT: nevermind, just checked the wiki, you can

[BlueWolf]

Sanity check: Does computing 500-1000 circle intersection checks per update cause slowdown or am I doing something really stupid? I'll do some profiling tomorrow but if anyone can answer from experience before that I would be thankful.

[deathbeam]

Sanity check: Does computing 500-1000 circle intersection checks per update cause slowdown or am I doing something really stupid? I'll do some profiling tomorrow but if anyone can answer from experience before that I would be thankful.

Of course it will cause slowdown. Why are you even doing that?

[BlueWolf]

Is it that much? Imagine you have 32 enemies and 16 bullets on the screen and bam, you have 512 checks per frame. Unless you do some fancy space partitioning, that is. Or am I still missing something obvious? Is there some other way to check if bullet hit enemy? I just feel like modern computers should be able to handle couple dozen moving sprites at the same time.

[Jack Dandy]

Keeping an eye out for BlueWolf's question, the answer interests me as well.

But I have something on my mind as well:

How does the actual code "run" when it comes to the update and draw functions?
Do they run in "parallel" to the rest of code, or not? IE Does a function need to "end" before being the allowed to go back into the update-draw cycle?

This leads into my next question:
I was trying to make a "wait for player input" bit in one of my functions by making an infinite loop that you can 'break' out of by pressing a mouse button somewhere.
It promptly froze my game.
Is this problem related to the above question?

Also, what happened to all the nice tutorials on the wiki? They up and vanished!

[s-ol]

Keeping an eye out for BlueWolf's question, the answer interests me as well.

But I have something on my mind as well:

How does the actual code "run" when it comes to the update and draw functions?
Do they run in "parallel" to the rest of code, or not? IE Does a function need to "end" before being the allowed to go back into the update-draw cycle?

This leads into my next question:
I was trying to make a "wait for player input" bit in one of my functions by making an infinite loop that you can 'break' out of by pressing a mouse button somewhere.
It promptly froze my game.
Is this problem related to the above question?

Also, what happened to all the nice tutorials on the wiki? They up and vanished!

All functions run synchronioulsy, in the same context and process. That means that no other function can run whilst the current one is active. The only way to break out from that is to run multiple threads (love.thread module).

An infinte loop waiting for input can only work if it also does event handling, love doesn't know about mouse buttons being pressed until the corresponding event gets polled from the event queue (love.event.pump() & love.event.poll()) and then handled.

For reference, you could look at the default love.run and the love.event module

[Jack Dandy]

Ah, that clears things up a fair bit, thanks.
Although, doesn't "synchronously" mean "running at the same time"? From the way you described it, that doesn't sound like the case.

Anyway, guess I'll have to rethink the way I implemented that one function...
(Also where da tutorials at )

[bartbes]

Although, doesn't "synchronously" mean "running at the same time"?

No, it doesn't. Maybe you're thinking of "concurrency"? (Though that doesn't imply parallelism either.)
Alternatively, asynchronism is usually used as poor man's concurrency.

I was trying to make a "wait for player input" bit in one of my functions by making an infinite loop that you can 'break' out of by pressing a mouse button somewhere.

There's different ways of managing this, but they basically all come down to some state management. You can do some funky stuff with coroutines if you're willing to set that up.

Also, as it's time for shameless self-promotion, if at some point you do want easy parallelism, there's a lib for that (which I still mean to write some futures API for at some point).

[Jack Dandy]

Alright, thanks to the both of you. Will look into coroutines and states.