Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
slime
Solid Snayke
Posts: 2918
Joined: Mon Aug 23, 2010 6:45 am
Contact:

Whatthefuck wrote: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
Party member
Posts: 106
Joined: Sat Jun 21, 2014 3:45 pm

slime wrote:
Whatthefuck wrote: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
Prole
Posts: 12
Joined: Fri May 29, 2015 7:55 pm

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
Prole
Posts: 39
Joined: Mon Mar 30, 2015 5:57 pm
Location: Slovakia
Contact:

BlueWolf wrote: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
Prole
Posts: 12
Joined: Fri May 29, 2015 7:55 pm

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
Prole
Posts: 49
Joined: Mon Sep 08, 2014 4:26 pm

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
Party member
Posts: 1077
Joined: Mon Sep 15, 2014 7:41 pm
Location: Cologne, Germany
Contact:

Jack Dandy wrote: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

s-ol.nu /blog  -  p.s-ol.be /st8.lua  -  g.s-ol.be /gtglg /curcur

Code: Select all

print( type(love) )
if false then
baby:hurt(me)
end

Jack Dandy
Prole
Posts: 49
Joined: Mon Sep 08, 2014 4:26 pm

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
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Jack Dandy wrote: 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.
Jack Dandy wrote: 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
Prole
Posts: 49
Joined: Mon Sep 08, 2014 4:26 pm