Aspect ratio: the original?

RetroArch General
#74

So the idea is that it’s correct because it’s based on math using a hypothetical display that reflects no display/experience anyone ever had or has (except, I guess, broadcast monitors that haven’t knobbed the image out to 4:3)? If so, that’s the same reasoning byuu used for his obviously-not-quite-right NES palette, which is another highly contentious topic. He wanted something that was objectively irrefutable, even if it subjectively failed to match anything anyone remembers. I certainly understand this reasoning, but I think it’s specious to call it “correct.” Perhaps “idealized” would be a better descriptor.

I agree 100% about the SNES’ 16 px padding needing to be factored into 4:3 stretching, though, if you’re wanting to be a stickler. That’s how higan does it, for example.

#75

Pretty much, and that’s why I went to such lengths to put “correct” and “right” in scare quotes all over the place. I can see using “idealized” for the same reason. I think it makes more sense to look at this approach as hitting the median, rather than being what’s right. While the odds of home users experiencing their games in exactly this way are low, this should hit about the midpoint for home experience. Some sets would be calibrated slimmer and others wider, so this marks a solid compromise between the expectations of different users, which as a bonus can be backed up by the fact that it aligns with the mythical perfectly calibrated set.

For what it’s worth, Nintendo shoots for around the same values as suggested above when emulating classic games. On the Wii Virtual Console, NES and SNES games are scaled from 512 pixels wide up to 640. Wii pixels are 10:11, so the resulting PAR is 25:22 (7.95:7). The “idealized”/“median”/etc. is 8:7. That is to say, Nintendo is 0.57% off from the “idealized” value. Anything close to this area seems quite reasonable, but obviously individual preference trumps math any day.

#76

Yeah, that’s fair, I think. :slight_smile:

Having a value that’s backed by math and reasoning rather than a subjectively reached, what-I-remember-from-25-yrs-ago shot-in-the-dark definitely has value when dealing with these endlessly debated topics. At the very least, it lends people a sense of closure to an otherwise endless obsession of tweaking.

#77

Vague Rant, you are adding even more confuse and misinformation to the people saying half truths, and truths explained in half. You are the reason these threads get longer and longer and longer. You make it sound more complicated than it really is. Not care for Aspect Ratio? Really?

Classic TVs were 4:3. Does this mean that classic games consoles displayed a 4:3 picture? YES. Everything was scaled to fit your 4:3 TV, all the games regardless of their internal PAR (pixel size) were scaled to be 4:3 DAR (although this might not be correct).

What did games look like on my old TV as a kid? How can I replicate that accurately? Easy. Set up emulator to display 4:3 DAR. As Vague Rant explained, some emus output a different resolution than original console (emus occasionally remove some padding), so double check that before, and re-adapt target DAR if necessary.

So what’s the correct aspect ratio for all consoles? What do you mean by “correct”, how you played as a kid? Read above. Or geometry correct? this is another (and long) story. Every console (and even games) had a different resolution, and hence a different PAR (Pixel Aspect Ratio). Designers had to account for this PAR to make things look correct (eg. a perfect square or circle) AFTER the TV scaled content to 4:3. This means that if you saw the content as 1:1 PAR (straight from emu without resize) you should see perfect circles and squares vertically stretched. Problem is, MOST designers didn’t even care for this (and you thinking a beautifully crafted 60$ game couldn’t have such blatant fails), they drew everything in their correct look at 1:1 PAR and there be dragons in 4:3. And this is my friend why you never saw Sonic in TV as a perfect circle when jumping. So yes, geometry correct is a PER GAME thing, and not console, it depends on designers. Some designers accounted for the 4:3 stretch (F-Zero) and some didn’t (Super Mario World), yes, even within same company. Now were coin block in SMW supposed to be square? hmmmmm that’s a good question.

Bleh, this sucks. What do I do then? THAT IS what this thread IS ABOUT. Looking at a game and decide what looks (geometry) correct or not. Mind you, some designers mixed elements with different inherent PAR in the same game, so some sprites will never look good in either DAR (you will have to choose one). So this thread is not ABOUT discussing superfluous and known facts, but judging supposedly correct looks.

