Am I right in assuming that the tile map is really just a list of palette indexes? That is, each nybble in the tile map is really just an indicator of the palette the tile uses? Since the palette index in the BAT requires 4 bits, this seems logical, especially when you consider that you don't really *need* to map out *tile* indexes since they would be contiguous, but the palette that each tile uses could change from frame to frame.
Correct. There is no compression via tilemap on the VDC side (most streaming video wouldn't benefit from it, plus it's kind of useless, unless you do a variable frame rate and buffer/cache system). So storing the tile indexes is redundant. Just the palette index is stored in raster map order (horizontal). Every frame contains a new palette for the BG.
The huvideo player uses custom CD routines to access the drive. It bypasses the system card. The system card functions aren't really optimal for doing such streaming. Plus, the normal system card cd_read function is slower than it needs to be. About 90k per second IIRC. Huvideo requires 122k a second transfer. Some the late gen SuperCD games also use custom CD read functions as well for faster access. I ripped the one from Seiya Monogatari game and it worked great for all my tests using it (disassembled thanks to MooZ's proggy). There's other stuff in the lib too, like LZSS decompressors (with all kinds of source/destination setups. Even LZSS decompress from ADPCM ram to VRAM, etc). Cool stuffs.
Topic: HuVideo (Read 861 times)
