[H] lolicatgirls.nes
Moderator: Moderators
[H] lolicatgirls.nes
Last edited by Dwedit on Tue Aug 05, 2008 11:52 am, edited 1 time in total.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
-
atari2600a
- Posts: 324
- Joined: Fri Jun 29, 2007 10:25 pm
- Location: Earth, Milkyway Galaxy, The Universe, M-Theory
- Contact:
sadly haven't put an emulator on this rig yet, do you has screenshots? 
Code: Select all
*=$0000
loop JMP loop
.eof
Last edited by Dwedit on Tue Aug 05, 2008 11:53 am, edited 1 time in total.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Awesome. 
All we need now is a new mapper that is capable of bankswitching a few hundred MB worth of data, both PRG and CHR. Toss in some code to play PCM data, and you could watch movies (or at least short cartoons) on the NES!
All we need now is a new mapper that is capable of bankswitching a few hundred MB worth of data, both PRG and CHR. Toss in some code to play PCM data, and you could watch movies (or at least short cartoons) on the NES!
- BMF
RuSteD LOgIc
RuSteD LOgIc
If we want to make FMV's on the NES a reality, what we really need is CHR-RAM and a good codec that takes into account temporal and spacial redundancy, for which a decoder can be efficiently programmed for the 6502 so that a video frame can be decompressed in no more than 4 or 5 hardware frames.
The problem is that with just 8KB of CHR-RAM it would not be posible to fill the whole screen (although a wide-screen image wouldn't look so bad). It would also be impossible to double buffer the tiles of the new frame as they are decompressed.
I while ago I was thinking about a codec that allowed a maximum number of tiles to be updated every frame, probaly tiles that weren't used by the current video frame. A codec like this would be heavily based on spacial redundancy, because the same video frame would use a very limited number of tiles.
Well, I'm not sure what kind of compression would work better. This has always been one of my plans, to code a compressor/decompressor for NES videos, so that small cutscenes that fit in regular carts could be used during games. I always give up though, because I can't think of a way that would actually work (and look acceptable).
The problem is that with just 8KB of CHR-RAM it would not be posible to fill the whole screen (although a wide-screen image wouldn't look so bad). It would also be impossible to double buffer the tiles of the new frame as they are decompressed.
I while ago I was thinking about a codec that allowed a maximum number of tiles to be updated every frame, probaly tiles that weren't used by the current video frame. A codec like this would be heavily based on spacial redundancy, because the same video frame would use a very limited number of tiles.
Well, I'm not sure what kind of compression would work better. This has always been one of my plans, to code a compressor/decompressor for NES videos, so that small cutscenes that fit in regular carts could be used during games. I always give up though, because I can't think of a way that would actually work (and look acceptable).
If you really want compression for NES video, just use something LZ based, with a maximum window size of the previously displayed frame. Depending on the stream format used, LZ can be can be just as fast as memcpy, depending on memory access times.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
CHR RAM writing and especially reading through PPUADDR/PPUDATA are slow. If we use a special mapper to make CHR RAM pseudo-dual-ported, we might as well implement compression in hardware too.Dwedit wrote:Depending on the stream format used, LZ can be can be just as fast as memcpy, depending on memory access times.
"LZ" is just too generic for video... Some combination of block-based schemes should be used. Also, I don't think you need constant access to CHR RAM, as most of the work could be done in WRAM. If the video is displayed as "widescreen" the borders would provide some decent time for copying the data to CHR RAM and name tables once it's ready. A common cart can be used for that.
Dwedit:
A while ago I made a NES/Fami song called "Kittens n' Shit, I Guess."
http://2a03.free.fr/?p=pub&dir=B00daW
If you were to open the FTM and drop the speed down to '2', I think it would be fitting; especially since there is no DPCM.
Just File, and then Create NSF.
You won't hurt my feelings if you don't use it.
*THUMBS UP* on the mania.
Update:
Please include JARGON BANNED in celebration to your lolicats demo.
A while ago I made a NES/Fami song called "Kittens n' Shit, I Guess."
http://2a03.free.fr/?p=pub&dir=B00daW
If you were to open the FTM and drop the speed down to '2', I think it would be fitting; especially since there is no DPCM.
Just File, and then Create NSF.
You won't hurt my feelings if you don't use it.
*THUMBS UP* on the mania.
Update:
Please include JARGON BANNED in celebration to your lolicats demo.