Log In  

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)
    new_val = shl(c, 4) + band(0x0f, old_val)

  poke(addr, new_val)
P#22009 2016-06-01 00:13 ( Edited 2016-06-02 23:40)

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.)

P#22024 2016-06-01 05:44 ( Edited 2016-06-01 09:46)
:: Felice

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. :)

P#22125 2016-06-02 19:40 ( Edited 2016-06-02 23:49)

[Please log in to post a comment]

About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2019-11-18 21:43 | 0.013s | 2097k | Q:13