10 Commits

Author SHA1 Message Date
a0d516803b example: remove frame_ix double semicolon 2024-05-19 08:42:07 -05:00
bcaa9789cf texture_memory_alloc: rework texture memory allocation
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.
2024-05-12 17:06:00 +08:00
c0e10fe8f1 vga: delete
This is replaced with the (slightly cleaner) holly/video_output.
2024-03-08 20:46:55 +08:00
511d99563d maple_bus_commands: zero-sized structs should be zero sized
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.
2024-02-02 22:05:10 +08:00
1f6a29f379 example: update several examples 2024-01-03 23:32:37 +08:00
5db6272ceb example: add modifier volume
This creates a modifier volume with a cube that intersects a plane.
2023-12-30 15:11:22 +08:00
1078037226 icosphere: adjust lighting 2023-12-25 22:11:53 +08:00
8c5cd36078 icosphere: increase the size of ta_parameter_buf
This might accidentally work, but the number of ta parameters far
exceeded the previous value.
2023-12-25 22:04:25 +08:00
54f09bad01 ta_fifo_polygon_converter: properly calculate ta_next_opb_offset
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.
2023-12-25 21:59:26 +08:00
e340c3ca02 example: add icosphere 2023-12-24 17:48:20 +08:00