title: Javascript allocation of tilemap in browser
body: <p>I am currently building a small turnedbased maze game. The maze is 2D and build up by tiles - much similar to Zelda map kinda games.</p>
  
  <p>I have minimum 256 different tiles to select from and I will be reusing them a lot for different areas, such as buildings, trees, walls, grass, water etc. </p>
  
  <p>My plan is to make it run as smooth as I can without using any other framework than jQuery for Ajax and DOM manipulation.</p>
  
  <p>The game-engine is server-side, so the client browser is not performing any of the AI-logics etc. Its just requesting the "current state" of the game, then receiving the objects/enemies etc. But it has the levelmap downloaded from the start. The level could be like 256x256 tiles and each tile could be 32x32 pixels... havent decided on the block size yet, but I think thats the most optimal. Might be larger though.</p>
  
  <p>The player viewport will probarbly take up around 9x9 tiles or perhaps 15x15 tiles. Then you will scroll to see action and move around. </p>
  
  <p>As its turnbased, so no worries for "screen flickering 60 fps" a single flicker here and there is okay, but not all the time.</p>
  
  <p><strong>My question is: Whats the most optimal way to generate the map in the client?</strong></p>
  
  <ul>
  <li>1) should I transfer the map as "data" (json or similar) and then generate DIV's with CSS to build the tilemap in the client. This will minimize the bandwidth, but I fear that the DOM in the client will be at hardwork when I scroll the map?</li>
  </ul>
  
  <p>or</p>
  
  <ul>
  <li>2) should I prerender the full tilemap or larger parts (squares) of the map so that the browser has less DIV's to handle. This will kill reuseability for the maps as they are hardly patterned, so its just going to be "pure graphic download" + the tilemap information needed for the game collision etc. It ought to be faster to scroll for the browser.</li>
  </ul>
  
  <p>I cant figure out if it will take more or less resources once downloaded with the second approach, as the client/browser will have to allocate memory for all the larger "prerendered" blocks instead. But if its the "data optimal" solution from 1) its also going to be generating a lot of DIV's with class' and render these in the browser DOM somehow.</p>
  
  <p>SVG and canvas is currently not an option, unless someone can provide me with a fast way of converting alpha transparent PNGs' to canvas and still being able to scroll around with a viewport (with as many FPS as possible though, aka more than 15 fps)</p>