SpritesMind.Net

It's a few hundred lines of C. On x86_64, the compiled binary size is 13kb.

edit: Built for the Genesis, it's 6.2kb.

Thanks, I updated the ROM. Can you do a quick test on hw?
https://github.com/clbr/gentest/blob/master/game.bin.xz

aplib is closed source, and therefore I won't use it no matter how good it is. EDIT: This is for level data, and other user things, not for tile compression. It could be used to tile compression too, but I intended it to be exposed so the users can compress game-specific data.

Zlib is also industry ...

Zlib compresses rather well, for level data, etc.

Using miniz tinfl at -O3, the Genesis decompresses at 23.1 kb/s. It uses about 11kb of RAM. The optimized implementation for the NES uses 1.2kb RAM, but as 11kb is not that much, and the C source was easy to port, I didn't try to reduce the RAM ...

Yes, but isn't a DMA fill 2x faster than cpu fill? So even when blocking, it's less time spent.

I'm using the default Makefile from gendev. I'll compare with what is in sgdk.

So to recap, the right fix is to wait for DMA completion right after VDP_clearPlan?

Hm, would it be too much overhead to add VDP_waitDMACompletion() to the start of every VDP function, thereby making all functions safe to use, and also allowing user code to do non-VDP things when the DMA fill is going on?

If it was made an inline function, that'd be just one or two instructions.

To do it slow, and not have partial updates show, you need to double buffer. Which means: both planes will be used for your animation, nothing left for your game but sprites.

-O3: 27s, 0.015x realtime. Dropping it here, may Google preserve this to all eternity.

A couple posts above:

Okay, I have a redistributable test ROM that shows the issue here:
https://github.com/clbr/gentest/raw/master/game.bin.xz

Sources are in the same repo:
https://github.com/clbr/gentest

I'd appreciate if you could try it on your hw. And maybe build it too, so we can isolate ...

Can you confirm the current ROM has issues on hw, and that fixes it?

Also, this really needs to be documented. Every dangerous function needs to have big warnings.

First results are in: Opus runs successfully on the Genesis, and needs even less RAM than expected.

Downside: the current build, completely unoptimized C and -O2, took 57.5 seconds to decode 400ms of audio, making it 0.0069x realtime. :D

I might try O3 later, sadly without PGO since that doesn't ...

On my desktop, Vorbis is 480x realtime while Opus is 240x realtime decoding. Both using C code at -O2. It's possible it'd be too slow, but nobody else has measured it yet

That's extremely surprising, because nowhere in the docs does it say that. I assumed even when using DMA it would block. I would argue it's the job of the SDK to be safe here, doing the blocking internally, or at the very least documenting it with heavy warnings.

I don't have access to hw right now ...

I checked Vorbis' RAM usage, and while Tremor has a low-RAM branch, it's still too much for an unaided Genesis. Though I see someone used it with a 32x.

Opus being the latest craze, I have an interesting quote:
The amount of RAM that Opus requires depends on several factors:
1) Whether you're ...

My original ROM does not use DMA at all after loading all tiles at startup, so I don't think DMA is the issue.

Okay, I have a redistributable test ROM that shows the issue here:
https://github.com/clbr/gentest/raw/master/game.bin.xz

Sources are in the same repo:
https://github.com/clbr/gentest

I ...