How to create a faster/more accurate image alpha check mouse hover function

[airstruck]

Assumption was that getPixel would interpolate if you supply it with halfway between pixels coordinates.

If that's the assumption, how is your "always check the manual, always do the testing" admonishment relevant? The manual doesn't say anything about whether getPixel interpolates, and obviously OP did the testing, that's why this thread is here. I don't see how these remarks are on topic.

The undefined behavior remark was there to specifically mention that even if you test something and it works but it's not 100% intended by design, you shouldn't use it anyway - that prevents "works on my machine" debacles.

How do you expect anyone to know if anything's "100% by design" when there's no formal specification for either the Lua language or the Love framework? Things work how they work. If the Lua manual or Love wiki doesn't say not to do something, and the thing is otherwise consistent with the documentation (say, passing numbers to getPixel), you simply have no way to know whether it's "100% by design" unless you go digging around looking at code comments / commit messages / mailing lists, and are lucky enough to find something relevant.

Anyway, I don't believe your remarks are relevant to this thread, unless there is actually some undefined behavior or bug here. If you believe there is, why not be specific about what you mean? If you don't believe there is, you're off topic.

[raidho36]

Well I don't believe your arguing semantics is relevant to this thread either, so we're even.

[zorg]

Just to short circuit this thing you guys did, i edited the wiki (because i can) to make both getPixel and getSample mention it not interpolating the parameters given. You're both welcome.

[airstruck]

Just to short circuit this thing you guys did, i edited the wiki (because i can) to make both getPixel and getSample mention it not interpolating the parameters given. You're both welcome.

That's a good start! Make sure to remove that nasty undefined behavior from the example code when you get to mouse.setPosition.

[zorg]

Just to short circuit this thing you guys did, i edited the wiki (because i can) to make both getPixel and getSample mention it not interpolating the parameters given. You're both welcome.

That's a good start! Make sure to remove that nasty undefined behavior from the example code when you get to mouse.setPosition.

Didn't test that... does it misbehave there? Worst case, it needs a math.floor which i'll add for safety, but still... didn't check the internals to see.

[airstruck]

Didn't test that... does it misbehave there?

No idea, I assume it does something reasonable, like floor it, or round it, but who knows? Just saying, there's going to be lots of cases like this on the wiki.

It's not like getPixel misbehaves, it's just an implementation detail. If you're passing it non-integers, half the time you probably don't care whether Love floors it, rounds it, interpolates it or whatever, as long as it does it consistently.

Should the wiki be making a recommendation like "only pass integers?" If Love's just doing whatever you'd be doing anyway, like flooring it, it's a nice convenience. I'd probably just write what happens, like "non-integer values are floored," if I were inclined to edit a bunch of wiki pages and rake through a bunch of Love source.

[bartbes]

For the record, that behaviour was (and is, I guess) considered a bug, that has since been fixed. It only affected the ImageData pixel accessors and the SoundData sample accessors, since they use ffi implementations when available. Indeed the fallback code, for when the ffi is unavailable, or when jit is disabled (which means ffi is slow) does not have this issue.

[zorg]

Well, even if it's fixed, one should know how things work in my opinion; how data is stored, in this case. For both images and sounds.
(Then again, one could implement a function to do things like interpolation as well...)

Something like

Code: Select all

function getSample(sdat, offs, itpl)
  if itpl == 'linear' then
    local int = math.floor(offs)
    local frac = offs-int
    return sdat:getSample(int)*(1-frac) + sdat:getSample((int+1))*(frac) -- should guard against indexing beyond the end...
  else -- 'nearest' or 'piecewise-constant', whatever
    return sdat:getSample(math.floor(offs+.5)) -- same here. 
  end
end

for example. (This is actually both an useful and common thing to do... though mostly for people like me who don't use the framework in usual ways )

[airstruck]

For the record, that behaviour was (and is, I guess) considered a bug, that has since been fixed.

That's extremely helpful, too bad you didn't get here earlier.

In that case, those wiki pages should probably have a version-specific warning message similar to the setMeter bugs. Without that, it doesn't make much sense to yell at users about "exploiting" bugs and UB. User got no benefit out of the bug, probably never knew it existed. Users really need to be able to assume that Love's implementation details are intentional; otherwise a lot of things would have to be made explicit in the documentation. As it is, wiki appears to encourage user to trust Love to do something reasonable, as in the mouse.setPosition example, instead of treating it like UB or coercion.

[bartbes]

As it is, wiki appears to encourage user to trust Love to do something reasonable, as in the mouse.setPosition example, instead of treating it like UB or coercion.

I'm not sure what you mean by "coercion", in this case, but the coordinates are floored, there's still no (magic) interpolation. It just doesn't spit out garbage anymore.