I vaguely remember hearing people claim OP2 crashed when the resolution was set too high. I believe I know why.
The object that keeps track of the current view position also keeps track of what areas of the background have changed, so when it redraws the screen, it only needs to redraw the changed areas. The idea seems to be this can speed up drawing. The larger the screen size, the more memory is needed to keep track of updated regions.
The problem is, those buffers that keep track of updated regions are statically allocated. But, the good news is, all access seems to be done through some pointers to those statically allocated buffers. If that memory were allocated dynamically instead, then this problem could be overcome.
On another note, we could also try scrapping that whole system, as I suspect it doesn't really lead to any speed increases. Particularly if you scroll, in which case you're updating the whole screen anyways. Plus, if day and night is on, then that would also force screen updates. Or any other movement of light or vehicle animations, or even building animations. Basically it only seems to save time if you're look at some part of the map in the middle of nowhere, and not scrolling around either. At least that's what I suspect. I don't exactly have any timings to back up that claim. Plus, there is always the possibility that data gets used for something else I completely haven't thought of.
Oh, and the valid function that sets up the pointers is at:
0046F160 >/$ 5>PUSH EBX ; Function: Viewport.Initialize?(GFXSurface* surface)