nesdev.org

Where can this patch be found now? The CD audio for Der Langrisser. And is it for MSU-1 or the old 21fx?

MottZilla wrote:Where can this patch be found now? The CD audio for Der Langrisser. And is it for MSU-1 or the old 21fx?

@MottZilla, maybe that patch was never released? Care to contribute to the subject of this thread in any way?

Ramsis wrote:

Khaz wrote:The FMV audio only seems to work in higan though, not on the SD2SNES...

Please try renaming ct_msu1.pcm to ct_msu1-0.pcm -- I still haven't been able to test it on my sd2snes myself, but I'm pretty sure the filename's the issue here.

Sorry it took me so long to respond - it does indeed work if I change the filename. Thank you for restoring this demo!

Okay, I've done some more work on this, and finally got it to stream data directly into VRAM/CGRAM (no more WRAM buffering). Yay.

Oddly enough, the original hack doesn't even bother to use the active display time window to build the buffer; instead, it fills the buffer on every even frame and copies its content to VRAM/CGRAM on every odd frame, effectively cutting the framerate (at least) in half ... which is probably why I thought I was getting sea-sick upon watching the FMV the first time.

Before another release, I'll do my best to remedy these deficiencies, which of course implies the video will need to be reconverted.

This new version will be awaited with great interest

Ramsis wrote:Oddly enough, the original hack doesn't even bother to use the active display time window to build the buffer; instead, it fills the buffer on every even frame and copies its content to VRAM/CGRAM on every odd frame, effectively cutting the framerate (at least) in half ... which is probably why I thought I was getting sea-sick upon watching the FMV the first time.

Huh! So, you mean it goes like this?

Frame 1: Load Frame 1 to WRAM
Frame 2: Transfer WRAM to VRAM
Frame 3: Load Frame 3...

So... That video is actually playing in 30FPS, and you're saying it could be 60FPS? That doesn't seem possible to me at that size. Unless you meant it's skipping every other video frame, but the original video is 30FPS so it's actually playing at 15...

I'm curious to know a bit more about how these Video-Directly-To-SNES demos work. I know very (very) little about video encoding, but it seems to me like decoding the picture in real time would be prohibitively processor-intensive unless it's already pre-formatted for SNES. Does it generate a new palette for every frame, or use a static one for the whole video? Does it translate the image pixel by pixel? Or is it sort of a streaming thing where it only updates pixels that have changed from the last frame?

I'm just curious to have a better understanding of how to compare this video-decoding method to my frame-pre-processing method.

Khaz wrote:So... That video is actually playing in 30FPS, and you're saying it could be 60FPS? That doesn't seem possible to me at that size. Unless you meant it's skipping every other video frame, but the original video is 30FPS so it's actually playing at 15...

The original video (converted with an ancient tool from STR to AVI) is indeed 30 fps, but as I discovered just today, the odd and even frames are exactly the same -- so ultimately, it's only 15 fps. At least, that explains its choppiness.

Khaz wrote:I'm just curious to have a better understanding of how to compare this video-decoding method to my frame-pre-processing method.

I bet it's the same. For example, both ikari's video player and smkdan's implementation simply require a series of Tile data + palettes as the .msu data file; tilemaps are fixed and thus only written once at all.

EDIT: Okay, 2347 frames ready to be converted to SNES format. I've scaled them down to SNES aspect ratio, and cropped them to get rid of the black borders. Each frame is now 256×168 pixels, i.e. the video is intended to look just like it does in the PSX version (nothing removed, no vertical borders added).

There's a catch though: I don't see how this can be achieved in 8 bpp (Mode 3) as the amount of tile data per frame exceeds 32K (i.e., no "page" switching). The only way to do it seems to be via Khaz' Quantomatic (which is already doing its job even as I type), which allows 120 colors per frame instead of 256. We'll see if this is enough to do justice to CT's cutscenes. Personally, I prefer a bigger movie "window" on the screen. What do you guys think?

Any reason not to do both for the intro to compare? Other than being more work.

I'm assuming you're saying 120 colors full screen, or 256 colors and a reduced screen area? It would be nice to compare the result.

Like I said, you could probably do a compromise with a 4bpp layer using 6 palettes and a translucent 2bpp using all the palettes for it over the 4bpp layer. If I'm not mistaken, this could get you 2161 (the 1 being the color 0) colors onscreen total, but you'd have to make a really crazy tool for this, and it would probably take 100x the amount of time to process each frame...

You know, you could make a really awesome splash screen if you had a 4bpp layer using all the palettes and another 4bpp translucent (color addition than halving) layer also using all the palettes over it. You'd do [15x8] x [15x8] - 225 (because the same colors over each other don't look any different, and 15x15=225) + 1 (color 0) and then you'd get 14,176 colors. Wow.

For that last one, you might need to rent something like this.

http://upload.wikimedia.org/wikipedia/c ... mputer.jpg

Ramsis wrote:The only way to do it seems to be via Khaz' Quantomatic (which is already doing its job even as I type), which allows 120 colors per frame instead of 256. We'll see if this is enough to do justice to CT's cutscenes. Personally, I prefer a bigger movie "window" on the screen. What do you guys think?

Good luck! I don't know if it will be a problem for the Chrono Trigger video, but the last version of my program I posted to Github still fails when you have no 8x8 tiles with a full palette of colours, like a frame that's one solid colour for example. I've fixed that (and it'll run faster in those cases too), and I just posted the new version now...

I love a good fullscreen video personally. If the original version was letterboxed and you're going for authenticity then that's fine, but I say go as big as you can without cutting anything out or hurting the overall quality.