That’s not good enough, I’m a big asshole and I want the right answer. What is it? Right answer is “What do you think designers thought as good aspect ratio” (rather than “what do you think is good AR”). Think this way to decide what aspect ratio to use for each game. Think as a designer to evaluate your game’s DAR.

You big dumbass, how come all my old NES games fit exactly on my 4:3 if the picture’s not 4:3? Yo, mothafucka, first respect, do not insult me. Now, as I said before “scaling”, resizing, or whatever you wanna call it. All TV’s have a scaling chip embedded for this.

Anything else? I have no answers to no questions.

edit: oh, yes, and I wouldn’t base my conclusions on what Nintendo does for the VC. Yes, coin block are square with 8:7 DAR but they are the same people that still keep releasing mangled PAL games to VC, you know those that played 16% slower and more horribly things people rage so much.

#78

Meh. My scenario involves magic TVs which are tuned perfectly, your scenario involves magic TVs which are all tuned wrong but in exactly the same way. Your understanding of pixel aspect ratios is faulty. Perhaps you should have a look at something like this Commodore 64 doc (under the Aspect Ratio heading). It specifically mentions calculating PARs based on clock timing (and the necessary clock speeds for square pixels on PAL and NTSC), then also throws in that a less accurate way of making this calculation is to use the resolution and assume it fits a 4:3 area and work backward from there. It’s an OK way to operate and the results end up pretty similar, but ultimately, pixel clocks matter. They’re not there for fun, they determine how long each pixel is within a scanline.

Resolution is not the only factor in PARs, as you seem to be convinced. Hell, there are a billion arcade games that run at 256*240, but they’ve practically all got different pixel clocks, as seen on Pin Eight. To be clear, I don’t like that this is complicated, either. I think it’d be great if it was as simple as “slap it on 4:3 and that’s what every TV looks like all the time”. But it doesn’t work like that because there’s different consoles, TVs, user settings, etc. There’s not one answer, there’s as many answers as there are combinations of those three things. I’m not saying any of those answers are wrong, but none of them is right for everybody, including “it’s always 4:3” and also including “it’s whatever the pixel clock dictates”. It’s a messy issue.

Incidentally, while I wouldn’t use Nintendo as a confirmed standard either, I don’t think your reasoning is sound. Nintendo has said the reason they still release games running in letterboxed 50Hz for PAL territories is because that’s what is accurate to users’ experiences. I’m Australian; I know all about how annoying this is, but Nintendo is intent on making the games look like they did the first time around, even to the detriment of those games (in my opinion). If anything, this reaffirms Nintendo as jerky sticklers. But I still don’t think Nintendo knows best when it comes to emulation. Their NES palette is awful and doesn’t match any console or TV I’ve ever seen and they’ve even sometimes used non-integer scaling with no filtering (see Kirby’s Dream Collection). Those are great examples of Nintendo not making things look the way most people remember them, so I’d use those to justify Nintendo’s efforts being unreliable over them accurately displaying games the way they ran in markets they didn’t care about then and now.

EDIT: I suppose another question that might help to ponder is “Why do pixel clock-calculated PARs tend to result in such reasonable pictures?” Not even correct pictures, let’s just stick with “reasonable” for now. If pixel clocks are irrelevant, why bother using clock speeds which correlate fairly linearly along with the resolution, with a resulting PAR that’s in the ball park of creating a 4:3 image? The only major exception I’m aware of are the occasional arcade game with an unusually high pixel clock, where proprietors were directly instructed to calibrate their monitors using the test menu to make the picture fit. If all that mattered was resolution, a) arcade proprietors wouldn’t need to adjust anything because everything is always 4:3 and b) the clock speeds wouldn’t follow such a smooth curve, they’d just wildly fluctuate because they don’t matter.

#79

With what we have, that is pretty much what we can do (explained above). I already made some petitions that got no attention. Although this gets into a development topic.

