calc_push op loop golf

Reorganizing conditionals saves tokens here.
can_move also takes a rope operation table
2023-01-02 15:58:23 -08:00 · 2023-01-02 15:57:27 -08:00 · 2023-01-02 15:35:10 -08:00 · 2023-01-02 23:08:10 +00:00 · 2023-01-02 23:08:03 +00:00
1 changed files with 23 additions and 26 deletions
--- a/chameleonic.p8
+++ b/chameleonic.p8
@ -633,10 +633,12 @@ end

 ropecheck=split"-0.6,0.4,0.4"

+-- argument "o" is a rope operation:
+-- array of [mx0,my0,dmx,dmy]
 function level:can_move(
- is_player,
- mx0,my0,dmx,dmy,exclude_src,exclude_dst
+ is_player,o,exclude_src,exclude_dst
 )
+ local mx0,my0,dmx,dmy=unpack(o)
 local mx1,my1=mx0+dmx,my0+dmy
 if (is_player and self:win_at(mx1,my1)) return true 
 if (is_player and self:get_open_pit(mx1,my1)) return wrongbleep:adequately_warned()
@ -652,7 +654,10 @@ function level:can_move(
 return true
 end

-function level:tug_crate(mx0,my0,dmx,dmy)
+-- argument is a rope operation:
+-- array of [mx0,my0,dmx,dmy]
+function level:tug_crate(t)
+ local mx0,my0,dmx,dmy=unpack(t)
 local mxy0=_mix{mx0,my0}
 local existing=self._crates[mxy0]
 if (not existing) return
@ -734,7 +739,7 @@ function player:update()
  else
   local x,y=self.x,self.y
   local function try_move(dx,dy,f)
-    if level:can_move(true,x,y,dx,dy,0,2) then 
+    if level:can_move(true,{x,y,dx,dy},0,2) then 
     self.todo=f 
     self.cooldown=3
     local t=f[#f]
@ -1540,22 +1545,19 @@ function rope:_tug(hypothetically)
 local blocks = {}
 for i=#ancs-1,2,-1 do
  local ops_before_trash,blocks_before_trash=self:_calc_push(ancs[i+1],ancs[i],ancs[i-1],ancs[i-2])
-  local ops_to_do,corners={}
+  local ops = {}
  for b in all(blocks_before_trash) do add(blocks, b) end
  if #ops_before_trash>0 then 
-   ops_to_do=ops_before_trash
+   ops=ops_before_trash
  else 
   local ops_after_trash,blocks_after_trash=self:_calc_push(ancs[i-2],ancs[i-1],ancs[i],ancs[i+1])
-   ops_to_do=ops_after_trash
+   ops=ops_after_trash
   for b in all(blocks_after_trash) do add(blocks,b) end
  end

-  local ops=ops_to_do
-
  if #ops>0 then
   if (hypothetically) return ancs,i-1,ops,blocks
-
-   for o in all(ops) do level:tug_crate(unpack(o)) end
+   foreach(ops, level:tug_crate)
   return true
  end
 end
@ -1604,13 +1606,14 @@ function rope:_tug(hypothetically)
  end
  
  if not invalid_move then
-   if level:can_move(false,mx0,my0,dmx,dmy,1,0) then
-    if (hypothetically) return ancs,0,{{mx0,my0,dmx,dmy}},blocks
+   local mv = {mx0,my0,dmx,dmy}
+   if level:can_move(false,mv,1,0) then
+    if (hypothetically) return ancs,0,{mv},blocks

-    level:tug_crate(mx0,my0,dmx,dmy) 
+    level:tug_crate(mv) 
    return true
   else
-    add(blocks, {mx0,my0,dmx,dmy})
+    add(blocks, mv)
   end
  end
 end
@ -1687,17 +1690,11 @@ function rope:_calc_push(

 local ops2,blocked={},{}
 for o in all(ops) do
-  local mx,my,dmx,dmy=unpack(o)
-  if not level:mcoll(mx,my) then
-   -- great!
-  else
-   local crate=level:get_crate(mx,my)
-   if crate then
-    if not level:can_move(false,mx,my,dmx,dmy,0,0) then
-     add(blocked,o)
-     break
-    end
-   else
+  local mx,my=unpack(o)
+  if level:mcoll(mx,my)
+   if not (level:get_crate(mx, my)) break
+   if not level:can_move(false,o,0,0) then
+    add(blocked,o)
    break
   end
   add(ops2,o)
Author	SHA1	Message	Date
Kistaro Windrider	78f0a96529	calc_push op loop golf Reorganizing conditionals saves tokens here.	2023-01-02 15:58:23 -08:00
Kistaro Windrider	d792831370	can_move also takes a rope operation table this is approximately token-neutral but performance-saving. each function parameter makes its call cost worse. When can_move is called inside a loop, we already have a table and we unpack to call can_move; moving the unpack into can_move saves us marshalling cost. It requires us to construct a table in a different spot (where we were not previously doing so) but that spot is not in a loop.	2023-01-02 15:57:27 -08:00
Kistaro Windrider	b1cc74fe3b	Remove unused vars, convert tug_crate arg to table The tug_crate conversion is for performance. `foreach(tbl, predefined_func)` is substantially faster than a standard `for` loop using the `all` iterator. However, if the function inside the foreach is defined inline, it's much slower due to closure-construction overhead (even though nothing is being closed over). Converting `tug_crate` to take a table as an argument allows foreach to feed right into it, and it also naturally suggests a rewrite a few lines down to get rid of duplicative listing of `mx0,my0,dmx,dmy`, saving several tokens. I'm going to take a look at can_move to see if it's worth making iits mx0,my0,dmx,dmy arguments into a table as well.	2023-01-02 15:35:10 -08:00
Kistaro Windrider	0aeeb1975b	Show blocked crate moves (#24 ) Save/load system. Not golfed. Saves the music flag, the last level the player played, and the furthest level reached. Loads music flag on launch. Title screen starts on most recent level played; when in "release configuration" the title screen will only let the player pick levels up to the maximum reached through gameplay, but right now this is replaced with the 31. Save file can be wiped by holding the down arrow at the title screen. block writes while reading Disabling writes during "wipe" and "first load" is not quite semantically what we want, it's writes during read we want to block. This happens because turning the music on or off tries to save the state, and it's easier to just ignore that persistence request than to rework the music code so it doesn't. "wipe" and "first load" are when we're actually reading (and enacting) state, but it's the act of reading rather than those two acts that should block writes. It is also unwilling to write until it's done its first read, which I think is a feature; it makes it harder to accidentally blank out the player's data. Show blocked moves as an animated X. I am not convinced the sprite is very good. This could help the player learn what pulls were considered before proposing the ones that would occur if the player pulled the tongue. Or it's just visual noise that sucks. Anyway, this correctly captures what the blocked considered moves were, and we can decide whether to use it or not. Reviewed-on: pyrex/chameleonic#24 Co-authored-by: Kistaro Windrider <kistaro@gmail.com> Co-committed-by: Kistaro Windrider <kistaro@gmail.com>	2023-01-02 23:08:10 +00:00
Kistaro Windrider	b6d1a21b7e	Basic save/load system (#23 ) Save/load system. Not golfed. Saves the music flag, the last level the player played, and the furthest level reached. Loads music flag on launch. Title screen starts on most recent level played; when in "release configuration" the title screen will only let the player pick levels up to the maximum reached through gameplay, but right now this is replaced with the 31. Save file can be wiped by holding the down arrow at the title screen. block writes while reading Disabling writes during "wipe" and "first load" is not quite semantically what we want, it's writes during read we want to block. This happens because turning the music on or off tries to save the state, and it's easier to just ignore that persistence request than to rework the music code so it doesn't. "wipe" and "first load" are when we're actually reading (and enacting) state, but it's the act of reading rather than those two acts that should block writes. It is also unwilling to write until it's done its first read, which I think is a feature; it makes it harder to accidentally blank out the player's data. Reviewed-on: pyrex/chameleonic#23 Co-authored-by: Kistaro Windrider <kistaro@gmail.com> Co-committed-by: Kistaro Windrider <kistaro@gmail.com>	2023-01-02 23:08:03 +00:00