A case for 5x vertical crop in 1080p mode.

[SegaSnatcher]

If this were set as a scaler option, it would be system-wide. Likewise, if it were a hidden option as somebody had mentioned above, it would be "set and forget".

If the user enables such an option because they like the look of it on the NES core, they will assume that all is well, and could frankly forget that they set it up... or more specifically, forget that it does cropping (or assume that it never did cropping).

One day, same user - forgetting that this global setting was enabled - uses the TurboGrafx core, and plays a game where the outer portion of the screen area is used for critical information, and doesn't see it. Can't find a score, etc. They report a bug, when then wastes a lot of time. Being a hidden option, the user may have even forgotten that they ever set it. This happens all the time.

If it's a core-based OSD option, at least they can transcribe their settings in the bug report, and that cores for which it doesn't make sense don't even provide the option to crop.

With most TVs in the past several years being 4K (vertical resolution of 2160), most will automatically convert a 720p signal to 4K with an internal line-triple upscale... not sure what this commotion is all about, and why people feel the need to trim 10% of the screen to make it fit in an older TV.

Yeah, not saying this should be a global setting, but something you would either have within the core itself, or a custom per core setting you do in the ini settings, like custom aspect ratios.

Please remember that while Genesis and SNES output 240p signals, really only 224 lines have useful information, which means even if you output 720p on a new TV you will still see black bars at the top and bottom. While NES will show information outside 224 lines, a lot of it is garbage information that a CRT would have cropped out anyways. Also, 4K TVs tend to scale 1080p a bit better than 720p, since most HDTVs aren't doing nearest neighbor scaling anyways.

This has nothing to do with the age of the HDTV people are using, we just want to be able to fully fill the vertical height of our screens using an integer scale, while also being able to turn off interpolation completely by implementing a custom 6x horizontal aspect ratio. Plus, scanlines would work too.

Lastly, its not hard to educate people on new features if you are willing to do so. Most MiSTer users are not casuals, but enthusiasts. 5x cropped scale is a standard feature on both Emulators and Analogue consoles, and I have yet to hear of users complaining about that. So, this is why I don't see why we should have a double standard for MiSTer, when the above mentioned devices seem to be doing just fine with a 5x crop setting available to general users.

[ash2fpga]

Yeah, I'm in the camp that a 5× with vertical crop mode would be more trouble than it's worth, at least at this stage. The MiSTer can always be connected to an OSSC in the meantime.

I have had my mister connected to my ossc, and had much worse issues with having to fiddle with the ossc sampling options for mister than with original hardware (consoles). Having cropping options over the native hdmi mister output would be much better, IMO.

[Insert Disk Two]

Most TVs don't even like OSSC. Let's not complicated things unnecessarily.

[LamerDeluxe]

You can set all config.ini options per core, which I do for most arcade cores. So I don't think adding these options to the already existing config.ini options would be a problem at all, unless the user has no idea what he is doing.

[dshadoff]

About 1 out of every 3 issues logged on TGFX is due to users overriding core defaults, and not realizing that they have set the core to something different than how the original machine behaves. (CD fast / 64 sprites / etc.)

But as I say, I am stating this as somebody who maintains cores... stating possible reasons why FPGA programmers might choose to prioritize their efforts working on other things than this - and ways in which it might have a less-burdensome implementation. I'm pretty sure the FPGA programmers understand where I'm coming from.

[SegaSnatcher]

I do understand where you are coming from, but I just don't think people who are guilty of "user error" should be the reason why some useful features don't get implemented. I mean your concerns about this feature could be applied to any other new feature that gets implemented right?

If I was asking for some esoteric feature that very few have heard about, I'd totally understand, but 5x crop is incredibly common and well known throughout the FPGA and Emulator gaming communities.

I'm sure if anyone implements this feature they will take the things you are concerned about into account. I will also do my best to educate users about this feature if they are confused.

[Insert Disk Two]

Even Analogue consoles have X5. We can't have an option which is available on Analogue not be on MiSTer cant we

[dshadoff]

I mean your concerns about this feature could be applied to any other new feature that gets implemented right?

It could be applied to any other new feature that gets suggested, and the merits are weighed against the costs.
And several requests fail to proceed on this basis.
But many are implemented, in a way that attempts to reduce confusion and support effort.

[SegaSnatcher]

I mean your concerns about this feature could be applied to any other new feature that gets implemented right?

It could be applied to any other new feature that gets suggested, and the merits are weighed against the costs.
And several requests fail to proceed on this basis.
But many are implemented, in a way that attempts to reduce confusion and support effort.

That is why I suggested on github to maybe first limit this feature to NES core first and see how it goes. If that passes without issues then I don't see a problem implementing on other 240p console cores as well.

I highly respect your opinion and input, but regarding this specific feature I think you are more concerned than need be. As I and others have stated before this feature has been implemented successfully on other platforms with no serious issues, so I just don't see why MiSTer should be treated differently. I would think stuff like Save States would be more invasive from a hardware standpoint than 5x crop scaling.

Correct me if I'm wrong, but your main concern is if this ends up in the core menu that someone might accidently turn it on and wonder why their image is cropped? 1. That can be said about any feature that can have a visual change, e,g, "Composite Blending", 2. It would be pretty easy to find out if the problem someone was having is that they turned on 5x crop by mistake based on the details they gave and or pictures they posted.

A custom ini setting for this feature would make this debate irrelevant, since anyone who would take the time to type in a custom core setting obviously would have an understanding on what it will do.

Just wanted to say, I appreciate everyone's feedback here. Its great to talk about the merits of features.

[dshadoff]

I highly respect your opinion and input, but regarding this specific feature I think you are more concerned than need be. As I and others have stated before this feature has been implemented successfully on other platforms with no serious issues, so I just don't see why MiSTer should be treated differently. I would think stuff like Save States would be more invasive from a hardware standpoint than 5x crop scaling.

Correct me if I'm wrong, but your main concern is if this ends up in the core menu that someone might accidently turn it on and wonder why their image is cropped? 1. That can be said about any feature that can have a visual change, e,g, "Composite Blending", 2. It would be pretty easy to find out if the problem someone was having is that they turned on 5x crop by mistake based on the details they gave and or pictures they posted.

A custom ini setting for this feature would make this debate irrelevant, since anyone who would take the time to type in a custom core setting obviously would have an understanding on what it will do.

My concern is that cropping to 216 lines will negatively affect some cores, even if it pleases some people on the NES/SNES/Genesis.

Implementing system-wide as a scaler option (as was originally suggested) would affect all cores - which would confuse people. If it is implemented on a per-core basis as an OSD option, that would be significantly better, as cores which would not benefit would not be forced to have the feature. Also, as had been mentioned earlier, it would not seem to require any changes to the scaler.

I respectfully disagree that everybody making changes to .ini is going to have a clear understanding of what they are doing; many people follow instructions posted online without a clear understanding. MiSTer is no longer limited to tech-wizards; it already has significant support from the non-tech community as well.

[Insert Disk Two]

Not adding a feature because not everyone would know how to use it is not a very good reason. In my very humble opinion.

[dshadoff]

Not my point.

Hierarchy:
- everybody benefits
- some benefit, but nobody suffers. Easy to support
- some benefit, some struggle. Consumes support time. <- this is not a good position on the hierarchy

You are free to implement the feature yourself and try to get it integrated into the main corpus (or fork and have a parallel system if that fails). But arguments such as “that’s not a good reason not to do it” or “xyz system has it” are not persuasive arguments to get a developer to work on your feature over something else that they wish to do. Developers also need to consider how much future effort is involved in support or conflict resolution before embarking on something.

[SegaSnatcher]

My concern is that cropping to 216 lines will negatively affect some cores, even if it pleases some people on the NES/SNES/Genesis.

If its an optional feature then how could it negatively affect cores? If a user doesn't like how it looks then just like any other feature they can simply disable it. Again, the usefulness of this feature will be on a core by core basis. NES, Genesis and SNES just happen to be the most popular consoles where people use 5x crop.

Also, I agree with you, this feature won't make sense for every core and I'm not asking for this feature to be a global option. In fact the devs who I have talked to thinks its best to keep it in the core menu, so I wouldn't worry about this feature becoming a global feature.

Please try and keep an open mind about this feature even if you don't understand why people want it.

Not adding a feature because not everyone would know how to use it is not a very good reason. In my very humble opinion.

Exactly, there is no reason to show a double standard for this specific feature over all the other features that have already been implemented.

[dshadoff]

If its an optional feature then how could it negatively affect cores?

I get the feeling that you may not be reading what I'm writing, as I have addressed this point repeatedly.
So I'll stop now, as this is going nowhere.

[SegaSnatcher]

If its an optional feature then how could it negatively affect cores?

I get the feeling that you may not be reading what I'm writing, as I have addressed this point repeatedly.
So I'll stop now, as this is going nowhere.

I have definitely read what you wrote, I just don't think you have given adequate evidence that proves this feature would cause issues, no offense.

I do hope if implemented, it does in a way that satisfies your concerns. Thank You for all your contributions. Wasn't trying to be argumentative or anything, its good to talk about pros and cons of features and further educate people who may not understand what this feature does.

[rhester72]

I guess my personal confusion is the argument that "could cause support problems / user confusion / hell to freeze over" could be applied to damned near every EXISTING configuration option. Why is this, arguably more useful than some others, feature being particularly bemoaned? Don't make it a default, allow it to be set globally or per-core by hand-editing the INI only, and done. Why all the drama?

[SegaSnatcher]

I guess my personal confusion is the argument that "could cause support problems / user confusion / hell to freeze over" could be applied to damned near every EXISTING configuration option. Why is this, arguably more useful than some others, feature being particularly bemoaned? Don't make it a default, allow it to be set globally or per-core by hand-editing the INI only, and done. Why all the drama?

That is exactly the point i was trying to bring up. Why single out this feature as potentially "Problematic" when there are so many other features already implemented that you could say the same thing about. I think the real reason for those against the feature is that they don't fully grasp why people want this feature and the usefulness it offers in some situations.

Its sad to see people resort to the doom and gloom approach because they don't understand something. Its just another scaler option lol, nothing too crazy.

[Newsdee]

Its just another scaler option lol, nothing too crazy.

That's exactly the point. Guy tells you the feature is a pain in the butt to work on because of all kinds of non-technical drama and endless tweaking after it's written, and here you go trivializing the change making it sound an effortless trivial five minute tweak.

Nobody cares enough to make it work, and nobody owes work to anybody especially if it's not fun to work on it.
If you don't agree with that, then please go ahead and implement the feature yourself. Learning how to do it should not be an issue, after all you fully grasp why people want it so badly and how useful the feature is. Finding the motivation to put in all the required work shouldn't be a problem, right?

[SegaSnatcher]

Its just another scaler option lol, nothing too crazy.

That's exactly the point. Guy tells you the feature is a pain in the butt to work on because of all kinds of non-technical drama and endless tweaking after it's written, and here you go trivializing the change making it sound an effortless trivial five minute tweak.

Nobody cares enough to make it work, and nobody owes work to anybody especially if it's not fun to work on it.
If you don't agree with that, then please go ahead and implement the feature yourself. Learning how to do it should not be an issue, after all you fully grasp why people want it so badly and how useful the feature is. Finding the motivation to put in all the required work shouldn't be a problem, right?

I only say that because the developers I've talked to said implementation is not extremely difficult. I know if someone were to implement it that they would have to do it in a way that makes the most sense and avoids as many issues as possible. I'm sure Sorg wouldn't accept half baked implementations, so I trust anything he would consider would likely be okay.

[Newsdee]

I know if someone were to implement it that they would have to do it in a way that makes the most sense and avoids as many issues as possible.

That's the main problem; even if you are familiar with making core changes, this touches many parts (the core, the upscaler, the MiSTer core framework) and while the feature is simple to formulate ("just keep integer scaling at higher res but crop the screen"), there are multiple ways to do it with different caveats.

Let's give a (very bad) example: I am not familiar with the scaler code - so I wouldn't want to touch it. But I know where the NES core generates its signal, and maybe with enough tinkering I could work out how to chop off horizontal video lines at the source video signal. I could then work out how to plug it into the OSD options, say with a configurable amount of lines to remove. Maybe in a few weeks I could have something with 5x. That would work great for my own use...

...but if I want to then merge that change, all kinds of new problems will arise: the CRT people would complain it crops their output ("sure, then don't use it"), other core developers will complain it pollutes the OSD and remove (limited thus valuable) flags available for the OSD config ("let's use the INI?"), the different chopped screens will screw up all aspect ratios (also breaking the INI solutions for custom AR, oops), and I probably forgot / overlook other technical caveats of taking this blunt approach (e.g. do I need a frame buffer to make it simpler? but will that impact latency?..)

That's not even considering the amount of confused users that would not understand why they need an aspect ratio calculator and change settings every time they want to switch games. Etc, etc... suddenly my quick hack and exploration for fun became a nightmare of having to deal with a lot of disgruntled developers and users.

Sure, you could say every feature is like that; but I'd be only willing to go through it all if I was fully convinced that I either want the feature really badly as an official core feature, or if I'm motivated enough to defend it all the way through because I think that's the One True way to do it (which may result in clashes which caused spin-off fork to appear- not a good outcome anyway).

A lot of effort went into MisTer options to keep them simple yet capturing most of the desirable configs. I'd like to see 5x implemented (it's great for RPGs) but obviously nobody worked out yet a good way to approach it.

[FoxbatStargazer]

720p 3x still shows a visible border for these kind of cores (NES, Genesis, etc.), that's enough reason alone for interest in a 5x 1080p mode, filling the entire vertical space without introducing non-integer scaling.

More resolution is also always a plus for representing these often non-square pixels on a square pixel display, particularly with sharp interpolation.

[SegaSnatcher]

I've just simulated a centralized vertical 1200p crop to 1080p with a screenshot captured from an emulator on the PC using GIMP and I kinda like the result:

It seems to match where my old TV used to crop when playing with my original Sega Mega Drive back then in the 90's.

I really hope this become a reality in the near future.

Grabulosaure posted updated 5x crop builds for Genesis and SNES on Classic Gaming Discord. Looking pretty darn sweet.

Sadly, custom aspect ratios seem to be currently broken, but hopefully that gets fixed.

IMG_1284.jpg (1.32 MiB) Viewed 7663 times

IMG_1282.jpg (1.63 MiB) Viewed 7663 times

[SegaSnatcher]

More great news. Grab has added a 5x crop build for NES!

IMG_1287.jpg (2.51 MiB) Viewed 7549 times

IMG_1288.jpg (1.5 MiB) Viewed 7535 times

You can find all the 5x crop test builds in the link below. Make sure you are using integer scaling. Custom Aspect Ratios currently do not work.

http://temlib.org/pub/mister/crop/

[bootsector]

@Grabulosaure do you have plans to open a pull request for these soon? Thank you so much for implementing this!

[Insert Disk Two]

Just tested NeoGeo, this is fantastic. I wonder if it is possible that this is added to all the cores automatically?

I really hope C64 gets this option added, as it is in dire need of the option for 1080p!

[SegaSnatcher]

@Grabulosaure do you have plans to open a pull request for these soon? Thank you so much for implementing this!

The one thing that needs to be fixed is the ability to use custom aspect ratios for 5x crop, currently they do not work.

[bootsector]

@Grabulosaure do you have plans to open a pull request for these soon? Thank you so much for implementing this!

The one thing that needs to be fixed is the ability to use custom aspect ratios for 5x crop, currently they do not work.

Yeah, I've noticed that. But I think it deserves a pull request as it is, so people can jump in and collaborate more easily if it's on github!

[SegaSnatcher]

@Grabulosaure do you have plans to open a pull request for these soon? Thank you so much for implementing this!

The one thing that needs to be fixed is the ability to use custom aspect ratios for 5x crop, currently they do not work.

Yeah, I've noticed that. But I think it deserves a pull request as it is, so people can jump in and collaborate more easily if it's on github!

Oh, also there is a bug when you switch between 16:9 and 4:3 modes where it will get stuck to 16:9 if you change the aspect ratio in the core menu, that at least should get fixed before a PR.

[bootsector]

The one thing that needs to be fixed is the ability to use custom aspect ratios for 5x crop, currently they do not work.

Yeah, I've noticed that. But I think it deserves a pull request as it is, so people can jump in and collaborate more easily if it's on github!

Oh, also there is a bug when you switch between 16:9 and 4:3 modes where it will get stuck to 16:9 if you change the aspect ratio in the core menu, that at least should get fixed before a PR.

Hopefully Grab is still cooking this up until we'll finally see a pull request!

[LamerDeluxe]

I notice a lot of people use the custom aspect ratio to get clean square pixels. An option for integer scaling both horizontally and vertically would handle that much more easily. Also it still doesn't seem possible to achieve horizontal only integer scaling using a custom aspect ratio.