The previous texture_memory_alloc.hpp was written based on an
incorrect understanding of the "32-bit" and "64-bit" texture memory
address mapping.
The primary motivation is to rearrange the texture memory address map
so that "textures" (64-bit access) do not overlap with 32-bit
accesses, such as REGION_BASE or PARAM_BASE.
From the GCC manual.
> GCC permits a C structure to have no members:
struct empty {
};
> The structure has size zero. In C++, empty structures are part of the
> language. G++ treats empty structures as if they had a single member of type
> char.
I was not aware of the different behavior in C++.
This fixes every maple example--most were broken for multiple reasons, including
this one.
This also enables SH4 caching. This includes linking code/data into the P1
area (previously this was not the case).
The maple examples (which indeed involve much use of DMA) require much work to
successfully work with the operand and copyback caches. The vibration example
currently is the most complete, though I should consider more on how I want to
structure maple response operand cache invalidation more generally.
There are still texture sampling issues that I don't understand. Until
I properly understand this, using (bitmap) fonts that have
power-of-two dimensions seem to produce "acceptable but incorrect"
results.
This still needs to be cleaned up, particularly to properly pass the
texture size around--there are a few unnecessary '128x256' magic
numbers scattered in the code.
I think the original version is more readable, but the newer version
is better overall because it doesn't require reading from dst, and is
able to directly write to a 32-bit dst.
