Just out of curiosity, how close does my attempt to implement pset() come to the built-in version? Mine appears to be slower.
function my_pset(x, y, c) addr = 0x6000 + shr(x, 1) + shl(y, 6) old_val = peek(addr) if (band(1, x) == 0) then new_val = c + band(0xf0, old_val) else new_val = shl(c, 4) + band(0x0f, old_val) end poke(addr, new_val) end
Some (all?) Pico-8 API calls have arbitrary delays to simulate retro hardware, so it's likely nothing to do with the efficiency of your actual code.
If we assume for simplicity's sake that every API call has the same delay (AFAIK they don't), then your reimplementation of pset involves 2 API calls - peek() and poke() - which would make it twice as slow as calling pset() directly.
(I am kinda curious if "band(1, x) == 0" is slower or faster than doing "x % 2 == 0" though.)
BAND() certainly ought to be faster than a modulo, since division is almost always slow as molasses. I'm not sure if pico-8 counts lua operations equally though.
I never understand doing modulo instead of and, anyway. Doesn't it stop returning the correct result on negatives? I think most compilers emit a bunch of code to deal with two's-complement weirdness on negative numbers if you divide or modulo a signed integer instead of shifting/masking.
I say just do what you mean to have done... if you mean to check the bottom bit... then check the bottom bit with a single opcode every processor has. :) Likewise, if you mean to shift right, then shift right.
I should mention I am using the collective 'you' and not speaking to you specifically, Viggles. :)
[Please log in to post a comment]