I pretty much test with 1:1 PAR, 4:3 DAR, 7:5 for some arcades…

I say this because normally designers would pixel-draw in 1:1 par, so most likely that is the good ratio. Sometimes is not and I would default to 4:3 since RetroArch doesn’t give any more options. To judge by your clock rate link let’s take CPS3 9:11 PAR, what this means is that in order to show a perfect square perfectly square one would need to multiply the width with this ratio, so 384x224 becomes 314.18x224. This makes 1.40 DAR, so your average display TV would then resize it to 298x224 (4:3). So this is no different than directly let your old TV scale the signal (224 by (4/3) = 298x224)

But now we can do things that weren’t possible back then and truly show the desired(?) 1.40 ratio.

I made some tests. CPS3 in 4:3 1194x896 CPS3 in 1.4026:1 (9:11 PAR) 1257x896 How do you see it?

Here a proof at ideal 9:11 PAR. What I said above (mixing sprites with different PAR in mind). The circle looks fine, the in-game drawing looks horizontally stretched, the drawing would match the in-game one if this was stretched to 4:3 (1194x896).

Anyways this is pure theory, we can’t do anything until the RetroArch guys either put a meaningful DAR (based on clock rate) available to choose or let us make a real custom DAR (instead of the current custom resolution thing).

edit: btw here’s a lot of talk on clock rate and stuff if you are interested.

#80

You’re forgetting the extra 16 lines that are in the real signal. The active area on CPS3 is indeed 224 lines tall, but the full signal is 240. So using the “always 4:3” policy, the TV would "scale this to 320240" (scaling is kind of a digital process and not really the right word, but that’s largely semantics). Adding a 4 scale onto this as in your screenshots, you’d be looking at 1280960. In practice, emulators don’t show all 240 lines, so the equivalent for RetroArch purposes would be 1280896, and there’s your 4:3 display aspect ratio. Your screenshot is quite slim relative to this, which is what the game really looks like at 4:3.

Using 9:11 PAR, that would be 314240, or including the 4 scale, 1257960. Again, dropping the empty area, in RetroArch that’s 1257896, as in your image, which is dead on accurate. But when you include the cropped area (as is correct), you get a DAR of 72:55. Perhaps a more useful way to describe that is 3.93:3, which is just 1.82% slimmer than 4:3, hence why there’s only a 23 pixel difference from 4:3. And there’s the ball park.

#81

The curious note is on your “which is dead on accurate”. Did you read what I said? Circle is “accurate”, drawing is not. The reason I got it “right” is because PAR is resolution independent. It’s simply a ratio regardless of resolution.

Now that I know full signal size I redid the 4:3 one and went as far as measuring the pixels (for circle), what happens is that the 4:3 seems to be more exact than the 9:11, actually they are both very similar. The issue is that RetroArch is calculating the 4:3 of the cropped signal (bug?), which in my opinion is wrong, that’s why my initial calculations were wrong. In both the in-game drawing is wrong, that is unsettling because for the 4:3 version of the cropped signal it matched exactly with the illustration. In the end it boils down to a subjective view as I said. Problem is nobody knows what the full signal size is. You say it’s 240 for CPS3, that’s fine, for N64? for PSX? Saturn? This is not commonly exposed information, and unless RetroArch takes this into account probably everything done in the Aspect Ratio label will be wrong (with the exception of 1:1 PAR and custom). More importantly would be to know, what does RetroArch crops? At least they better fix the wrongly labeled “custom DAR” so we can input resolution independent DAR’s.

Here the updated screens: 9:11 PAR

4:3 DAR

#82

I simply meant “you accurately captured an image of the game as seen using 9:11 pixels”, in contrast to the 4:3 shot, which was originally somewhat inaccurate. I didn’t mean to imply any judgment about what looked best or seemed most in-line with developer intent. I agree that the circle is more circular in 4:3, but when we’re down to 3-pixel differences at 4* scale I guess it’s not much of a problem either way. I do agree that RetroArch adjusting aspect ratios based on cropped images is kind of weird and faulty reasoning, but I guess it’s an upstream problem, since it wasn’t RetroArch’s decision to work with cropped images in the first place.

