It is currently Sat Dec 16, 2017 11:53 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: NMI vs IRQ
PostPosted: Sat Oct 15, 2016 11:34 am 
Offline

Joined: Sat Aug 06, 2016 10:22 pm
Posts: 15
Hey qwertymodo, I don't know enough to help with the technical stuff, but I did find this. A user named Ladida made an example MSU-1 Video over at SMWCentral. The ASM is included in the download and might be able to help you out. https://www.smwcentral.net/?p=viewthread&t=73363 Maybe you could use this process instead of making your own player.
Quote:
in case youre wondering how its done (or how I did it):
1. grab relevant video file
2. open in handbrake or something, pick relevant time segment from video (or just whole vid)
3. export as 256x144 (16:9, crop/letterbox if you have to), @ constant 30fps (or 15fps, or 7.5fps, etc)
30fps gives you ~1 hour of video (if you use all 4GB of MSU)
15fps gives you ~2 hours
7.5fps gives you ~3 hours? or 4? i cant into math, sorry
4. virtualdub doesnt like mp4/mkv, so convert to avi
(you could have done steps 1-3 in virtualdub btw)
5. in virtualdub, export image sequence (PNG)
i guess you dont really need virtualdub for this, just something that will export
the processed video as a sequence of PNGs
6. batch convert the PNGs in irfanview to PCX, downsampled to 8bpp
7. batch process the PCXs through pcx2snes using the bat i provided as a sample
8. sticky the files together; have the gfx and pal separate
as in, combine all the gfx into one, and then all the pal into one, and then
stick the pal to the exact end of the gfx. take note of the address
9. you pretty much have your .msu, just use it.

you dont exactly have to follow the steps above. whats important is that you end up with
x9000 byte gfx files and x200 byte palette files for each frame, and it should look good
when animated at a constant rate (either 30fps, 15fps, 7.5fps, 3.75fps, 1.875fps...)

audio is much easier, everyone and their pet goat knows how to do it:
1. extract audio from video file
2. convert audio to 44.1khz 16bit wav
3. open in audacity, cut out audio you dont want (make sure it matches video)
skip this step if the extracted audio already matches the video you processed
4. export as wav, then just run through wav2msu


