You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.
  • UI code is downloadable - currently as inline module attached to the post (it includes also the touch screen logic).

    I started to develop modules inline because I ran out of google closure compiler allowances with my highly iterative development style: add a method, test and debug it, then next...

    Regarding memory consumption: I tried to be as terse as possible - because I myself ended up on other occasions with Out of memory. For those cases I then encoded the information: instead of an array of numbers I used a string and calculated the value from the ASCII value of the character (it is the specification of the PacMan game board as part of the (still progressing) conversation at http://forum.espruino.com/conversations/­127039... unfortunately not yet posted there (yet), because I wanted to describe the encoding... I though posted a topic discussion regarding memory consumption regarding not consumption in conversation http://forum.espruino.com/conversations/­255954 with the encoded strings in post at http://forum.espruino.com/comments/11858­853/. bs - borders - describe the islands or maze walls, ns - nodes - describe the 'points' where paths split, intersect, or make a turn, and ss - segments - describe the paths between the nodes. Since the standard PacMan game board is a raster of defined/limited size, coding within printable ASCII characters with values 33..126. The attachments include a clip of the drawing process of the borders and the initial specification and code for it . Decoding to get numeric value is method v() in lines 107..110 (ignore unused second parameter a). P.w is the raster width in pixels to fit the display (horizontally).


    3 Attachments

About

Avatar for allObjects @allObjects started