More than 13 seconds?

[kdyzlospotkasoba]

Hi Joey,
I was just wondering if there’s any way to squeeze more than 13 seconds from a standard 4MB cartridge.

As far as I know, SGDK uses its own compression method, LZ4w, which is based on LZ4. Would using it help achieve better results, or would it be too demanding for the Mega Drive/Genesis hardware?

Also, I’m not entirely sure, but could this particular video codec benefit from interlacing in terms of file size? Some older codecs do.

Reducing the number of unique tiles might also be beneficial, I think. Maybe integrating a script like this into the workflow could help:
https://github.com/bolon667/removeUniqueTilesFromImage

Have a great day,
David

[joeyparrish]

LZ4w can help you store more data, but the decompression would take up valuable CPU time we're using to push frames to the VDP. My guess is that this is not going to be a win.

---

I'm guessing that interlacing probably doesn't help. It doesn't reduce the amount of data we have to store or transfer. As far as I can tell, it really just changes the order of things in the tile map. That's assuming we interlace by rows of tiles, not individual lines. Interlacing rows of 8x8 tiles would probably be very noticeable at even double the current frame rate of 10fps. And interlacing individual lines would cost us more CPU cycles to render, since the VDP works in tiles.

I question whether older codecs actually benefitted from interlacing or if they just had to deal with it because that's what analog TV sources looked like. But in any case, we don't have a true "codec" here, we're just storing data in as close to the "native" format of the VDP as possible.

---

Deduplicating tiles in the encoder would reduce the data rate, but by how much would depend on the content. It's possible that this technique could make some frames smaller, but it would be inconsistent even within a single video. In the worst case, it would still mean a limit of around 136 frames + audio in 4MB.

You should probably just experiment with the technique in the encoder (could be done purely in Python during tile encoding) and see what kind of savings you get in the content you care about. If you are keeping a constant frame rate and just trying to cram in more frames, the only changes you would have to make in the file format and player would be to store the tile map for each frame in the encoded video, and have the player use that instead of the "trivial" tile map we have hard-coded today.

Tile maps are 1792 bytes (2 bytes per tile * 32 tiles wide * 28 tiles high), and tiles are 32 bytes each (8 * 8 pixels * 4 bits per pixel / 8 bits per byte), so if you don't find at least 56 duplicate tiles per frame on average (1792 / 32 = 56), you would actually be increasing the video size in ROM with this technique.

---

To go in another direction, the file format I built already has fields for video frame rate and audio sample rate, so you can absolutely encode video at a lower FPS, or audio at a lower sample rate, to fit more of it in the cartridge. You can make those quality tradeoffs if you like. The only thing you can't vary in today's encoder & format is the resolution. It's always full-screen.

---

My goal here was always to build a cartridge with SRAM and streaming capabilities to overcome the 4MB ROM limit, so I was always more focused on what would look and sound decent, and my encoder defaults are based on that. And the cartridge microcontroller has free cycles that it can spend on decompression, so I use a lossless RLE (Run-Length Encoding) scheme on the chunks, which gives me around 50% savings on bytes over the network.

That said, feel free to experiment! It's the beauty of open-source, right? You can encode your content differently, you can innovate on the file format, the player, try LZ4w compression, etc. I could be, and often am, wrong about things. I hope this project has brought you at least a little joy, and contributions are always welcome!