Also adds the incomplete modifier_volume example.
This also adds vec2 for UV coordinates, and obj_to_cpp has been
modified to parse vertex texture coordinates from obj files.
I think this was only relevant when END_OF_RENDER_VIDEO was in use;
this doesn't seem to affect flycast's END_OF_RENDER_TSP
generation. The former is definitely a flycast bug.
The main issue with the previous code:
constexpr uint32_t tiles = (640 / 32) * (320 / 32);
Should have been:
constexpr uint32_t tiles = (640 / 32) * (480 / 32);
The consequence of this is some OPBs were being overwritten by
TA_NEXT_OPB, causing corruption (missing triangles, incomplete
drawings) in some tiles.
0x15 is 21, which is larger than the OPB size (16).
The 0x15 value directly causes CORE to hang given a sufficiently
"large" object list (more than ~2 triangles per tile).
After changing pointer burst size to the intended value, 15, CORE no
longer hangs while drawing "large" object lists.
This enables alpha blending for both font_outline and
font_outline_punch_through.
I have also experimented more with 16-gray vs 256-gray--I have not
decided which between monochrome, 16-gray, or 256-gray I like the
most.
Perhaps a better test might be to test hanzi.
Previously, due to the ordering of .text.p2ram and .bss, the linker
was forced to allocate .bss in the output file, increasing the size
of the final binary unnecessarily.
The linker scripts now preserve debugging symbols during linking.
This fully threads both the real minimum size of the texture and the
dimensions of the texture through to the TA parameters.
This also removes spurious zero-area drawing commands (space
characters).
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.
This is very barebones, and uses the serial interface to communicate
the status of the "a" controller button being pressed.
I'd like to make this a more interactive/graphical demo.
The <uint8_t> template instantiation was causing 8-bit writes to the
command buffer, when they were intended to be 32-bit writes. This
garbled and truncated the data ultimately sent to the VMU LCD.
This also adds ta_parameter_writer; I am not certain if I like this,
but it felt necessary to deal with ta_parameters being either 32 or 64
bytes long--for this reason, a reinterpret_cast to a union is less
attractive (the union members are not a fixed size).
