Reduce slowdown during explosions
Expanded remake of 1994 Amiga game "Gravity Force 2".
Brought to you by:
mrhoppyx
Menu
▾
▴
Fixed in rev 12. copied from blog post:
I recently got a new graphics card because the onboard graphics on my desktop machine doesn't support multiple monitors. However, my PC's manufacturer didn't see fit to put in a full size PCI-E slot. I cut the end off the short slot and put in the new graphics card. It seems that the communication between the graphics card and motherboard is a bottleneck.
Following this, the game was slow when many explosions (or players colliding with level) happened about the same time. Investigation showed that this can be reduced by reducing number of image paste operations to bitmaps in graphics memory.
The level blast hole cutting and collision detection works by keeping 2 copies of the level image - one in regular memory for reading, and one in graphics memory for drawing. When a hole is cut by an explosion, an image is pasted to the regular memory image. The previous implementation which was causing slowdown would immediately copy this area to the graphics memory bitmap. The new version batches these operations together, with some cap on how long to wait before actioning each one (currently 11 game mechanic iterations). When one action reaches its expiry date, all other pending actions that meet some criteria are taken with it in a single image copy operation.
Having no restriction on which pending actions are batched together can result in the whole level being updated, if there is are edit operations in opposite corners of the map. This was the fastest version on my desktop. However, my netbook had some performance hit in this situation. Therefore there is some limit to patch size in this version of the code, which leads to the game working acceptably on both my machines.
The criteria is to group together image operations where the difference between the new area of rectangle containing both does not exceed the sum of the two areas by some limit.
There are many ways this might be improved, but system in rev 12 work sufficiently well.
======
things that might try if come back to this:
better batching algorithm
criteria that no overlap of areas?
draw updated area squares to get feel of what going on
only update area need to - eg explosion often on horiz or vertical wall so only half blast cut required. Less on a indestructible wall or in empty space
cut graphics memory image into squares. No need to have any images for blank space squares, indestr only squares never updated etc. Fairly pointless for during explosions speed because care more about slowdown in worst case than general speed. Looking to use update image from memblock might be faster than paste image to -ve bitmap though.
Lots of things to try. Probably shouldn't bother unless totally overhauling this part.