0xff

In the process of making changes to psplib’s video rendering routines, I came across a strange problem – calling a certain library function resulted in screen and palette corruption. Since the function was used to access contents of the VRAM, I figured it was because I was writing to the wrong location in memory somewhere.

The strange thing was that I had a similar function already in place, and except for some minor semantic differences, the code was the same. Even more surprisingly, commenting out the code that called the function did not help – the only thing that did was completely removing the function’s definition.

I finally tracked down the problem to the compiler’s optimization flag (O2). Completely disabling optimization with (-O0) got rid of the corruption. I’m not sure if this will have any detrimental effects on the rendering library in terms of speed (I doubt that it will, as psplib’s renderer is extremely frugal), but I suppose that I’ll eventually find out.

UPDATE It looks like optimization (much like the proverbial chinaman) is not the main issue here. While I haven’t completely resolved the issue, it is fairly certain that it’s related to reading/writing to VRAM. The issue seems to be commonplace, and I’ve found possible explanations here and here (see section marked Important).