you can copy and use my source code if you want. it should work with anything you throw at it;
just replace the audio file(s) and the .msu file


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Sat Oct 15, 2016 12:06 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
Thanks, I'll take a look at that, but I'm still planning on writing my own, since I haven't worked with the PPU before, and I'll need to understand it in order to complete the hack (since the videos will interrupt the gameplay and I'll need to restore the video state afterward). Also, understanding how it works makes the reverse engineering of the existing code that much easier. I basically have mine functionally displaying, I'm just having timing issues which it sounds like should be workable with forced blanking (or at least that should get me most of the way there and if I have to shrink the frame, I can do that too, but smkdan's player managed to do it). So, that's the plan.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Mon Oct 17, 2016 2:59 am 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 42
qwertymodo wrote:
Then, can anybody help me understand where these numbers are coming from? I need to transfer ~33K over the course of 4 frames (15fps@60Hz), or else I need to drastically reduce my frame size.


I think the problem is you haven't bandwith to do that. You only have 22,8 KB every 4 frames.

But decreasing the resolution to 192 horizontal scanlines yo have 10,88KB per frame, and i don't know why with 256x160 or 256x144 you don't have enough bandwith.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Mon Oct 17, 2016 11:45 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
qwertymodo wrote:
The source video is letterboxed to 256x144 (or maybe 160, I don't remember), so I'll look into the use of forced blanking. Not really sure how to do that though. This whole video thing is new for me.

If you're only transferring ~9 KB per frame, and your visible area is 160 lines high and centered vertically, you can probably get away with just setting the top bit of $2100 at the beginning of NMI, and resetting it at the end, as long as all the tiles above and below the video frame are black. Normal VBlank plus the extra 32 lines at the top of the screen should give you something like 11 KB, with a sufficiently lean and efficient NMI routine.

If you needed more bandwidth, you could use an IRQ set to trigger at the bottom of the video playback window, and disable NMI entirely. This would get you roughly 16 KB per frame.

You say the original video is 15 fps?

...

You're not using HDMA for anything during video playback, are you?

Señor Ventura wrote:
You only have 22,8 KB every 4 frames.

But decreasing the resolution to 192 horizontal scanlines yo have 10,88KB per frame

How are you calculating those numbers? DMA is 165.5 bytes per line. Are you assuming a particular amount of code overhead?


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Mon Oct 17, 2016 12:57 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19350
Location: NE Indiana, USA (NTSC)
22800 bytes/4 frames * 1 line/165.5 bytes = 34.5 out of 38 lines. I'm not sure how much time the S-PPU spends in "pre-render" seeking out sprites for the first line though.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Mon Oct 17, 2016 1:57 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
Since the video is letterboxed, I was able to force blank from scanline 184-40 which gave me enough time to upload the frame in 4 chunks. Now I just have a bunch of counter logic code to write and I'll have myself a video player.

Image


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Mon Oct 17, 2016 3:10 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
That's only 142 lines of video. I assume it's supposed to be 144...

Also, I don't know if you're doing this, but it's probably wise to avoid using HDMA, because it can interact badly with regular DMA on early S-CPUs. I'm not sure if the bug happens on a 'dry fire' (HDMA active but no data for that particular scanline), but the fact that it can happen at the beginning of line 0 suggests that it might, and I wouldn't risk it. You can start HDMA partway through a frame, but it's a bit fiddly and I believe there's a one-line delay.

Then again, if you're starting the main DMA right below the video, it's probably finished well before the top of the screen...


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Mon Oct 17, 2016 5:21 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
I'm not using HDMA. Good call on the line numbers, I probably want to blank 185-39 (I'm using a tilemap with fully black tiles in the letterboxed area, so there won't be any garbage if I blank late/enable early, it just cuts down on the bandwidth a bit). Anyway... it's working (the audio is a bit out of sync because it's muxed in separately, I don't feel like coding up an SPC ROM and upload routine just to disable the DSP mute register, especially since this is going to be a ROM hack anyway, and the original game will handle that for me).

https://www.youtube.com/watch?v=SO0zOXvgk64


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Tue Oct 18, 2016 12:16 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
Thanks for all the help, I've managed to get all 10 FMV's playing now :)

https://www.youtube.com/watch?v=kJ7CT6bFPlw


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Tue Oct 18, 2016 3:16 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
Good job!

I find Color quantizer works better than the GIMP in many cases. It certainly has more options (particularly in the old version 0.6.5.0)... Don't be afraid to fiddle with "Max error"; I find that small patches of colour can come out horribly wrong if it's too small...

Unfortunately I don't see a way to quantize in a 15-bit colourspace. If you use a custom palette, it doesn't seem to pay any attention to the "Number of colors" box... I've tried using a custom palette to quantize to 15-bit with dither, and then re-dithering to 256 colours afterwards, but the first step takes forever for some reason (then again, my computer has been acting strangely of late, so your mileage may vary)...

What's the colour depth of the original video? The above paragraph is only relevant if it's higher than 15-bit...


Some quick test results (image credit: tepples):

GIMP 2.8.10 - reduce to 256 colours with positioned dither, then posterize to 32 levels.
Attachment:
Wii_kids_GIMPpositional256_RGB15.gif
Wii_kids_GIMPpositional256_RGB15.gif [ 43.44 KiB | Viewed 1092 times ]


Color quantizer v0.6.5.0 - Adaptive, 256 colours, frame size 2048, max error 15, ordered dither, all other settings default. Load in GIMP and posterize to 32 levels. Generally much smoother, but notice the bit depth issues in the dark areas...
Attachment:
Wii_kids_CQordered256e15_RGB15.gif
Wii_kids_CQordered256e15_RGB15.gif [ 41.6 KiB | Viewed 1077 times ]


Color quantizer v0.6.5.0 - custom RGB555 palette, 8x8 pattern dither (by far the most computationally intensive kind of dither; this step took nearly 3 minutes), tweaked max error and frame size but can't remember settings. Save and load modified image. Adaptive, 256 colours, frame size 4096, max error 14, ordered dither, all other settings default. Finally load in GIMP and posterize to 32 levels.
Attachment:
Wii_kids_CQpatternRGB15_ordered256e14.gif
Wii_kids_CQpatternRGB15_ordered256e14.gif [ 45.28 KiB | Viewed 1084 times ]


Has anyone else got any recommendations for a good colour quantization and dither solution?

If you'd rather roll your own, that's not a bad thing and I'm not going to stop you...

...

I don't know what you're using to target SNES format, but note that pcx2snes has a chroma dither feature that screws with hue in an attempt to preserve luminosity, and it is implemented in such a way as to mess up the palette of an image that has already been posterized to approximate 15-bit colour. I find the results can be rather ugly. I prefer to use my own code to convert images to SNES format, because I know it won't pull any weird shenanigans...


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Tue Oct 18, 2016 10:00 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
I wrote my own png to bitplane converter in C++. So, if I implement any of the custom dithering algorithms, like one of these, I'll do it in there. I might also put the resizing in there as well to avoid that extra step as well. For now, I'll give color quantizer a shot. At the very least, I need to give the positional algorithms a try, since error-diffusion algorithms don't play nice with animation.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Tue Oct 18, 2016 11:33 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
qwertymodo wrote:
custom dithering algorithms, like one of these

Hey, those look really good. For 16 colours, anyway... Plainly you're way ahead of me on this.

Quote:
resizing

...wait, I thought you said the source video was 256x144...

Quote:
error-diffusion algorithms don't play nice with animation.

Ah. Good point.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Wed Oct 19, 2016 7:30 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
93143 wrote:
...wait, I thought you said the source video was 256x144...

The original source is 320x176, letterboxed to 320x240. The final output is running at 256x144, letterboxed to 256x224


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Wed Oct 19, 2016 11:39 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
I see.

Not to be too much of a back seat driver or anything, but why not 256x152? According to my calculations it would still fit fairly comfortably if you left as much data as possible to the last frame, and the aspect ratio would be slightly less wrong.

Based on the page you linked above on the subject of dither algorithms, I'm going to assume you plan to use a high-quality rescaling algorithm too... man, I really have trouble trusting people to do their hobbies right, don't I?


Last edited by 93143 on Wed Oct 19, 2016 11:46 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Wed Oct 19, 2016 11:43 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
265x152 wouldn't be the right aspect ratio. The correct ratio is actually 256x141.8, so I'm just calling it 142 and adding 1 black line on top and bottom.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group