creaothceann
He/Him
Editor
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.
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Warp wrote:
I honestly find this a bit baffling. What exactly is the problem in explaining it? I believe I asked pretty simple questions. It's not like it's rocket science or something.
The issue is that CRTs have a fixed number of lines (how many depend on the standard), but they have no defined number of columns: depending on how fast your signal is, you will generate more or less pixels per line, but a line will always have the same size (with the pixels being stretched or compressed, depending on your signal speed). An example for the sake of clarity: in the Genesis, both the H40 mode (320 pixels/line) and H32 (256 pixels/line) will result in lines of the same length in a real CRT, with the result that the latter mode will have longer, nonsquare, pixels. In the case of the SMS, this also happens (and for the NES, and so on); so leaving the image at 256x192 ("a nice 4:3" as you put it) results in incorrect aspect ratio because a real CRT will have nonsquare pixels in this case.
Marzo Junior
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
It looks like SMS indeed outputs huge horizontal and tiny vertical borders, and some devs even gave them special colors, so the overall picture was 4:3, but the real screen was 16:9-ish. See the third link by creaothceann.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
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)? I still don't understand what cropping has anything to do with this.
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
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)?
Lets start over; for simplicity, I will focus on NTSC and the SMS. A (progressive) frame in NTSC has 262 lines; if a video game generated any less, the image would roll over as time passes. Of these 262 lines, 243 are "active" lines, meaning they are (potentially) visible on-screen. The remainder of the lines do not need to be generated (but the time they take must be accounted for; they make up the vblank interval, the time during which the electron guns are re-positioned to the top left of the screen). Of these 243 active lines, the SMS uses 192 for the active game area (possibly to compensate for overscan). This means that a image with 192 lines needs 51 lines of border; the SMS generally does 27 lines at the top and the remaining 24 lines at the bottom. This is filled with the backdrop color, which may change along the way (see California Games screenshot for example). The SMS also generates 284 pixels per line, of which 256 are the (potentially) visible pixels (also due to overscan); the remainder are also border pixels, filled with backdrop color; these are distributed as 13 to the left and 15 to the right. For reference, the full NTSC line length is equivalent to 342 SMS pixels; the "missing" 58 pixels are not generated, and they represent the time taken by the electron guns to re-position for the next line (hblank interval). So the real image generated by the SMS is 284x243 in resolution. THIS is what has to be scaled to 4:3 aspect ratio (borders and all). You can then crop the borders a bit (keeping the 4:3 aspect ratio), since old CRTs did that to varying degrees (this is called overscan). Generating a 256x192 image is wrong, and scaling that to 4:3, or 16:9 or 16:10 or whatever is also wrong. And while you can scale the 256x192 image in such a way that the correct aspect ratio is achieved, you will miss out on the border color -- some games actively used this, even changing the backdrop color midway. And one last thing: this scaling is done implicitly by the CRT: the exact timings of the generated video signal determine when the CRT will draw each pixel, and for how long. The video signal generated by the SMS is such that the 284 pixels generated each line take up the whole (active) NTSC line, so the pixels get stretched horizontally. So the only way in which it can be said that the SMS is doing the stretching is by giving a "too slow" video signal per line.
Marzo Junior
creaothceann
He/Him
Editor
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
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
So, if I understand correctly, if you just wanted to show the pixel content of the game you could simply stretch the original 256x192 pixels into something wider, like 16:10 or 16:9, but if you also want to show the colored borders outside this pixel content area (which was very common with old consoles / 8-bit home computers, including in this case the SMS, and which some games even used for effects), you need to do something a bit complicated (basically make the emulator produce all the extra area around the 256x192 pixel content, and then stretch it in such a manner that the pixel content becomes 16:9 or such).
creaothceann
He/Him
Editor
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.
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
creaothceann wrote:
[1] That last odd line isn't used by consoles in progressive mode and probably has very minimal impact on aspect ratio calculations.
That last odd line is quite literally the difference between progressive and interlaced modes: if you draw 262.5 lines every frame, hblank will start in the middle of a line every other half frame; thus, every other frame will be shifted down by one line, meaning you alternate between drawing the even and odd lines. The half-lines end up in the overscan area, so they aren't visible. Progressive mode simply doesn't use that line (so it draws 262 lines every frame), so that the new image is drawn on the same lines as the previous image, replacing it instead of complementing it. So yeah, the last line is irrelevant in progressive mode.
Marzo Junior
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
tl;dr: We need SMS emulator video output fixed, to add those borders.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
feos wrote:
tl;dr: We need SMS emulator video output fixed, to add those borders.
Strictly speaking, the same would be true for NES, SNES, Genesis, and so on; they are all technically wrong if they don't generate the borders, then have the image stretched to 4:3. It is just worse for the SMS because it uses less lines for the game than the others.
Marzo Junior
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Does eg. the NES really have any borders? If I understand correctly, the pixel data is extended to the entirety of the TV screen, even at the cost of the outermost pixels going out of the screen.
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
TD;DR: Yes, the NES has borders; the above discussion talked about SMS too much, but what it says is common to ALL consoles intended for CRTs. And an image is not stretched to fit a CRT except horizontally. The long version: I will try to explain this in a different way that will hopefully make it clear why. I will again focus on NTSC; NTSC, PAL and SECAM differ in details (such as number of lines, or number of frames per second), but their workings are the same. I will not make the mistake of focusing on any given console, TV, video recorder or anything else to avoid confusing the issue even more. NTSC has 525 lines; no more, no less. These are split into two 262.5-line fields (or 262-line fields, for progressive display, as in consoles) which are drawn alternatively to the even rows and odd rows (progressive display uses the same set of rows always). The field rate is 60 Hz for black & white, or 60/1.001 for color signals (due to the added requirement in terms of bandwidth, as well as for backwards compatibility with older TVs). For interlaced display, this means one 525-line image per frame at 30/1.001 Hz, for progressive display this is a 262-line image per "frame" at 60/1.001 Hz. I will ignore interlaced displays from now on because they are generally irrelevant for consoles (but Sonic 2 2p mode says hi). Of the 262 lines in progressive display in NTSC, 243 make up the active display; the rest are used for vertical retrace of the electron beams. Thus your video must output 243 lines per field, and 19 lines' worth for the vertical blanking. If it outputs any less, the video will roll over. Thus, ANY console, VCR, or whatever that outputs NTSC signals needs to output 262 lines worth of video, of which 243 need to have actual image data (again, progressive display). Borders count as needing image data, as different CRTs have different overscan sizes; so the NES, too, has vertical borders. Now comes the lines, also known as scanlines. First off, there is a fundamental difference between CRTs (for which NTSC, PAL and SECAM were developed for originally) and modern displays (LCDs, plasma, etc): while CRTs have a discrete number of scanlines, a scanline in a CRT is controlled by an analog signal. This means that it technically has infinite resolution, if you can manage to generate a signal fast enough; but in truth, the signal will most likely wash out the details if it is too fast, and may not even work with most older TVs and cables. Put in other words, a "pixel" is whatever width your analog video signal makes it. This is usually incorrectly referred to "stretching" or "extending" the image. 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. As I mentioned above, overscan varies by TVs, and even as the set ages; this applies for scanlines too. The blanking part is always in overscan; but part of the active image data is likely to also be on overscan. Consoles used a "safe" region of the active image that comprised about either 80% or 90% in vertical and horizontal ranges. This changed over time as TVs were better manufactured and more powerful consoles were made. * Result depends on really high precision numbers and some rounding, so results may vary depending on which numbers you use Edit: And for what is worth, I am taking a class on digital processing of sound and video that covers a lot of stuff.
Marzo Junior
creaothceann
He/Him
Editor
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.
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
creaothceann wrote:
I don't really understand how the signal encoding works, but afaik a console can have faster or slower pixel clocks.
Indeed, the difference between H40 and H32 modes in the Genesis is the VDP's clock — it is slower in H32 mode, using the same frequency as the SMS and the NES.
creaothceann wrote:
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.
These consoles don't output 256 pixels per line — they output 288 pixels per line, of which 256 are the game image. In a TV with little or no overscan, the 288-pixel active image would be stretched across the TV set. But because real TVs have overscan, part of this is hidden; this led TV broadcasters and console devs used less of the active image for content to make sure everything important was visible (this happened with lines too). The game image is ideally as centered as possible in the active image to make sure it isn't clipped to the left or to the right (or top and bottom).
Marzo Junior
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Hi guys, we need to know how does the TV display low-res games from the Genesis. Does anyone have a certain answer? http://tasvideos.org/forum/viewtopic.php?p=394642#394642
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 10/5/2014
Posts: 31
It depends on TV and if you run the console in PAL or NTSC mode. Here is how it looks on a CRT: (large picture warning) http://notaz.gp2x.de/img/mess/megadrive/mr_nutz_ntsc.jpg http://notaz.gp2x.de/img/mess/megadrive/mr_nutz_pal.jpg
Skilled player (1431)
Joined: 11/26/2011
Posts: 655
Location: RU
Thank you very much! Hopefully now we will have encode with correct aspect ratio. Here smaller pic for PAL mode:
I show you how deep the rabbit hole goes. Current projects: NES: Tetris "fastest 999999" (improvement, with r57shell) Genesis: Adventures of Batman & Robin (with Truncated); Pocahontas; Comix Zone (improvement); Mickey Mania (improvement); RoboCop versus The Terminator (improvement); Gargoyles (with feos)
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
feos wrote:
Hi guys, we need to know how does the TV display low-res games from the Genesis. Does anyone have a certain answer? http://tasvideos.org/forum/viewtopic.php?p=394642#394642
Some accurate numbers from SpritesMind based on oscilloscope measurements: - H40 mode: image is 347 pixels wide (13 + 320 + 14) - H32 mode: image is 283 pixels wide (13 + 256 + 14) - V28 mode, NTSC: image is 243 lines tall (11+224+8) - V28 mode, PAL: image is 294 lines tall (38+224+32) - V30 mode: image is 294 lines tall (30+240+24) V30 mode is PAL-only, and causes the image to roll over progressively if set on NTSC. These numbers are for the raw image data generated by the VDP, including borders; the signal has more data, but it is synchronization signals. "Normal" mode in Genesis is H40 V28; low res mode is H32 V28. The best way to handle the image in low res mode would be to stretch the 283 pixels of H32 into 347 pixels while leaving vertical size intact. In both cases, then cut a 4:3 region. So the correct horizontal scaling factor would be 347/283 ~ 1.22614841. Since the 27 border pixels also get stretched, this means that the "center" 256 pixels get stretched to just shy of 314 pixels (313.893992933 to be accurate); stretching it to 314 pixels gives a scale factor of 1.2265625, which is close enough, I suppose. Edit: Source.
Marzo Junior
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Then it appears the old as my granny guideline about unchecking "Proper Aspect Ratio for LowRes" (when the game uses lowres most of the time) is completely failed?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
The guide has its value in that it allows preservation of raw pixel data as would be generated by the VDP (the Genesis VDP is a modified version of the SMS one, by the way) before it is fed to DACs to generate the video signal for the TV. But yeah, following the guide results in videos that have the wrong aspect ratio for any console that expects a TV at the other end.
Marzo Junior
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
Well, it's not totally broken: we can dump unstretched pixels to avi and then apply SAR via x264, making the player fix the aspect ratio. I don't think it will be worse than stretching them in gens (to 320x224, which is not 4:3) and then stretching them again to 4:3.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
feos wrote:
and then apply SAR via x264
Using mkvmerge GUI is nicer imo, one doesn't need a calculator and it applies the setting only to the container :)
marzojr
He/Him
Experienced player (742)
Joined: 9/29/2008
Posts: 964
Location: 🇫🇷 France
Reading a bit of Exodus's source (specifically, this), I now have some more information regarding H32 and H40 in the Genesis. Specifically, the active display portion takes exactly the same time in both of the modes. This corresponds to the 256 (H32) or 320 (H40) pixels rendered in emulators being drawn. This means that, at least on a Genesis, you can get a perfect aspect ratio for H32 mode by simply stretching horizontally from 256 to 320 pixels.
Marzo Junior
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
You missed the opening bracket.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.