Posts for creaothceann


creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
got4n wrote:
passion.
^^
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
marzojr wrote:
The signal used to generate the center image in the NES, SMD, SNES and H32 Genesis is around 5.37 MHz signal; if you do the math, this means about* 341 "pixels" per scanline; of these, 288 "pixels" are in the active region (the rest are for horizontal retrace of the electron beams, and are in overscan). Thus, anything that generates a signal with that frequency will have to generate 341 "pixels" of signal, 288 of which compose the active image. Since a NES image is 256 pixels wide, it needs to generate a border to fill the image region (this is required because of the frequency of the generated signal); so the NES, too, has horizontal borders.
I don't really understand how the signal encoding works, but afaik a console can have faster or slower pixel clocks. So even if we know that it outputs 256 pixels per line, they may be a bit compressed or stretched compared to "regular" pixels - and theoretically this area may be placed anywhere depending on when the console starts outputting the pixels.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Samsara wrote:
condescending narcissist
???
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Well, once the extra area has been added the picture can be stretched to 4:3, and the emulator output part of that picture will automatically become more 16:9-like.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Warp wrote:
So the SMS stretched the 256x192 screen image into a non-4:3 aspect ratio (even though TV was 4:3)? So it did like a 4:3 -> 16:9 aspect ratio stretch (leaving the upper and lower borders of the TV empty)?
Basically, yes. (see e.g. the Afterburner example) But think the other way around - you still have the standard NTSC screen with a 4:3 area (after cutting off part of the tube) and whose height can be divided into 483 scan lines.[1][2] The electron beam sweeps along these lines over the screen and whatever is in the input signal (blankness, the SMS's backdrop color, actual pixels, ...) ends up being spread out there. Progressive mode reduces the line count from 483 to 482 and draws only every other one, leaving 241 filled lines and 241 black scanlines between them. Out of the 241 filled lines, only 192 contain pixels; the rest is the backdrop color. It still gets a bit more complicated since apparently the SMS begins changing its active drawing color later than usual and stops earlier, leaving some space to the left and to the right also filled with the background color. So you get a stretched surface that is only partially filled out. Getting the aspect ratio of that resulting picture doesn't sound simple to me, certainly it's more complicated than a simple "4:3 -> 16:9 aspect ratio stretch". [1] That last odd line isn't used by consoles in progressive mode and probably has very minimal impact on aspect ratio calculations. [2] The time between full pictures can also be measured in scanlines; that's where the 525 comes from. EDIT: ninja'd
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Virtual Machine, for example DOSBox or VirtualBox.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
256x192 being 4:3 only applies if you assume square pixels. In the days of DOS and ModeX this might have been acceptable (especially if most games use only 192 lines), but it doesn't make any effort to represent what you see with a real system (simplified) where the signal is stretched onto a curved surface with the only requirement that the cut off image should look about 4:3. Remember, resolution does not equal size and therefore all aspect ratio calculations based on resolution are incorrect.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Note that the previous code was the development version for testing specific values; it can be simplified to this:
function SMS_TV_Screen(clip c)  {
        c
        Assert(Width==256 && Height==192 && IsRGB32, "SMS_TV_Screen: invalid input clip")
        PointResize(256, 384).AddBorders(0, 48, 0, 48).BilinearResize(640, 480)
}
Or without black borders:
function SMS_TV_Screen(clip c)  {
        c
        Assert(Width==256 && Height==192 && IsRGB32, "SMS_TV_Screen: invalid input clip")
        PointResize(256, 384).BilinearResize(640, 384)
}
For a slightly sharper image, replace the 256 in the PointResize call with 512. (And/or replace the BilinearResize with Spline64Resize or another resizer.)
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Here's an Avisynth script that converts the raw emulator output to a TV screen (using idealized parameters). The size goes from 256×192 to 640×480.
Language: Avisynth

f1 = "Ghostbusters.png" f2 = "Lord of the Sword.png" f3 = "Sonic 1.png" f4 = "Sonic Chaos.png" ImageReader(f1, 0, 0) +\ ImageReader(f2, 0, 0) +\ ImageReader(f3, 0, 0) +\ ImageReader(f4, 0, 0) ConvertToRGB32 v1 = last .Crop(1, 1, -1, -1).AddBorders(1, 1, 1, 1, $FF0000) v2 = SMS_TV_Screen.Crop(1, 1, -1, -1).AddBorders(1, 1, 1, 1, $00FF00) StackHorizontal(v1.AddBorders(0, 0, 0, v2.Height - v1.Height), v2) function SMS_TV_Screen(clip c) { TV_LineCount = 525 - 1 TV_OverscanTop = 22 TV_OverscanBottom = 22 TV_PixelsPerLine = round((TV_LineCount - TV_OverscanTop - TV_OverscanBottom) * 4 / 3) Console_LineCount = 192 * 2 Console_PixelsPerLine = 256 Console_StartingLine = (TV_LineCount - Console_LineCount) / 2 Console_Bitmap = c.ConvertToRGB32.PointResize(c.Width, c.Height * 2) BlankClip(length=c.FrameCount, width=Console_PixelsPerLine, height=TV_LineCount) Layer(last, Console_Bitmap, y=Console_StartingLine) Crop(0, TV_OverscanTop, -0, -TV_OverscanBottom) BilinearResize(TV_PixelsPerLine, Height) }
http://i.imgur.com/SL1GXL5.gif
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
For YT there's this, though I never tried it myself.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
If there are video files* that are encoded in the emulator's raw 1:1 aspect ratio, it's as easy as dropping that file into MKVMerge GUI and specifying the aspect ratio in the video stream's settings. The video player (e.g. MPCH) will then stretch the picture during playback. So even if the 256x192 ratio is wrong, it's not the end of the world. *not WMV, because WMV sucks.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
According to the standard, an old NTSC color TV has 60/1.001 fields (half-frames) per second consisting of 525 scanlines, of which 483 are visible. (The odd number is for shifting the odd fields down one scanline. Consoles usually don't output that last scanline so there are ~60 frames per second and black scanlines between the visible lines.) The image is drawn by three electron guns sweeping horizontally over the screen which has a very fine dot mask, so while there's a discrete number of lines there's no fixed number of pixels per line. It only depends on how fast the input source can change the color and how much the colors bleed together because of the NTSC signal encoding and the electron beam expanding/shrinking depending on its brightness. This is why the picture is still relatively sharp when it's stretched to its 4:3 aspect ratio while on a PC we have to use something like bilinear interpolation. So the exact ratio could be measured by drawing 192*2 lines on a black screen of 482 lines, stretching that to 4:3, and cutting off the blank lines since they're usually not displayed in an emulator.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
For some reason there are 1,179,648 lines containing the text "BoardName MBC5 ROM+RAM+BATTERY". If you delete all but one of them it might work. (Use Notepad2 or Notepad++, not Windows' notepad.exe!)
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Awesome! :D
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
...did you record a video?
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
IIRC I wrote that part because after subtracting 8 you'd end up with negative numbers. If you're subtracting from 15 instead it might already be correct. Just try it with a few values from the game.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Just leave some folders with these links open on a second monitor. ;)
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
You could try asking these guys.
Post subject: Re: Problems encoding (S)NES movies with Wine
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Mvf314 wrote:
the only thing that works
https://www.virtualbox.org/
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Btw. audio was slower than the video in the encoding.
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
Why is this topic even in SNES Games?
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
creaothceann
He/Him
Editor, Experienced Forum User
Joined: 4/7/2005
Posts: 1874
Location: Germany
You can use e.g. Avisynth for that, but it'd be better to find out why this happens in the first place.