Espozo wrote:Like I said, you could probably do a compromise with a 4bpp layer using 6 palettes and a translucent 2bpp using all the palettes for it over the 4bpp layer. If I'm not mistaken, this could get you 2161 (the 1 being the color 0) colors onscreen total, but you'd have to make a really crazy tool for this, and it would probably take 100x the amount of time to process each frame...

You know, you could make a really awesome splash screen if you had a 4bpp layer using all the palettes and another 4bpp translucent (color addition than halving) layer also using all the palettes over it. You'd do [15x8] x [15x8] - 225 (because the same colors over each other don't look any different, and 15x15=225) + 1 (color 0) and then you'd get 14,176 colors. Wow.

For that last one, you might need to rent something like this.

http://upload.wikimedia.org/wikipedia/c ... mputer.jpg

Dammit you've got me thinking now. I've never tried doing anything with translucency before but my understanding is it's just bascially averaging the two colours, right? The first paragraph there actually sounds doable. Say you use my program to quantize the image down to 6 palettes. Then, you have another program to scan through and calculate the errors on each pixel. At the most minimal case, you collect a list of the 14 worst colours found and assign them a correction colour in one of the two 2bpp palettes. If you have a tile that needs two different correction palettes just pick the one with more pixels to correct. I don't feel like doing math right now but that miiight get you a slight improvement on just quantizing a straight 8 palettes.

Alternately, you could take a more balanced approach, give each 2bpp palette a couple of tiny corrections (like say 1R,0G,0B and 0R, 1G, 0B), do a quick scan to see which palette will correct the most pixels and assign it, to hopefully give more of a softer effect across the whole image.

The second paragraph is a more fascinating idea. When you're talking 14k colours available at once, that's almost a quarter of the SNES's total colour library. At that point you don't even really need to CALCULATE the optimal arrangement for each frame. You could just find some algorithm that gives you a good spread of colours and use that megapalette for everything. And if you want to get really intense, find some progression of palettes where you can get say four sets of 14k colours, and shift between them depending on which is best for each frame.

HOWEVER though you have a theoretical limit of 14k colours, you can't exactly have them all on screen at once because again you have to weight each tile to see which combination of palettes will come the closest. Trying to think about how badly that impairs the concept hurts my head right now.

I have to give you credit for daring to consider the idea.


EDIT: Oh yeah. If anyone else is doing video with the Quantomatic and you don't have a way to convert the .inc files into a .msu, I have another quick excel file that does that. I should give my python program the option to export raw binary files as well, to make that easier.

Khaz wrote:HOWEVER though you have a theoretical limit of 14k colours, you can't exactly have them all on screen at once because again you have to weight each tile to see which combination of palettes will come the closest. Trying to think about how badly that impairs the concept hurts my head right now.

What? The hardest part seems to be that both layers use the same 8 palettes. I actually think I did my equation wrong, but I'm having the hardest time figuring things out. I think I fried my brain on this...

Would it be [15x8] x [15x7] + 1 = 12,601? Wait, wouldn't you actually multiply the second 15 by 8 and not 7 because we never calculated actually calculated the color by itself? Then it would be 14401, which is slightly more than I originally thought.

Similarly, I forgot the colors on the 6bpp one could be by themselves, so [15x6] x 24 + [15x6] + 24 + 1 = 2274.

Espozo wrote:What? The hardest part seems to be that both layers use the same 8 palettes. I actually think I did my equation wrong, but I'm having the hardest time figuring things out. I think I fried my brain on this...

Would it be [15x8] x [15x7] + 1 = 12,601?

As far as I can tell, if all colours are unique, it's [15x8] x ([15x8] - 1) = 14280. ASSUMING you have a selection of colours where no two combinations create the same result, which sounds absurdly hard to arrange.

The problem though is in rendering the image in those colours. Say you have one tile where one pixel here needs palettes 1 and 2 for its colour, but another pixel needs palettes 3 and 4. So, you have to balance which combination of palettes satisfies the most pixels in that tile and go with that, which will probably make the pixels it DOESN'T cater to look downright awful. I think your idea might look awesome for a gradual smooth gradient of colour or something, but when you get a lot of different colours inside the same tile it probably breaks down unless, like you said, you have one hell of a computer program to work out the best compromise...

Khaz wrote:like you said, you have one hell of a computer program to work out the best compromise...

Well, it's not impossible. Just leave your computer running for 2 years. Anyway though, even if it isn't the total amount of colors, there is going to be so many colors that it might not even matter anyway.

Oh yeah, one trick I've had that I think would work (I've never actually tried it on real hardware though) would be if say the tile map 512 pixels tall, you could use HDMA to move the vertical scrolling register 4 pixels up every 4 pixels down the screen to make it to where the 512 tile map is fitting in the 224 space. The reason for this is you could have the palette be different for every 8x4 pixel area.

Espozo wrote:even if it isn't the total amount of colors, there is going to be so many colors that it might not even matter anyway.

Just based on what I've seen so far, I'm kind of wagering that it will. Just plain reducing an image to the SNES's maximum colour depth can cause visible breaks in the image that were once a smooth transition of colour. Reducing that down another quarter or more could start to look unpleasant. Choosing the palette based on content is important to getting a good result. Just try reducing an image to 256 colours in MSPaint - it uses the same stock palette every time, so even with plenty of colours to work with it looks awful.

You may be right though, I'd have to see the results to know.

No, you're not going to have the palettes be the same for the whole video, you're going use different palettes for every frame. I'm saying that even with the 8x8 attributes, it will still look really colorful.