Yup, that's the only way to pinpoint the cause. Since hacking an assembly could create a non-working game in a variety of ways...here's a few easy suspects:
Indirect jump vectors no longer pointing to the correct "landing" spots.
Gfx data being shared with regular data (or even program instructions).
"Broken" or missing delimiters used in gfx tables.
Any hack that shifts anything in code is apt to break things severely unless all address dependencies have been taken into account in the disassembly, and even then there are no guarantees.
Also, some programs may have certain data dependencies with colors or even sprite data. In Adventure, for example, a bit of each color value is used to determine whether it should be interpreted as a "normal" value or a "flash" value (e.g. as used for chalice colors). Additionally, Adventure uses a zero byte to mark the bottom of each sprite's shape. This allows sprites of many different sizes to be stored efficiently, and also allows display to be started mid-sprite (which is how the porticus animation works). It does, however, mean that it's essential to avoid any blank rows within a sprite (that's why one of the bat frames has the funny dots above it, and why there are some extra dots in the Easter Egg message object). Further, a few games may make 'interesting' assumptions about colors or shapes. For example, in my Archon kernel demo, I use X and Y to hold the two color values (blue and yellow). In my kernel, I do
... draw the nice part of the frame
This provides a very nice way to avoid having anything show outside the proper area of the screen. But it only works if bit 2 of x is clear and bit 2 of y is set. Changing the values in X and Y to use different colors may cause that code to stop working if the wrong colors are chosen.