Search found 338 matches
- Sat Dec 19, 2015 2:10 pm
- Forum: SGDK
- Topic: zlib status
- Replies: 10
- Views: 6092
Re: zlib status
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 ...
- Sat Dec 19, 2015 11:38 am
- Forum: SGDK
- Topic: zlib status
- Replies: 10
- Views: 6092
zlib status
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 usage...
- Sat Dec 19, 2015 9:54 am
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
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?
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?
- Fri Dec 18, 2015 6:05 pm
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
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.
If it was made an inline function, that'd be just one or two instructions.
- Fri Dec 18, 2015 4:34 pm
- Forum: SGDK
- Topic: Theorical question about the planes
- Replies: 12
- Views: 7230
Re: Theorical question about the planes
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.
- Fri Dec 18, 2015 4:33 pm
- Forum: SGDK
- Topic: Gen compressed audio, Opus
- Replies: 5
- Views: 3621
Re: Gen compressed audio, Opus
-O3: 27s, 0.015x realtime. Dropping it here, may Google preserve this to all eternity.
- Fri Dec 18, 2015 3:54 pm
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
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 wheth...
- Fri Dec 18, 2015 2:07 pm
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
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.
Also, this really needs to be documented. Every dangerous function needs to have big warnings.
- Fri Dec 18, 2015 2:03 pm
- Forum: SGDK
- Topic: Gen compressed audio, Opus
- Replies: 5
- Views: 3621
Re: Gen compressed audio, Opus
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 wor...
- Fri Dec 18, 2015 9:48 am
- Forum: SGDK
- Topic: Gen compressed audio, Opus
- Replies: 5
- Views: 3621
Re: Gen compressed audio, Opus
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
- Fri Dec 18, 2015 9:43 am
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
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,...
- Thu Dec 17, 2015 7:31 pm
- Forum: SGDK
- Topic: Gen compressed audio, Opus
- Replies: 5
- Views: 3621
Gen compressed audio, Opus
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 encodi...
- Thu Dec 17, 2015 6:12 pm
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
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'd a...
- Thu Dec 17, 2015 4:18 pm
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
It's not a flashcart, but a programmed chip. Other big roms work.
I'll try to make a small test ROM I can share.
I'll try to make a small test ROM I can share.
- Thu Dec 17, 2015 1:34 pm
- Forum: SGDK
- Topic: Video problems on hw
- Replies: 20
- Views: 13123
Re: Video problems on hw
SGDK does it for me, in boot/sega.s.