This draws a nice macaw texture in a square-shaped triangle strip. The square is then rotated around the y-axis. I dealt with myriad bugs while experimenting with this, all of them entirely my fault: - macaw texture colors were incorrect because GIMP was exporting raw RGB data in gamma-corrected sRGB space, whereas the Dreamcast is in linear color space. - macaw texture colors were incorrect because I truncated color values to the least significant rather than most significant bits. - macaw rotation around the Y axis caused the macaw texture to distort, stretch and recurse in interesting and unexpected ways. This was caused by sending Z values in the wrong coordinate space (Z) contrast to what is expected by the Dreamcast (1/z). Reordering z-coordinate operations so that the reciprocal is computed last resolved this. - macaw rotation around the Y axis caused the macaw texture to warp unexpectedly, but only on real hardware. This was caused by unnecessarily negating Z coordinate values. Behavior for each of the Z-coordinate issues differed between Flycast and real Dreamcast hardware. I also did several tests related to SH4 cache behavior, particularly related to the "copy-back" mode. I verified copy-back behavior on a real dreamcast, and experimented with the operand cache write-back instruction, "ocbwb". In particular, when the `scene` buffer is access from cacheable memory, e.g: the P1 area, and CCR__CB is enabled, DMA from physical memory to the TA FIFO polygon converter will fail because the scene data has not yet been written to physical memory yet. `ocbwb` can be used to "write back" scene from the SH4 operand cache to physical memory--only the latter is visible from the CH2-DMA perspective.
6 lines
242 B
C++
6 lines
242 B
C++
#include <cstdint>
|
|
|
|
extern uint32_t _binary_macaw_data_start __asm("_binary_macaw_data_start");
|
|
extern uint32_t _binary_macaw_data_end __asm("_binary_macaw_data_end");
|
|
extern uint32_t _binary_macaw_data_size __asm("_binary_macaw_data_size");
|