High Resolution Bug

[Hooman]

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:

Code: [Select]

0046F160 >/$  5>PUSH EBX                                      ;  Function: Viewport.Initialize?(GFXSurface* surface)

[BlackBox]

Interesting.

I think the easiest fix would be to just replace the static buffers (and dynamically allocate them). The problem with that, would be that the buffers would need to be re-allocated every time the screen was resized (particularily, when the screen was made bigger. Otherwise the buffers are too small I would think).

Do these buffers store pixel data, or what? If they are just a list of rectangles to be redrawn I don't see how the size of them would really make much difference depending on the screen size (a rectangle is just a rectangle, it takes up the same amount of memory regardless of the actual dimensions of the rect).

[Hooman]

It's like a bitmap of which tiles need to be redrawn. So the higher the screen resolution, the more tiles it can fit, and the larger the bitmap needs to be.

So no, not pixel data. It's at tile granularity.



Could probably hook that procedure, let it run normally, setting the pointers to static buffers, and then overwrite them later. Might need to hook elsewhere too to clean up properly, such as during a resize. Although there might not be such code for all I know.

Or we can be lazy and assume it always gets enough space during startup, and leave the OS to clean up after it.