If you do that, you'll probably end up putting so much processing power on the interface card between the Super NES and the CD-ROM drive that it can almost emulate the Super NES. The original PlayStation was born in exactly this way.MottZilla wrote:Well then all you need is to make a SNES CD addon that streams the data off the CD.
video roms
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
A friend of mine was saying that it may be possible to interface the SNES with a CDROM without anything fancy and that if you could hook it up to B-Bus you could DMA from the CDROM's buffer into A-Bus very quickly. Ofcourse neither of us are electrical engineers.
Or do you mean that it would require something with alot of processing power to stream data to the SNES for the application of video playback?
Or do you mean that it would require something with alot of processing power to stream data to the SNES for the application of video playback?
Both CompactFlash and CD-ROM drives are parallel ATA devices. PowerPak would need only a few changes to read ROMs from CDs:
- support for ATAPI variant of ATA wire protocol
- support for ISO 9660 file system
- 12 V and 5 V power for the drive motor
cool, didn't expect this much discussion for this forum.
@byuu: Mode 3 would've been way easier to implement than what I showed in the TMNT demo, I just didn't like the savage ROM requirements since I wanted something to show that I could present with the resources currently available. The 256MB S-DD1 ROM idea sounds so out there, but it'd actually be pretty fun to mess around with. I'd definitely use it, and even though the audio doesn't take up as much space it'd help out there too. I assume you could just extend the mmc[] array in your S-DD1 code to not have the &3? I don't know what else you'd have to do to get a 256MB ROM loaded...
About the PAL vs NTSC issue, I really don't want to make anything tied to one format. Just personal preference, I mean if I buy another console to replace my busted one it'd definitely be an NTSC one, I never want to target PAL for homebrew, but I don't want to eliminate chances of compatibility with both. 240x176 in NTSC sounds good to me actually. It would be good for 20FPS anyway, but I might have to shave off a line or two to fit the palette upload, no big deal.
@tokumaru: I don't think this video (ones from myself anyway) have practical purpose in any games outside of novelty. Wouldn't it feel wierd having an 8MB ROM with a small intro video, and 300kb of actual game content? I say 300kb as en example because that's how much is vacant in the TMNT video. I don't think much can be done without special chips to make it fit practically in any game, even then it's a major stretch.
------
Speaking of the audio end of it, I would've liked to make all of this powered by just the spc + '816, no fantasy hardware or anything complicated added to it. I wanted to make something that if you were to give a snes oodles of ROM and a simple bank switching setup, nothing more than that, it'd work no problem. I want the original hardware to do most of the heavy lifting.
I currently use 22khz mono, I don't think 32khz stereo software driven is far from reach, the SPC routine I have already spends a decent amount of time waiting for the next 2 samples bytes (1 byte for control, 1 byte for audio which I don't need at all).
So there are roughly 64 spc cyles between scanlines over on the snes end, I only transfer every 2 lines. The SPC routine looks like this:
it's very generic and the bbs0 could be removed just by having another routine that operates without that check. It's not pressed for time or anything though so I left it as is. It works every 2 scanlines for 2 bytes.
If I were to make something resembling this:
Not tested or used or anything. Over 3 scanlines, it will accept 8 bytes of data. 8 bytes so I only need to test for Y crossing page boundary at the end of all of this.
224 / 3 * 8 = 592 bytes a frame after rounding, which is 8 (or 2.6) short of the 600 I need for 64000 samples a sec. Don't really care, I'll make it JUST a tad lower in rate and you won't tell the difference. Ofcourse there is overscan but meh.
My current 22khz mono code takes 10-11 scanlines per frame, trippling gives 33 which is still plenty of time for any videos to run. With the cycle counting and everything I'll probably destroy and shreds of compatibility this ever had with zsnes/snes9x but I don't care. I'll be debugging this with simulatneous spc+cpu trace logs in bsnes anyway.
I don't modify volume in the new routine I just posted, I can just assume max volume until the end where the snes just starts feeding it silence.
------
also byuu since you sound interested with videos and all of that, have you made any of these before? This must all be small potatoes to you so I assume you've done it many times over.
Also, I don't feel like touching anything related to the S-DD1 compression because I feel it'd be really challenging trying to make a compressor for something that obscure. It would help massively though...Regardless, a 128mbit powerpak with potential MMC support would be my ideal target cartridge, except I don't own one or a NTSC SNES, or a SNES that actually functions.
edit: I realise there's tons of issues with the spc code I posted although I don't want anyone to go out of their way to fix something I already covered, disregard the horrors in that snippet.
@byuu: Mode 3 would've been way easier to implement than what I showed in the TMNT demo, I just didn't like the savage ROM requirements since I wanted something to show that I could present with the resources currently available. The 256MB S-DD1 ROM idea sounds so out there, but it'd actually be pretty fun to mess around with. I'd definitely use it, and even though the audio doesn't take up as much space it'd help out there too. I assume you could just extend the mmc[] array in your S-DD1 code to not have the &3? I don't know what else you'd have to do to get a 256MB ROM loaded...
About the PAL vs NTSC issue, I really don't want to make anything tied to one format. Just personal preference, I mean if I buy another console to replace my busted one it'd definitely be an NTSC one, I never want to target PAL for homebrew, but I don't want to eliminate chances of compatibility with both. 240x176 in NTSC sounds good to me actually. It would be good for 20FPS anyway, but I might have to shave off a line or two to fit the palette upload, no big deal.
@tokumaru: I don't think this video (ones from myself anyway) have practical purpose in any games outside of novelty. Wouldn't it feel wierd having an 8MB ROM with a small intro video, and 300kb of actual game content? I say 300kb as en example because that's how much is vacant in the TMNT video. I don't think much can be done without special chips to make it fit practically in any game, even then it's a major stretch.
------
Speaking of the audio end of it, I would've liked to make all of this powered by just the spc + '816, no fantasy hardware or anything complicated added to it. I wanted to make something that if you were to give a snes oodles of ROM and a simple bank switching setup, nothing more than that, it'd work no problem. I want the original hardware to do most of the heavy lifting.
I currently use 22khz mono, I don't think 32khz stereo software driven is far from reach, the SPC routine I have already spends a decent amount of time waiting for the next 2 samples bytes (1 byte for control, 1 byte for audio which I don't need at all).
So there are roughly 64 spc cyles between scanlines over on the snes end, I only transfer every 2 lines. The SPC routine looks like this:
Code: Select all
MainLoopX:
cmp x,$f6 ;wait for matching index
bne MainLoopX
inc x ;protocol count++
mov a,$f4 ;get data byte #1
mov ($00)+y,a ;store to ARAM at appropriate spot
incw $00 ;increment entire 16bit pointer
mov a,$f5 ;get data byte #2
mov ($00)+y,a
incw $00
bbs0 $03,skip ;playback started? skip if so
mov a, $00 ;after 256 bytes uploaded, key on
bne skip
mov $03,#$01 ;set bit 0 of playback started flag, then key on ONE TIME ONLY
mov $f2,#$4c ;KON CH0
mov $f3,#$01
skip:
;cmp $00,#$00 ;once next byte pointed to is $C000, then the last address written was $BFFF
;bne UpdateVolume ;unecessary due to high byte changing immediately upon reaching the end
cmp $01,#$C0
bne UpdateVolume
mov a,$BFF7 ;read header byte of final block
or a,#$03 ;set loop/end
mov $BFF7,a
mov $00,#$00 ;reset pointer back to $3000 for another bunch of blocks
mov $01,#$30
jmp MainLoopX
UpdateVolume: ;help balance the load between cases
mov $f2,#$0c ;update mvoll
mov a,$f7
mov $f3,a
mov $f2,#$1c ;mvolr
mov $f3,a
jmp MainLoopXIf I were to make something resembling this:
Code: Select all
;$F7 is for sync (A only) sometimes and the rest are for data
;$00 and $02 point to two samples that are 9 * 8 * 256 bytes large ($4800 each)
;assuming $6000 and $A800
;(3 bytes)
ScanlineA:
cmp x,$f7 ;wait for matching index
bne MainLoopX
inc x
mov a,$f4 ;data byte #1
mov ($00)+y,a
inc y ;saves 4 cycles over incw $00, no page boundary cross checking required as long as it's incremented by power of two between checks
mov a,$f5 ;data byte #2
mov ($02)+y,a
inc y
mov a,$f6 ;data byte #3
mov ($00)+y,a
inc y ;43 cycles passed since the CMP loop
;need to stall for time a little bit so may aswell throw this check in here
bbs0 $04,wait ;playback not yet started?
bbc0 $01,wait ;256 bytes have already been buffered?
mov $f2,#$4c ;KON CH0/CH1
mov $f3,#$03
mov $04,#$01 ;only do this once
jmp ScanlineB ;71 cycles elapsed including this jump
wait:
push a ;waste 20 cycles before allowing further stuff (68 altogether, including 5 cycle branch taken bbs0)
pop a
push a
pop a
push a
pop a
nop
;(4 bytes)
ScanlineB:
mov a,$f4 ;data byte #4
mov ($02)+y,a
inc y
mov a,$f5 ;data byte #5
mov ($00)+y,a
inc y
mov a,$f6 ;data byte #6
mov ($02)+y,a
inc y
mov a,$f7 ;data byte #7
mov ($00)+y,a
inc y ;48 cycles for this block
;*insert meaningful activity here*
push a ;18 cycles + 48 = 66
pop a
push a
pop a
nop
;scanline C (1 byte):
ScanlineC:
mov a,$f4 ;data byte #8, $f7 now contains the next control byte for next iteration
mov ($02)+y,a
inc y
bne ScanlineA ;no page crossing means just loop again
inc $01 ;advance page pointers and check if the end is reached
inc $03
cmp $01,#$A8 ;once high byte of first sample points to the start of the second, it has reached the end (for both)
bne ScanlineA
mov a,$A7F7 ;final header first sample..
or a,#$03
mov $A7F7,a
mov a,$EFF7 ;likewise second sample
or a,#$03
mov a,$EFF7
jmp ScanlineA ;52 cycles after this block224 / 3 * 8 = 592 bytes a frame after rounding, which is 8 (or 2.6) short of the 600 I need for 64000 samples a sec. Don't really care, I'll make it JUST a tad lower in rate and you won't tell the difference. Ofcourse there is overscan but meh.
My current 22khz mono code takes 10-11 scanlines per frame, trippling gives 33 which is still plenty of time for any videos to run. With the cycle counting and everything I'll probably destroy and shreds of compatibility this ever had with zsnes/snes9x but I don't care. I'll be debugging this with simulatneous spc+cpu trace logs in bsnes anyway.
I don't modify volume in the new routine I just posted, I can just assume max volume until the end where the snes just starts feeding it silence.
------
also byuu since you sound interested with videos and all of that, have you made any of these before? This must all be small potatoes to you so I assume you've done it many times over.
Also, I don't feel like touching anything related to the S-DD1 compression because I feel it'd be really challenging trying to make a compressor for something that obscure. It would help massively though...Regardless, a 128mbit powerpak with potential MMC support would be my ideal target cartridge, except I don't own one or a NTSC SNES, or a SNES that actually functions.
edit: I realise there's tons of issues with the spc code I posted although I don't want anyone to go out of their way to fix something I already covered, disregard the horrors in that snippet.
splitting this up because I don't want to add to an already huge post.
new rom to demonstrate the 32khz stereo idea. Got the cycle counts right, also destroyed snes9x compatibility, awesome. thank god for bsnes or I'd have nothing to test my screwy roms on. Unfortunately, it needs S-DD1 again. The interleaved brr file with both tracks is like 7.6MB, so I still don't have something I can just slap into a powerpak and play on the real deal. If I could like hear/see a snes playing this that'd be sweet but it looks like that's not happening for some time.
Random stuff:
-needed to make the uploader use fixed point for uploads per frame, the DSP pointer and SPC pointer kept colliding without.
-overscan was the difference between 31750hz and 32000hz, since I'm not playing video, why not?
-the code which handles this is unoptimized, but it won't be much trouble getting it going alot faster.
Just happy to have 32khz stereo streams running smoothly through software entirely. For 1989 it's a great combination of chips. It's not CD-quality byuu but I still like what I hear. Also sorry about the song of choice, it's the only CD quality source material I have around at the moment.
new rom to demonstrate the 32khz stereo idea. Got the cycle counts right, also destroyed snes9x compatibility, awesome. thank god for bsnes or I'd have nothing to test my screwy roms on. Unfortunately, it needs S-DD1 again. The interleaved brr file with both tracks is like 7.6MB, so I still don't have something I can just slap into a powerpak and play on the real deal. If I could like hear/see a snes playing this that'd be sweet but it looks like that's not happening for some time.
Random stuff:
-needed to make the uploader use fixed point for uploads per frame, the DSP pointer and SPC pointer kept colliding without.
-overscan was the difference between 31750hz and 32000hz, since I'm not playing video, why not?
-the code which handles this is unoptimized, but it won't be much trouble getting it going alot faster.
Just happy to have 32khz stereo streams running smoothly through software entirely. For 1989 it's a great combination of chips. It's not CD-quality byuu but I still like what I hear. Also sorry about the song of choice, it's the only CD quality source material I have around at the moment.
Yes, exactly. When I have a WIP ready, I'll message you on my forum about it.I assume you could just extend the mmc[] array in your S-DD1 code to not have the &3?
Would probably be tomorrow afternoon or so.
Maybe. Let's see. Need 42,240. 86*1324*3/8=42,699.240x176 in NTSC sounds good to me actually. It would be good for 20FPS anyway, but I might have to shave off a line or two to fit the palette upload, no big deal.
You're cutting it way too close, as you still need to transfer audio data and set up all the DMAs and such. Go for 240x160@20Hz NTSC.
Need 38,400. 102*1324*3/8=50,643.
Also, you don't need to transfer a palette if you use RGB332. But if it looks better with a custom 256-color palette, then that works I suppose. Maybe try 240x144?
No, I've never had a good, lossless, decompressed video feed necessary to make it happen. I just knew it was possible was all.also byuu since you sound interested with videos and all of that, have you made any of these before? This must all be small potatoes to you so I assume you've done it many times over.
Andreas Naive already made one. I believe RHDN cached it, too.Also, I don't feel like touching anything related to the S-DD1 compression because I feel it'd be really challenging trying to make a compressor for something that obscure. It would help massively though...
It works great. I used it when I was trying to figure out why a bug in DF's Star Ocean allowed it to work in ZSNES but not other emulators. Turned out to be a bug in ZSNES and a misunderstanding of how the chip worked that allowed it to work on real hardware. Fun.
Anyway, it's pretty easy. neviksti also has compressors for the SPC7110.
Yes, it's exceptionally good quality. I'm amazed the SNES can sound that good, actually. The problem is that you have no time left for displaying video now ;)For 1989 it's a great combination of chips. It's not CD-quality byuu but I still like what I hear.
---
If I could make a request for the 256MB video, do you think you could try the Lunar: Silver Star Story opening? :D
http://www.rpgamer.com/games/lunar/lsss/lsssmov.html
(Japanese version, please. Higher quality and no caption-overs)
(need IV41 - Intel Indeo Video 4.1 codec for that particular file)
(lower quality: http://www.youtube.com/watch?v=OahHMRT4n3c)
If not, no big deal. But I would love to show off a ROM like that to others :D
I had no clue about the pre-existing compressor, I grabbed mingw and it worked great. I compressed a random ASCII file and tried the following:
works great, having the chip moitor reads to $43x0 makes it real inuitive to implement. I assume after the few cycles the push/pop burns it's ready to stream, however much you want.
It looks like it starts preparing decopressed data depending on what it internally has in its 43x2-43x4 mirror after a write to $4801, I guess if I reserve one channel and set the address ONCE at reset, then I could do DMA for constant sized blocks of data, and the chip would automatically advance its own internal pointer depending on the variable sized compressed data. But then I wouldn't know when to switch banks because I can't see the address it stores, unless I missed something in your source. Seems I have to set the source address manually when crossing banks but that's cool.
I still have to remake the batch converter thing I have here to output mode3 stuff, but the plan as of now is something like:
-modify andreas' compressor to take command line arguments, no problem
-have my converter program detect where the compressed stream crosses a 1MB bank and then store these values to some table in ROM. The frame counter would be compared to the next bank cross frame # coming up and once there's a crossing, $4806 and $4807 source values in RAM get incremented. Would also store an offset into the new bank based on the compressed piece of data that crossed over. Like if the final piece of bank data 'overflowed' the current 1MB bank by $60 bytes (last byte read was $F0:005F), it'll access from $E0:0060 from the next frame. $The E0 and F0 banks in my ROMs are where the swtiching occurs.
-make the 32khz streamer less shit in performance department.
i'm still using overscan but I'd shut off the screen just as early as I would without.
---
Also, I couldn't get the high quality video opening here a tall, I download Iv5play.exe or whatever it was that installs Indeo Video 4,5 and whatever else. No luck in media player or virtual dub, irfan view is the only thing here the plays it, although it refuses to extract bitmaps because 'it can't find the video data' despite the fact it has no problems playing it?
Unless I could get that high quality one into a workable format (for myself, I don't know why it won't play even with codecs installed). I will use the youtube one since I had no problem working with that.
edit: forgot to post, youtube audio since SPC end doesn't stand to change at the moment: here, while I don't care for any of that its still better listening than the other demo for sure
Code: Select all
PHP
REP #$10
SEP #$20
LDX #$F000 ;last chunk of ram
STX $2181
LDA #$01
STA $2183
LDA #$01 ;enable the chip itself
STA $4800
LDA #$08 ;one reg no inc
STA $4300
LDA #$80 ;$2180
STA $4301
LDX.w #testfile
STX $4302
LDA.b #testfile>>16
STA $4304
LDX #$0100
STX $4305
LDA #$01 ;CH0
STA $4801
PHA ;same timewaster star ocean uses
PLA
STA $420B
STZ $4800
PLP
RTSIt looks like it starts preparing decopressed data depending on what it internally has in its 43x2-43x4 mirror after a write to $4801, I guess if I reserve one channel and set the address ONCE at reset, then I could do DMA for constant sized blocks of data, and the chip would automatically advance its own internal pointer depending on the variable sized compressed data. But then I wouldn't know when to switch banks because I can't see the address it stores, unless I missed something in your source. Seems I have to set the source address manually when crossing banks but that's cool.
I still have to remake the batch converter thing I have here to output mode3 stuff, but the plan as of now is something like:
-modify andreas' compressor to take command line arguments, no problem
-have my converter program detect where the compressed stream crosses a 1MB bank and then store these values to some table in ROM. The frame counter would be compared to the next bank cross frame # coming up and once there's a crossing, $4806 and $4807 source values in RAM get incremented. Would also store an offset into the new bank based on the compressed piece of data that crossed over. Like if the final piece of bank data 'overflowed' the current 1MB bank by $60 bytes (last byte read was $F0:005F), it'll access from $E0:0060 from the next frame. $The E0 and F0 banks in my ROMs are where the swtiching occurs.
-make the 32khz streamer less shit in performance department.
i'm still using overscan but I'd shut off the screen just as early as I would without.
---
Also, I couldn't get the high quality video opening here a tall, I download Iv5play.exe or whatever it was that installs Indeo Video 4,5 and whatever else. No luck in media player or virtual dub, irfan view is the only thing here the plays it, although it refuses to extract bitmaps because 'it can't find the video data' despite the fact it has no problems playing it?
Unless I could get that high quality one into a workable format (for myself, I don't know why it won't play even with codecs installed). I will use the youtube one since I had no problem working with that.
edit: forgot to post, youtube audio since SPC end doesn't stand to change at the moment: here, while I don't care for any of that its still better listening than the other demo for sure
Aw, well hopefully ffmpeg works. Would be a shame to store the video in a lossless format after Youtube mangled it :(
As a last resort, http://www.rpgdreamers.com/rpgmovie/lunar.wmv
That's the English version and it has some overlay bullshit from their website, plus the ear bleeding US vocals. But since we have the JP vocals, with a little video clipping on the first few frames it could potentially work. Subtitles are probably better than Youtube quality ...
And yeah, crossing a bank boundary is fine for the S-DD1, but obviously you have to have the right banks mapped in via 4804-4807.
Anyway, thanks a million for making the Lunar version for me. Going to be absolutely amazing to finally show off what the SNES is really capable of :D
Going out to get dinner now, when I get back in a few hours I'll start on the 256MB S-DD1 mode. Need to get rewind up and working too, so tomorrow morning at the latest. I'll make it public so everyone here can try it out.
As a last resort, http://www.rpgdreamers.com/rpgmovie/lunar.wmv
That's the English version and it has some overlay bullshit from their website, plus the ear bleeding US vocals. But since we have the JP vocals, with a little video clipping on the first few frames it could potentially work. Subtitles are probably better than Youtube quality ...
And yeah, crossing a bank boundary is fine for the S-DD1, but obviously you have to have the right banks mapped in via 4804-4807.
Anyway, thanks a million for making the Lunar version for me. Going to be absolutely amazing to finally show off what the SNES is really capable of :D
Going out to get dinner now, when I get back in a few hours I'll start on the 256MB S-DD1 mode. Need to get rewind up and working too, so tomorrow morning at the latest. I'll make it public so everyone here can try it out.
Okay, this is public so that NESdev people can try it out. Please don't go seeding it everywhere. Get it now if you want it, though. May be gone after the next WIP is out.
You need the Qt DLLs from the official release, and it also lacks profiling, so it's about 15% slower than official releases.
But it allows up to 256MB for S-DD1 games, and 257MB for SPC7110 games (the MMC doesn't index the 1MB program ROM chip.)
http://byuu.org/temp/bsnes_v057_wip02.tar.bz2
Also, mplayer seems to want ir41_32.dll for IV41 playback, and FFmpeg can supposedly go through avisynth if needed.
You need the Qt DLLs from the official release, and it also lacks profiling, so it's about 15% slower than official releases.
But it allows up to 256MB for S-DD1 games, and 257MB for SPC7110 games (the MMC doesn't index the 1MB program ROM chip.)
http://byuu.org/temp/bsnes_v057_wip02.tar.bz2
Also, mplayer seems to want ir41_32.dll for IV41 playback, and FFmpeg can supposedly go through avisynth if needed.
The IV41 bullshit is resolved, though I had to use an old XP machine to get irfanview to do a BMP extraction. VLC crashed, although I know where to go if I need more IV41 vids dumped. The mov is 15FPS though, you sure you want that? I didn't realise it sucked that bad until I saw I needed to throttle playback (at only 20hz too) before it timed correctly against a youtube playing in parallel. The youtube has more FPS although it probably has worse artefacts or whatever.
The garbage on the sides I'll kill with windowing or something, the odd rows of pixels on the bottom must just be me getting the scroll wrong / shutting off screen too late. That pic is from the mov, no "floyd steinberg" dither when chopped down to 256 PNG files and converted. If you can suggest a conversion setting to make it look better than great. The 64MB ROM works fine with the bsnes you posted. Not using compression yet because I don't even have the base player working 100%, have to do overlapping transfers and two tilemaps to fit a 38KB screen pair in there, or atleast that's the approach I'm going for at the moment.
The garbage on the sides I'll kill with windowing or something, the odd rows of pixels on the bottom must just be me getting the scroll wrong / shutting off screen too late. That pic is from the mov, no "floyd steinberg" dither when chopped down to 256 PNG files and converted. If you can suggest a conversion setting to make it look better than great. The 64MB ROM works fine with the bsnes you posted. Not using compression yet because I don't even have the base player working 100%, have to do overlapping transfers and two tilemaps to fit a 38KB screen pair in there, or atleast that's the approach I'm going for at the moment.
Oh wow, the screenshot looks even better than I imagined!
Really, it's only 15fps? Damn. I'll leave it to you then, does it look better at 15fps HQ or 20fps LQ? Or maybe the WMV is a little better? :(
I even have the Sega Saturn MPEG version of Lunar, but I have no idea how to extract the movie from it. Need to find someone with the PSX version, there's 82 billion movie extractors for that system.
Really, it's only 15fps? Damn. I'll leave it to you then, does it look better at 15fps HQ or 20fps LQ? Or maybe the WMV is a little better? :(
I even have the Sega Saturn MPEG version of Lunar, but I have no idea how to extract the movie from it. Need to find someone with the PSX version, there's 82 billion movie extractors for that system.
Why do you need to send any tilemaps? Just set it to a linear 0-599 range once at poweron, and then transfer the video like that each frame. Leave the tilemap at $f000+, and tiledata at $000-efff. Or is your code optimizing out repeating tiles?have to do overlapping transfers and two tilemaps
Hahah, awesome. The world is either going to love us or hate us for this :DThe 64MB ROM works fine with the bsnes you posted.
I just wanted to comment that Saturn and PSX videos usually didn't have much quality to begin with.
Most Saturn videos I've seen had very little color resolution and were very mean to gradients, in addition to being very wiggly. PSX videos usually have severe JPG artifacts, and pretty bad color resolution too. And most of the videos from either system ran at 15 fps.
I know that the SNES has it's own limitations, but when they are combined with pre-existing issues the final result suffers. Look at the yellow collar the guy in the screenshot has. When it meets the sky you can see some very bad blocking. The original codec has poor color resolution, and this becomes apparent when it tries to represent two opposing colors (blue and yellow) next to each other. Red is another color that usually suffers because of this (look at how the red in his chest bleeds).
Based on this, I believe that whatever result you achieve from this particular video will be sub optimum. Unless there is a better source for it than the actual game it's from. I've seen Saturn and PSX videos re-released in better quality as extras in PS2 games and things like that.
Most Saturn videos I've seen had very little color resolution and were very mean to gradients, in addition to being very wiggly. PSX videos usually have severe JPG artifacts, and pretty bad color resolution too. And most of the videos from either system ran at 15 fps.
I know that the SNES has it's own limitations, but when they are combined with pre-existing issues the final result suffers. Look at the yellow collar the guy in the screenshot has. When it meets the sky you can see some very bad blocking. The original codec has poor color resolution, and this becomes apparent when it tries to represent two opposing colors (blue and yellow) next to each other. Red is another color that usually suffers because of this (look at how the red in his chest bleeds).
Based on this, I believe that whatever result you achieve from this particular video will be sub optimum. Unless there is a better source for it than the actual game it's from. I've seen Saturn and PSX videos re-released in better quality as extras in PS2 games and things like that.
Hmm actually, let's go with this one, then:
http://fmv.thehylia.com/lunar-silver-star-story
12.6MB in DivX format, it's supposedly a direct rip from the PSX version. The JP audio should sync over it just fine. If it ends up being 15fps, I guess that's okay. More time for the audio and such, and a smaller resultant file size. I think this video looks just fine when played back on my PC.
And yes, unfortunately using any lossy video source is going to give sub-optimal results. 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.
Thanks again for making this, I really really appreciate it :D
http://fmv.thehylia.com/lunar-silver-star-story
12.6MB in DivX format, it's supposedly a direct rip from the PSX version. The JP audio should sync over it just fine. If it ends up being 15fps, I guess that's okay. More time for the audio and such, and a smaller resultant file size. I think this video looks just fine when played back on my PC.
And yes, unfortunately using any lossy video source is going to give sub-optimal results. 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.
Thanks again for making this, I really really appreciate it :D
