video roms

[tepples]

The only benefit is that the S-DD1 can most likely take advantage of some of the artifact crushing to compress better. But if we really want to show off, we need a lossless source video. Or maybe second best, with a Blu-ray anime/cartoon opening or something.

Or just take some random YouTube Poop video of Adventures of Sonic the Hedgehog. YouTube's HQ mode uses H.264 codec, which has much less noticeable artifacts than the Cinepak/MJPEG codecs of the CD-ROM based consoles.

Another idea: Instead of using 256-color tiles, encode each frame with eight different 15-color palettes. See Quither to learn what's possible.

[smkd]

I worded the thing about tilemaps badly, I do send them at reset and not at any other time. $F600+ is where they sit and yscroll gets alternated.

haha I'd put artefacted anime videos way above any youtube poop =). I think DKC series used the 16 palettes and 4bpp tiles to get its very colourful overworld images drawn, it looked pretty decent. If there was any pressure to cut down on ROM size it'd be alot more appealing.

I have a video ROM here but it has some issues:
-I still haven't made the audio code less shit, although there's no pressure in terms of frame time
-no compression, I just wanted to get something working before involving all of that. It won't be hard to add it into the current source.
-it uses the frames from the mov, not the divx you just posted there. You want the video to have the entire intro from the divx, with the JP audio delayed until it syncs with the JP vid? I mean, should there be silence for the first few moments?

Matthew if you don't want me putting these on your server just say so, I don't mind uploading big videos even with the horrors of *Australian Internet* but I don't know about you.

7zip 'ultra' compression got the video down to 43MB, I wonder how the S-DD1 will measure up to that.

[Near]

Wooooooooooooow!! Looking absolutely amazing so far!! :O
You're absolutely amazing, thank you so much.

-I still haven't made the audio code less shit, although there's no pressure in terms of frame time

Sounds really good so far to me at least :)
But yeah, may as well show off the full power of the system since we have plenty of extra time at these frame rates.

-it uses the frames from the mov, not the divx you just posted there. You want the video to have the entire intro from the divx, with the JP audio delayed until it syncs with the JP vid? I mean, should there be silence for the first few moments?

Yes, that should be fine. The 15fps actually does look a little choppy, so hopefully 20fps will be a marked improvement, but we'll see :D

Matthew if you don't want me putting these on your server just say so, I don't mind uploading big videos even with the horrors of *Australian Internet* but I don't know about you.

Indeed, I'd love to link to this on my site if at all possible, but I know Derrick would have a coronary when he saw the bandwidth logs >_<

7zip 'ultra' compression got the video down to 43MB, I wonder how the S-DD1 will measure up to that.

Given the way compression works, I'm sure the SFC file will be smaller, but once compressed with 7-zip, that file will likely be even bigger. S-DD1 is nowhere near as good as 7-zip, even though it's optimized for tiledata. Once it's applied, 7-zip won't be able to find patterns anymore.

I still think it's worth using. Smaller ROMs load in emulators faster, and it looks more impressive from a technical standpoint. Either way though, it looks like we have plenty of space left.

[tomaitheous]

Another idea: Instead of using 256-color tiles, encode each frame with eight different 15-color palettes. See Quither to learn what's possible.

You can also interlace (not to be confused with an interlaced TV output) the tilemap with HDMA to break the 15 colors per tile limit. This'll add a little overhead for uploading more palette associations for multiple tilemaps, but the trade off is worth it. You can do palette association for 8x4, or 8x2 , etc pseudo tiles. 4bit tiles are half the bandwidth for transferring to vram, half the storage space too in rom too.

Side note: I couldn't get that last rom to work in bsnes Shows about second or so of video, then shows junk onscreen.

[Near]

You need wip02, posted in this thread. It extends ROM support to 256MB.
I was able to play the entire video.

[smkd]

I'll work in the compression soon. the DivX one has much better quality, there's so much less artefacting although it stutters just the same. I made it drop frames to fit the 30hz->20hz conversion (in my batch converter not the SNES code) but it is just as fluid as the mov. It stutters in media players too, there's no smoothness, take any section with scrolling and its so apparent. Then I see the low quality youtube one posted earlier and it's so smooth. The part where they scroll through all those characters stutters pretty badly in every movie file I've seen except the youtube, but ofcourse the youtube one has extremely shit quality at the same time. What a tease haha.

edit:

But yeah, may as well show off the full power of the system since we have plenty of extra time at these frame rates.

Any suggestions on what to do? Time with the screen disabled is limited though, thanks to having to double buffer a pair of 38KB frames with less than 64KB of VRAM. If missed something just say so, was late when I actually made the thing work. There's plenty of nothing happening during the active display time, the audio code runs, the pointer setup code runs, then it does nothing for quite a while.

