Though I did spend much time thinking about this, my idea was not correct.
The "tearing" and "previous frame is being shown while it is being drawn" is
simply because that's exactly what the logic in holly/core.cpp did.
This is no longer the case--by the time the newly-created core_flip function is
called, the core render is complete, and we should switch the FB_R_SOF1 to the
current framebuffer, not the one that is going to be written on next frame.
This also modifies alt.lds so that (non-startup) code now runs in the P1 area,
with operand/instruction/copyback caches enabled. This caused a 10x speed
increase in my testing.
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.
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.
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.
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.
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.
