How GEDS scrolling works

The scrolling routines of InfiniMap weren't as well documented as I hoped. Not even when I blogged that "yeah, it finally works". And while trying to document them, I noted some undesired difference between what the code does and what I claimed it does in the comments. So here it goes. First this is the full level map, stored as a 2D array of tiles. Within them, we define an area of world coordinates (xmin,ymin)-(xmax,ymax) that is guaranteed to be present in the video memory as well. That is the "invariant", the condition that was true on the first line of a scroll_*() call and that must be restored before we leave the function.

    if (py < ymin + WH / 2) 
      do { up_scroll(); } while (py < ymin + WH / 2);
    else if (py + WH / 2 > ymax) 
      do { down_scroll(); } while (py + WH / 2 > ymax);
    if (px < xmin + WW / 2) left_scroll();
    else if (px + WW / 2 > xmax) right_scroll();

WWxWH is the dimension of the validty area. We will never let xmax - xmin < WW happen. To decide whether scrolling routines should update the contents of video memory, the scrolling code compares the position of the camera (i.e. the center of the viewport) with the coordinates of the area. If it gets too close to one edge of the 'validity area', video memory contents will be updated and that edge will be moved, possibly dragging the opposite edge along (since we have fixed-dimension video memory)

  void right_scroll() {
    unsigned xoff = (xmax - xmin) / TL;
    // compute target position in video memory
    u16 *src = dataview + xoff;

    xmax += SQ; // new validity window will end 64 pixels on the right.
    if (xmax - xmin > 512) { 
      xmin += SQ;
      xview = (xview + SQ / TL) & 63;
      dataview += SQ/TL;
    }
    // copy from src to video memory
    // so we fill the expanded area with valid tiles. 
} 

Then, this is the video memory. The hardware reads it as a 2-dimensional wrapping array, that is if it cannot read more at the right, it goes back reading on the leftmost column. The (xview,yview) reference point corresponds to "where in the video memory is (xmin,ymin)" (that was the part that needed a patch).

Note that only a part of that valid area will show up on screen (highlighted here).

Note that whatever happens, xmin always shifts by 64 pixels. That's the horizontal copy granularity SQ (because it was meant to be square), and no, I never checked it led to better performance than 32. We must have ScreenWidth + 2*SQ < VramWidth, though.