[Near]

Oh, this is absolutely maddening. The chance of a lifetime and I can't find a good quality version :(

I even have the Sega Saturn MPEG version but no way to rip it (SSF doesn't emulate the MPEG card, so even screen capture is out, as if I had a way to upload such a large file.)

How about this one? This is the Saturn MPEG version on Youtube as a high quality version: http://www.youtube.com/watch?v=aDOE8GUlIAA&fmt=18

And this one at least appears smooth for that one scene, but is lower quality: http://www.youtube.com/watch?v=flDD6xRbuKo

Does anyone know where to get a higher quality version of this video?

Bleh. I give up :(
Whatever works best in your opinion, I'm just happy to see it done, and I'm already floored by the previous version you posted.

I'll work in the compression soon.

By all means, no hurry here.

Any suggestions on what to do?

If you already have 32KHz stereo output, not sure. Maybe push for 30fps? :P
Bandwidth calculations tell me it's not possible though. Plus our sources for this particular video are too low framerate. It'd be a waste.

You may want to show off the power better by picking a video you like that we have in actual high quality, 60fps action. It would also be fun to utilize all 256MB, which would mean using a really long video and sending Matthew several thank you cards in the mail in advance :)

[Bregalad]

To be honnest 20FPS is ok for vids (as long as they are made with motion blur). Even 15FPS is decent (don't forget that movies were originally 18FPS). The reason anything below 50-60FPS looks choppy for games is that there is no motion blur.

[tokumaru]

15 fps will look fine if it's properly downsampled from a smoother original (which might include motion blur), something that videos from Saturn and PSX games were not.

You can see that that opening sequence was made by a professional animation studio, probably at 24 fps because that's what anime usually is. Then the software company just chopped it down to 15 fps without much care, this is why it looks choppy.

This is usually true for any Saturn/PSX game that has anime sequences at 15 fps.

[tokumaru]

How about this one? This is the Saturn MPEG version on Youtube as a high quality version: http://www.youtube.com/watch?v=aDOE8GUlIAA&fmt=18

Wow, this is much better than the previous versions. If cropped properly to be full screen (should be easy with VirtualDub) it might end up looking pretty good.

And this one at least appears smooth for that one scene, but is lower quality: http://www.youtube.com/watch?v=flDD6xRbuKo

This appears to have gone through a video filter to make it smoother (a filter that VirtualDub has), but it looks a bit overdone. If it's applied not so heavily on the video above it might make it a bit better.

EDIT: I just checked the high quality video again and it's actually 30 fps, but it doesn't look very smooth because it was poorly converted from 24 fps. This means that every 5th frame is the video is a duplicate of the 4th, and this kills all the smoothness. If someone is able (I failed very hard at getting VirtualDub to open the mp4 file) to get rid of the repeated frames they'd probably get a very smooth 24 fps video, which could be properly converted back to 30 fps.

[smkd]

Is anyone here good enough with video editing to turn one of those into something tolerable when played at 20hz?

edit: for the time being, I am using the DivX video. It definitely has alot less artefacts than the mov one and is a bit smoother. I had to use dithering in irfan view because otherwise the color banding was absolutely fucking killer, although I think it looks prettier than the 64MB one I uploaded.

I only recently modified andreas compressor to work when my batch converter invokes it. I'll feed it compressed streams whenever it crosses a 1MB bank boundary, since you said S-DD1 can read properly between 64KB boundaries right? Even 1MB boundaries? After crossing a 1MB bank of data, it'll reconfigure $4806 and $4807, setup another DMA source address, then keep doing fixed address reads from said address. Should be just fine if my knowledge of the chip is in check. Will probably get a start tomorrow.

edit2: I should've posted the divx example ROM. Out of sync audio and unecessary bits at the start, but you can atleast watch for the quality, let me know what you think. There are glitches on the sides of the borders with very bright colors in view but that's just because I wrote the wrong value to $2131 and I don't feel like uploading another 80MB ROM just for that =)

http://smkdan.eludevisibility.org/videos/vid10.7z

[Near]

If someone is able (I failed very hard at getting VirtualDub to open the mp4 file) to get rid of the repeated frames they'd probably get a very smooth 24 fps video, which could be properly converted back to 30 fps.

I'd say to use PAL at 25fps, but I know we want NTSC, so we'd probably want to do a 6:5 pulldown and output at 20fps.

And my sentiments echoed, I'd be hugely appreciative if anyone here could clean up the video for streaming smoothly. I'll be happy to commission this if it's a lot of trouble.

edit: for the time being, I am using the DivX video.

You sure? It's the JP version with the intro I only saw in the HQ Saturn MPEG rip on Youtube. Regardless, what you're using now is stunningly brilliant, and I love that it lacks the Working Designs captions.

Out of sync audio and unecessary bits at the start, but you can atleast watch for the quality, let me know what you think.

Wow, major major improvement to quality indeed. Really the only place I even notice an issue is that left-to-right panning scene. I'm honestly very happy with the file as-is. And in fact, I almost don't mind keeping that short Game Arts intro, it's kind of funny and makes it look like the actual Saturn game :D

I'd say if its no trouble to just pad empty audio onto the start of the PCM stream, or just mirror the video's audio source. Whatever's best.

This is just gorgeous, it really shows off that the SNES really can be a first-class citizen even in terms of full motion video and near-CD-quality audio. Its biggest caveat was the extremely expensive (at the time) ROM data.

Thanks to this example ROM, perhaps we can encourage one of the flash cart makers to support such a mapper; or at least get some demo coders to create enhancements like this for existing games.

[tepples]

You can do palette association for 8x4, or 8x2 , etc pseudo tiles. 4bit tiles are half the bandwidth for transferring to vram, half the storage space too in rom too.

But a single 8x8 pixel tile takes the same amount of space as a palette, so it might not be a gain to try rewriting all eight background palettes all the time.

[Near]

Here's a screen grab of the new video for those who don't want to download it+bsnes:
http://img228.imageshack.us/img228/9104/videoj.png

I'll feed it compressed streams whenever it crosses a 1MB bank boundary, since you said S-DD1 can read properly between 64KB boundaries right? Even 1MB boundaries?

It can definitely cross 64KB boundaries. To be sure, I modified the emulator to log transfers. If the real game does it, you can be confident that you can too. And it does:

Code: Select all

printf("* S-DD1: %.6x : %.4x [%u]\n", addr, buffer.size, (addr & 0xff0000) != ((addr + buffer.size) & 0xff0000));
sdd1emu.decompress(addr, buffer.size, buffer.data);

Code: Select all

* S-DD1: ffd0ab : 0824 [0]
* S-DD1: fed27f : 1800 [0]
* S-DD1: de84ac : 0300 [0]
* S-DD1: de9af5 : 0380 [0]
* S-DD1: d4f159 : 8000 [1]
* S-DD1: daf458 : 1c00 [1]
* S-DD1: dbe8ed : 0800 [0]
* S-DD1: dce0e8 : 1080 [0]
* S-DD1: ddc615 : 04e0 [0]

Just from the start, it crosses a 64KB boundary fairly quickly.

The only reason it wouldn't be able to cross a 1MB ROM boundary is if the chip internally uses a 20-bit address register. That would be rather stupid.

I can't 100% verify it since the two S-DD1 games out there don't actually transfer across a 1MB boundary. Given that you have to change banks anyway, you may as well play it safe and assume the chip can only transfer within the current 1MB mapped block.

You probably already have code to detect bank crossing that splits the DMA into two partial transfers, so it shouldn't require any changes unless you're mapping 4MB at a time and streaming to the end. In that case, modify it to only use MMC3:$f00000-$ffffff and we'll be certain the hardware was capable of that.

Now unfortunately, I strongly doubt the real S-DD1 and SPC7110 were capable of accessing more than 6/8MB for the S-DD1 and 1MB+4MB for the SPC7110. Doing so would've required more address bus pins, which would be a pointless expense just to tie them all to ground.

I don't think it violates the spirit of the chips though to simply extend their addressable range. This is very different from making up an MMC + PCM streaming device from scratch.

[tomaitheous]

You can do palette association for 8x4, or 8x2 , etc pseudo tiles. 4bit tiles are half the bandwidth for transferring to vram, half the storage space too in rom too.

But a single 8x8 pixel tile takes the same amount of space as a palette, so it might not be a gain to try rewriting all eight background palettes all the time.

I'm not sure I follow you. A single 8x8 4bit tiles takes 32bytes. A single tilemap entry takes 2 bytes. If he uses 4 tilemaps for an 8x2 pseudo tile, that an extra 6bytes on top of the normal 8x8 and tilemap, per 8x8 area. 38bytes per 8x8 < 64bytes of 8x8 8bit tile. And if I'm not mistaken, he's already updating the 256 color palette of 8bit tile mode on every frame (unless he's using direct 332 RGB mode). Wouldn't be updating 8 subpalettes be even smaller than updating an 8bit palette? (not that it's a large amount to begin with in comparison with all the tiles being updated).