Signal height of games intended for running on NTSC monitors is actually very well known. It’s either 240 lines (progressive) or 480 lines (interlaced). NTSC is 480 interlaced lines by its nature and 240p is a cheap trick where each line is sent twice. The SNES does both (try some of those hi-res mode games like … that dumb racing game), N64 does both, PSX and Saturn probably do both, too. Things are pretty similar on the PAL side, 288p or 576i.

Games are all running at one of these resolutions, frequently with black emptiness filling up the area between the active area and the edge of the signal (although other platforms like the Master System fill with a solid border color). See, e.g. PAL SNES games running at 224 lines in a 288-line window and have a guess why it sucks. If the developer was feeling charitable, they might choose to expand the picture out to the full 240 lines (the SNES’s maximum) to soften the blow a bit, but 240/288 is still pretty mediocre, and it really shows that these consoles are built for NTSC and PAL is an afterthought. But yeah, it is definitely known what signal these systems were outputting.

#83

Yes, I was rethinking on my wording and went directly to edit the post just to see you already posted. Rather than what’s the full signal, the real question should be what systems is RetroArch cropping the resolution to.

I just realized, coming from the video field, that the padding is simply what I call overscan, or NAB. With that on mind it makes sense now all of these are 240. But as I said people are so so confused that lies like these expand like the cholera. Go to system16 for CPSII and resolution is filled with 384x224 (really?), I just went to a page saying some Genesis games were 224 and others 240… So there’s the conflicting point. Because DVD video has NAB at the sides you don’t say DVD resolution is 704x480. You normally say the full 720x480 resolution.

I’m very worried because the RetroArch guys want to do a bunch of not realistic additions, and I predict necessary things like these won’t be fixed. So basic that one would think they had been addressed very long ago (similar to the genesis aspect ratio issue now -recently- fixed upon my call).

#84

RetroArch just takes whatever frame the core hands over. Turn off ‘crop overscan’ and bsnes core gives the padded, letterboxed image, snes9x core does not.

Aspect ratio obsession isn’t a particularly interesting topic for most devs. It’s hard to get excited about minutiae like that, particularly when, as soon as you get something implemented, someone else comes along and says “no, no, no, you’re doing it all wrong. I know because of circles!”

#85

So what matters most is accurate hardware emulation, and feeding the current resolution via libretro, like Genesis Plus GX does.

#86

And RetroArch guys never ever fix cores, right?

Yes, obsession isn’t a very exciting thing, getting things (minutiae you say the phosphor guy) fixed is. I’m impressed by your words, ignoring everything shed on this thread and trivializing everything to “circle or not circle”. I would have expected wiser comments from someone who makes shaders. Aspect ratios is a trivial thing if you have the data, and if you are a developer you surely have a few spec papers. I do even understand this, surprises me you don’t. I thought by common sense game developers were shooting for 4:3, but seems mostly not, they were limited by the chips they used and hence made the graphics according to that. Then they would have stopped there or go beyond and take into account the later 4:3 readjust, some did think on that others don’t, at that point you can start talking about circles (which one did they comply to) not before. (read the “hunterk, the circle and me” section)

The interesting bit is why on earth RetroArch decided to crop signal output on all cores (or rather why didn’t they fixed it on cores), and why don’t many of them won’t show the padding even with overscan = false? So much effort on screen, game and audio synchronization, and so little efforts on ratio synchronization, 100% unbalanced. Incoherent decisions everywhere.

