Closed w0rm closed 7 years ago
I had to prefix MagnifyingFilter
options with magnify
because the names clash with MinifyingFilter
. Even though they are the same things internally, the magnifying filter only allows two possible options, so I want to limit it with types.
@Zinggi @lepoetemaudit could you please have a look.
It looks good to me - the level of the comments is really helpful for understanding how it corresponds to the WebGL equivalents, and I think all the defaults are very sensible. I'm guessing this pattern...
Texture.loadWith
{ textureOptions
| magnifyingFilter = Texture.magnifyNearest
, minifyingFilter = Texture.nearest
}
...means that if other textureOptions are added in future it will be backwards-compatible with older code. If so, I'm all in favour. I think there are quite a few other potential options that may need to be added in future (different source / target image formats for example).
Thanks for looking at this!
@lepoetemaudit what do you think about prefixed magnifyNearest
for the magnifying filter and unprefixed nearest
for the minifying filter?
@w0rm I agree with separating out the types. Perhaps we could prefix the minify, e.g. minifyNearest
, for consistency? Personally I don't much mind either way.
@lepoetemaudit I really don't know myself, I've considered this option, but then
minifyNearestMipmapLinear
would be too long. Anyway, I renamed for the sake of consistency.
I also added flipY
that is True
by default, so it doesn't break existing shaders. The reasoning behind this is that it makes it a bit harder to map the coordinates to texture.
This closes #24