#problem blending alpha (due to order of drawcalls)
32 messages · Page 1 of 1 (latest)
the depth buffer is just a yes/no test, it doesn't change blending.
you have two main options.
- draw back to front
- use a shader that discards fragments when they are under some alpha threshold so they don't write to the depth buffer.
option 2 does not require sorting, but it can only do a hard edge cutoff, since it's still just a yes/no test.
hmm, thats a tuff choice
does a 2d game like stardew valley suffer from sorting? will it make it slow?
I would not say it 'suffers' from sorting
it does sort for sure
sorting is very common
tilemap systems like stardew valley store data pre-sorted
using layers
i am verry bad at predicting process time lol
and it knows it's going to draw from Y0 to Y+
i alwayts think things take way longer then they actually do
so it stores the data in a way tht makes it easy to use.
generaly you sort once, then keep the sort
at least for data that is relativly static
i mean, stardewvally probably has the alpha choice anyway, because its fiels
then just resort the parts as they move.
all tilemaps sort in some way
layers are the most common
it stores the data in sorted layers
then just draws them in order.
hmm, maybe i will make a static and dynamic texture object, where the statics get sorted once in a big list (trees and flowers)
and the dynamics get then get placed inside that big list in the correct spot (the player, and other moving things)
is this a good selution?
you can also sort on the Y value
yea, thats what i ment by sorting woops
larger Y values tend to be 'closer' to the camera
but that i dont have to sort everything every iteration
yeah for a tilemap you want to sort your movers into the layers of your static things.
ah okay, then i am going to implement that, thnx!