What we don’t need is to repeat to boredome the same over and over again. But add new data. If you wanted to shoot for accuracy, then allow an easy way to set custom dar’s (or par, I don’t care which), so we can do what we please. If you wanted to shoot for nostalgia, then you got it ALL wrong. Current RetroArch’s DAR only work with the cropped signal (which is wrong, again I don’t have any papers to proof this), so currently the image shown will be slimmer than you remember if 4:3. AND some cores don’t allow to show the full signal (case in point CPS3), so settings do different things in different cores, a hurrah for inconsistency! If you wanted to show real 4:3 in these cores you would need to ignore the 4:3 setting and set a custom DAR (yes custom to the rescue again!). So there are 2 broken things in RA, but mainly the most important one “custom DAR” setting. Then if you feel generous you could force all cores to output full signal (not a bad idea), and make the overscan setting functional for all cores too. Then we can start talking about circles.

hunterk, the circle and me: In snes (256x240) most of the games were designed with a 8:7 PAR on mind. That would become 292x240. Yes, SMW coin blocks are not square anymore, where’s the trick now? Other games were designed with 4:3 DAR on mind, like fighter games, SFA2 is one of them. That would become 320x240 (double that in my screens) (*note the game has inherent letterbox, sorry, not the best game as example). Now everything looks fat!

cropped signal…full signal

So why is everything wrong after I did “the right thing”? Well simple, because developers didn’t. So bottom line, what Lex says: MIMIC THE HARDWARE, let nostalgics “enjoy” their thing, and fix “custom DAR” setting so “accurators” can do our accurate thing talking about circles or whether designers accounted for NAB/overscan or not, and so forth doing the likes of applying 8:7 DAR on a cropped snes signal (this is what supposedly developers aimed at) for the right geometry.

#87

Anyone else gone way past giving a shit ? What started out as a decent interesting thread has been ruined by a couple of arrogant, self-centered, obsessed wankers. Could the mods just ban the prick above and lock this thread, it serves no purpose anymore except to fuel obsessive arrogance.

#88

Nice to meet you John.Merrit, are your other 9 posts just like this one? If so I would vote for banning you instead. Show respect to older users who push forward development instead of whinning about those that actually DO SOMETHING. Keep wanking my friend, good one.

For the rest interested on the topic, here are some shots comparing different ratios of what I explained above and a photo I just scanned of when I was a kid (Merrit I wonder if you were already born at that time)

[Moderator note: User was warned for this post. Please keep our community civil. We are all working toward a common goal.]

#89

Keep it civil, please. No need to insult one another. We don’t want/need the forums to become places where people are afraid to ask questions or discuss things for risk of flaming and verbal abuse.

@Dogway Yes, core changes happen sometimes, but it’s a pretty tall order to suggest changing how almost all of them function, particularly ones where the libretroization has been upstreamed.

Re: phosphors/shaders, yes, we all have our kinks. The key difference here is that I write my own solutions rather than demanding others to do it for me. Vague Rant and SuperSonic in the Wii subforum wanted a similar option (ViWidth or something…?), so SuperSonic made a patch that mostly worked, submitted a pull request and Squarepusher cleaned it up and merged it. I think it currently is only exposed for Wii/GCN, but perhaps you could tweak it just a bit to make it suit your purposes, as well (or perhaps SuperSonic would be willing to help).

#90

Respect for you, dogshit ? Get fucked you arrogant fuck. Perhaps if you shut the fuck for a few minutes and let the devs do their work. Or why don’t YOU show everyone how Wonderful you are and write your own emulator, otherwise Shut the FUCK up.

[Moderator note: User was warned for this post. Please keep our community civil. We are all working toward a common goal.]

#91

I know it was probably only an early attempt at diplomacy (before tearing down that facade in your followup post), but in my reading this board since sometime last Fall, I’ve really only seen one person that meets your description above. Such behavior is otherworldly in its lack of graciousness and over-the-top sense of entitlement, and I’d like to be able to blame that behavior on a language barrier, but that doesn’t seem to be the case here. It’s a shame because of the negative impact on community. Otherwise, I see cordial, if enthusiastic, emulations purists, and there’s nothing wrong with that.

#92

It would not work, viWidth is a part of the specific video code for GC/Wii. It was already in RA, what I did was make it editable without needing to recompile for every core.

#93

ah, too bad. Thanks for chiming in :slight_smile: