MiSTer FPGA Forum

Sorgelig wrote: ↑Tue Jun 16, 2020 10:12 am No idea about which improvement you are talking about. If you force enable composite blend when it applied on full screen, the same Sonic looks very bad. I never used it till adaptive blend was added. Even if sonic gets some benefit from blending in very particular screens, it's not worths to enable it if it cannot detect the places where it has to be applied.

I would argue the opposite and say that the full screen composite blend is the only correct representation, but of course preferred image quality is a matter of taste, too. That is why options for "more original with composite blend" and "RGB like perfect" are great.

As said, the improvement I am talking about is having more choice in image represenation. The Genesis core can display the games as they were intended with all the tricks used to achieve blending, gradients etc. that could otherwise not be achieved.

Not only I love this feature, as you can read on this thread and I like to add the "catmull rom scanlines filter 010" to it. The image quality is perfect to me personally when using both and I would really love to have this in all the cores that used CRTs.

Note that I do not make such requests lightly, because I am aware that open source developers of populars applications get swamped with feature requests and had I the skill I would do it myself. People without programming skill should and usually will try to contribute in other ways which we tried here by making a point for adding a feature that exists in one core, to the other cores.

Therefore once again a thank you to you and the developers who make MiSTer possible, it is not taken for granted.

We are not asking about the Adaptive Composite Blend, only the fullscreen "Composite Blend ON".

Sorgelig wrote: ↑Tue Jun 16, 2020 10:12 am Wolf3D is originally very pixelated game. Talking about dithering on some walls in this game is meaningless. If you wouldn't show that pic i wouldn't even notice.

At the end of the day it depends on what you experienced growing up, Wolf3D on the PC was one of my absolute favorite games, and when the author wrote that all most impossible homebrew for megadrive I was jumping for joy, only to test it on RGB on my PVM and found that the walls and gun looked like completely wrong, I even reached out to the author to find out if it was a limitation and indeed it was hence why he used composite blend , after plugging in some composite cables it was gorgeous, sure on a PVM the composite is bearable with scan lines disguising the composite blurriness and artifacts on real hardware.

If the aim of the mister is to mimic the original system 1:1 then surely the shortcomings and fringe cases should be included as well? Else its definitely just easier and cheaper just to use software emulation.

Sure, use similar RGB to composite adaptor and use ancient CRT. So everything is already there. MiSTer emulates the console. Composite output is simply not a part of MiSTer, so you need to add it if you are fan of blurry videos.

Basically scaling filter with blurriness already simulates bad quality of composite video.

Sorgelig wrote: ↑Tue Jun 16, 2020 11:16 am Sure, use similar RGB to composite adaptor and use ancient CRT. So everything is already there. MiSTer emulates the console. Composite output is simply not a part of MiSTer, so you need to add it if you are fan of blurry videos.

Basically scaling filter with blurriness already simulates bad quality of composite video.

I remember a post where you referred to the VGA Out as a leftover of debugging and HDMI as the main output of MiSTer, which makes absolute sense. The digital I/O board also drops VGA Out. So why recommend the use of CRTs now?

Composite Blend and filters are already a part of MiSTer, all we ask for is this feature to be extended to the other cores so we can have one more choice of an authentic image on modern, available hardware.

Sorgelig wrote: ↑Tue Jun 16, 2020 11:16 am Sure, use similar RGB to composite adaptor and use ancient CRT. So everything is already there. MiSTer emulates the console. Composite output is simply not a part of MiSTer, so you need to add it if you are fan of blurry videos.

Basically scaling filter with blurriness already simulates bad quality of composite video.

So throw more hardware at the problem, instead of working on the software based implementation?

Crts wont last forever sadly, and really its not about blurry picture quality at all but displaying it the way the developers intended to or how you grew up, the screenshots I posted early is evidence that what people are after isnt blurry picture but proper blending to make the games look correct.

FaSMaN wrote: ↑Tue Jun 16, 2020 11:43 am So throw more hardware at the problem, instead of working on the software based implementation?

This is how it's designed originally. Actually blurriness of composite output wasn't supposed to be abused by dithering to get specific effect.

You call Sonic screen with composite blend (shown above) as normal? For me it looks like crap. It's like whole MiSTer project made in vain if I watch at that pic. Although it's good as a concept and demonstration how bad quality sometimes can give special semi-transparent effects.

I'm not denying that similar composite blend may appear on Master System. This is specific to core and need to be coded in. It's not what can be added independently from core.

As was mentioned already, "looks very bad" / "crap" is a subjective thing. Other people seem to like it. Personally I use CRTs for 95% of my retro gaming, but when I display something on modern panel I need to use shaders or at least some sort of scanlines/filters, because the sharp, square modern pixels look really awful to me. While we may say it's also a personal, subjective opinion, obviously it's also more accurate historically, since there was no adaptive blending or HD panels back then. Trying to promote the modern look as the "correct" one and the old one as "inferior" is not only a complete misunderstanding, but also really unfair and one of the big problems within the retro scene.

I mostly aim for RGB, but can fully understand why people would want composite, and not only because of a few famous examples like this Sonic waterfall. Its inherent softness across the whole scene was the original anti-alias and also colour blending has benefited countless games (eg Amiga's point'n click adventures), artifacting was huge on platforms such as Apple 2 or Atari 8-bit.

In the end of the day it's all about options and choices, and I don't see how adding this option can do any harm, it'd certainly not made the whole MiSTer project in vain - just the opposite, it would bring it closer to the original, intended look. And nobody's demanding it, it's just a feature request. If we don't talk about it, it might never happen.

Sorgelig wrote: ↑Tue Jun 16, 2020 12:04 pm This is how it's designed originally. Actually blurriness of composite output wasn't supposed to be abused by dithering to get specific effect.

I am a bit confused do you mean on the mister side or the consoles side, because on the consoles it has been used for decades for just that especially on earlier systems that cant handle transparencies, just about every fighting game for shadows, demo scene, and with the future Psone core etc....

Sorgelig wrote: ↑Tue Jun 16, 2020 12:04 pm You call Sonic screen with composite blend (shown above) as normal? For me it looks like crap. It's like whole MiSTer project made in vain if I watch at that pic. Although it's good as a concept and demonstration how bad quality sometimes can give special semi-transparent effects.

I am sorry it makes you feel like that, I can sympathise that's how I feel when I see wolf3d without it, on some of the demoscene demos, that relies on it.

Sonic is probably not a good example as its only the waterfalls , slap some scan lines over it and it becomes a lot better though.

Sorgelig wrote: ↑Tue Jun 16, 2020 12:04 pm I'm not denying that similar composite blend may appear on Master System. This is specific to core and need to be coded in. It's not what can be added independently from core.

I am glad to hear, I guess its up to the who ever writes the core, and I think we made a good case here today that some users want it.

Sorgelig wrote: ↑Tue Jun 16, 2020 12:04 pm This is how it's designed originally. Actually blurriness of composite output wasn't supposed to be abused by dithering to get specific effect.

You call Sonic screen with composite blend (shown above) as normal? For me it looks like crap. It's like whole MiSTer project made in vain if I watch at that pic.

Well, like with most tech the developers got every bit they could out of hardware by abusing things that were not meant to be used in that certain way and the artwork for the games was created for standard TV sets. That holds true for basically all retro systems.

I can totally understand your reaction when looking at MiSTer with a "perfect image quality"-dogma in mind, but what is "perfect"? The way it was seen on screen, or the way how the video signal was ideally put out? With the Genesis core MiSTer does "perfect" in both areas, imho, and we can choose the historical accurate (and by many beloved) display or the pixel perfect way.

Sorgelig wrote: ↑Tue Jun 16, 2020 12:04 pmAlthough it's good as a concept and demonstration how bad quality sometimes can give special semi-transparent effects.

That is one of the bonus applications I always have in mind, the teaching aspect, so I can only agree.

Sorgelig wrote: ↑Tue Jun 16, 2020 12:04 pm I'm not denying that similar composite blend may appear on Master System.

It holds true for basically all systems where the artwork was created for standard television setups. To give one more example, on SNES the supposed-to-be-semi-transparent text boxes in RPGs do not look as intended without composite blend.

Sorgelig wrote: ↑Tue Jun 16, 2020 12:04 pm This is specific to core and need to be coded in. It's not what can be added independently from core.

I was hoping that it would be relatively easy to implement as per what Kitrinx said the module was once meant to be very portable. Thus I hoped it would not be a big deal to do. Everything is work, of course, but it sounded like it would not be too much to at least request.

You are in no way making MiSTer less perfect with such a feature. On the contrary: More options make it more powerful in general.


EDIT: Found the link making a case for composite again https://nerdlypleasures.blogspot.com/20 ... osite.html

Just look at the palm trees in Sonic, MiSTer with Composite ON actually achieves this look where they otherwise are just pixel stripes.

Threepwood wrote: ↑Tue Jun 16, 2020 12:44 pm on SNES the supposed-to-be-semi-transparent text boxes in RPGs do not look as intended without composite blend.

SNES already has implemented such blending with option for that. Unlike Genesis, it uses other feature (fake 512px mode) which can be used for full screen blending without sacrificing the quality. You can look at Jurassic Park game for example.

Found the link making a case for composite again https://nerdlypleasures.blogspot.com/20 ... osite.html

Yeah, look at SFII screens. This is total crap. It's like "catch the flea but miss the elephant."
Generic dithering NEVER meant for composite blending. It's standard practice to make more colors on limited systems. It was present a lot on systems without composite output. Of course more blurry pic you make, more it will be blended. But it's absolutely has nothing to do with composite blend. As most of screens on that misleading article. Dithering in most cases are meant to look as dithering without any blur.

Sonic, SoR2 (and some other games) unlike traditional dithering used transparency on each other pixel to explicitly use blending and make semi-transparency effect. Don't assume any generic dithering with semi-transparency technique on above games.

Sorgelig wrote: ↑Tue Jun 16, 2020 1:23 pmYeah, look at SFII screens. This is total crap. It's like "catch the flea but miss the elephant."

Do we really need to throw so much "crap" around here?

I disagree that the article is incorrect and what you call "crap" is a composite video capture of a real Sega Genesis Model 1. This is what the games were developed for and the intended, historically accurate look. The developers and artists did develop games for a common target medium, which was not RGB.

The good thing about optional features is that they can be turned off or on as per individual taste.

Sorry to chime in here. Don't you think you have made your point? As far as I see it it is something that has to implemented into the core. So if a core developer want's to implement it fine. If not there is always the option to get into it and do it your self, it's all on Github!

Sorgelig wrote: ↑Tue Jun 16, 2020 9:33 am While talking how good one particular scene when screen is heavily blurred you completely disregard that wast majority of time it simply render the video as complete crap without any benefits.

I don't disregard the lack of sharpness to me that looks better the sharpness brings out all of the flaws in the image

Crap being subjective term sure the quality of RGB is better as a standard but those games were made with composite in mind and the RGB makes the flaws of the old games more apparent but yeah I guess a lot of people prefer the games to look sharp but I do prefer them to look authentic.

The games were not meant to look pixelated the Arcade versions of 3D games at the time already had bilinear filtering

Actually I do that with all of my classic consoles up until the Dreamcast the consoles use heavy dithering patterns and surely you must know that it was used with the limits of composite in mind there have been many instances where dithering gave a better appearance.

https://youtu.be/niKblgZupOc is an example

But then it is a preference some people prefer RGB but I do prefer the smooth look in the comments section of youtube one referred to it as free anti aliasing.

With that all said you must already know the benefits of composite the project as I quote is so that original hardware is no longer needed the choice of being able to choose is a part of that.

PVMs and BVMs were certainly not consumer grade during their time and all consoles came with RF back in the day the balance between RF and Super Sharpness for me is composite.

lomdar67 wrote: ↑Tue Jun 16, 2020 2:56 pm do it your self

That's a great advice mate. Last time I coded something was a simple BASIC game back in the eighties, and I've struggled even with that. But no matter, I will just drop everything I'm doing now and spend a few years learning Verilog, or whatever other sorcery MiSTer project demands. It totally makes sense, right?

This silly "well, why don't you code it yourself" aside seems to be a common rebuttal in similar situations. Try as I may, I really fail to see why asking about some features is automatically perceived as a grave insult and sign of disrespect, when it's anything but. Such requests bring attention to assorted features and may cause somebody who has the ability to try and fulfil them. And how many times have I heard the "there doesn't seem to be much interest in the X/Y/Z, so..."?

I'm pretty sure most users have great admiration for Sorgelig and the rest of talented people who create the cores and hardware. But we're adults here, so there is no need to preface every post or request with such disclaimers. This respect and admiration also does not mean we have to agree on everything, like in this discussion, which now went well past simple feature request and regards a broader issue (composite=crap).

Asking again and again won't position it any higher on a developer's priority list.
You've made your request, the thread is here for when a developer wants to work on it. (But chances are, if they wanted to work on it, they would already have come up with the idea themselves, and wouldn't need an external suggestion.)

Sorgelig has made it clear that he isn't interested in working on it, and none of the other million or so (hah !) developers has stood up to take it on... so that leaves effectively nobody, unless you decide to take it on. Or wait until new developers arrive, or existing developers reach this on their "to do" lists.

But adding to the thread is just a little annoying, and might serve to reduce developer interest.

...Just saying...

dshadoff wrote: ↑Tue Jun 16, 2020 5:11 pm Asking again and again won't position it any higher on a developer's priority list.

I agree, but we weren't "asking again and again". The initial request has evolved into discussion about reasons for and against it. I don't see anything wrong or annoying about that.

But, indeed, I have stated my point on both counts and will refrain from further posts in this thread (unless somebody wants to carry on with the composite=crap fallacy, though it'd probably be best done in a dedicated thread).

It’s a little off-topic, but maybe this is something for the „composite guys“ : https://twitter.com/retrotink2/status/1 ... 8016002048

lomdar67 wrote: ↑Wed Jun 17, 2020 7:53 pm It’s a little off-topic, but maybe this is something for the „composite guys“: https://twitter.com/retrotink2/status/1 ... 8016002048

Thank you, but this would better go into "Display Devices" where it would get appropriate attention.

It is a composite out board to connect to ta CRT, but this thread here is about composite "simulation" on HDMI Out to get the appropriate composite look on modern displays.

Folks with a CRT do have less of a need for this feature in cores other than the Genesis.

lomdar67 wrote: ↑Wed Jun 17, 2020 7:53 pm It’s a little off-topic, but maybe this is something for the „composite guys“: https://twitter.com/retrotink2/status/1 ... 8016002048

Wow superb just what I was looking for but not sure if he is releasing it.

There is one guy selling one but he has been out of stock for a long time
https://www.antoniovillena.es/store/pro ... o-adapter/

akeley wrote: ↑Tue Jun 16, 2020 4:55 pm Such requests bring attention to assorted features and may cause somebody who has the ability to try and fulfil them. And how many times have I heard the "there doesn't seem to be much interest in the X/Y/Z, so..."?

Don't want to stretch this anymore as it is becoming off topic.

But everybody should consider that MiSTer and (all?) cores are open source and non profit hobby project. So you shouldn't request anything. You can ask or suggest features and that's it.

Sometimes these "suggestion" sound so demanding and for my taste this is not right and annoying! Sorry, but that's the way I see it.

I havent been on here too long and when I joined I thought it would be a good place to discuss new features and make a request or two that will help the greater community, but it appears that some users believe this practice to be irrelevant and we should all game the same, this thread is completely derailed now , what started off as a good conversation with photos, use cases etc... has turned into a * flinging match with some basing their opinion on no logical ground other than their own feelings and desires, to somehow grasp at power and control.

Features can be disabled and enabled, if you don't like one simply don't enable it, rather than shooting people down who request it

lomdar67 wrote: ↑Fri Jun 19, 2020 6:24 am So you shouldn't request anything. You can ask or suggest features and that's it.

"to ask for" is literally the meaning of "to request", see https://www.merriam-webster.com/dictionary/request

lomdar67 wrote: ↑Fri Jun 19, 2020 6:24 am Sometimes these "suggestion" sound so demanding and for my taste this is not right and annoying! Sorry, but that's the way I see it.

Outside of obvious slurs there is no "sound" to text, which makes it so easy to misunderstand. In communication there is a sender who tries to word a message with a certain meaning and context in mind and a recipient who has to interpret the message according to their understanding of the words and within their own context. When the intonation of a voice and visual cues (body language) are missing, then it is the recipient who fills in the gaps with the context they are having in mind. In other words: It can be the recipient who in their own mind adds negativity or hostility to a message that contained none to begin with. It gets worse with language barriers on international forums, because then subtext and connotation are even less reliable than among native speakers.


I can only speak for myself now:

I am never angry or put any hostility in my messages and would want them to be read with a soft, warm and benevolent voice in mind. For example, some people probably read my message from earlier "Do we really need to throw so much "crap" around here?" with an angry and shouting voice in their mind. Try reading it again with a warm and benevolent voice and you will see that there isn't any inherent hostility even is such, text only, words that are void of intonation.


In general, from my own community experience that I can offer:

A good code of conduct in discussions would be to always assume the best intention, but if something comes across in a negative way, then this mindset requires a simple request for clarification, in the way of "this came across like ..., was that your intention?". It is a benevolent mindset of discussion culture that makes debating the most enjoyable.

Likewise, intentions need to be made clear and cannot be assumed by other, third parties. Fruitful discussion requires a to and forth of stating and offering viewpoints that differ and it is only natural to start with a position of disagreement. Claiming disagreement is not claiming the other person to be wrong, but stating that the viewpoints differ. What then happens is an exchange of facts, cases and descriptions of reasons to fully try to explain there differing viewpoints. Viewpoints and opinions can change or can be revealed to not actually disagree to begin with.

There was no statement of rejection to implement such a feature, this discussion here never reached such a point. If there were such a clear statement of "I do not want to do it" that would simply be respected by all parties involved and there would be no hard feelings. Such a statement must come from the people actually involved in that discussion, though and cannot be made on behalf that person by third parties (this is usually refered to as white knighting). Nobody demanded anything, like nobody is required to do anything.

Discussions go a certain way and people behave in certain ways. This is individuality. Together with the emotional void that is the nature of simple text, of course it happens that we: 1) Dislike how a discussion is evolving after getting involved or 2) dislike the topic or mode of a discussion before getting involved. Keeping in mind that nobody is obligated to post, the sensible option is to either stop replying or, if there was no involvement in the discussion yet, to not get involved in the first place. Doing so otherwise quickly leads to derailing the topic, because there is nothing constructive added. Such posts are "off topic". Naturally it may happen that users who are not very aware of this try to steer the discussion culture of a thread to what they deem is the best form of conduct and they do so with the best of intentions. Literal users-level individuals are equals though and if one tries to impose their preferred way onto others, that is usually called "bullying" or "backseat moderating".


Again only speaking for myself:

After 1,5 years of using MiSTer I do a lot of user support here - something I always did and Sorgelig happened to request in his disclaimer recently -, because it is inherent to this aforementioned spirit of a benevolent approach to help each other. There is experience gathered over time and such experience shared makes a community stronger and more pleasant, as well as ultimately the product the community revolves around better. Helping newcomers to overcome initial hurdles helps a community to grow and as a side effect to again add more diverse opinions and viewpoints. In discussions these diverse opinions allow to find better solutions again. More individuals > more viewpoints > more ideas to pick and choose from. This was such a thread of exchaning ideas and viewpoints.

This discussion here is indeed entirely derailed now, but I would be glad to pick it up again, because the different views on our very niche hobby can only make the product better not worse and image representation on screen according to different TV standards appears to be a woefully neglected topic.

Thus: Let's go back to a constructive on-topic talk.

I used to own a SMS (sold it because a Genesis with Everdrive can replace almost all of it) and I remember the composite out being particularly terrible and weird as hell, definitely not like what the Genesis composite looks like (which is still ugly because composite is composite, but otherwise pretty good quality). For that reason I don't believe it's accurate to claim that the Genesis filters should just be copied over to the SMS core, as both systems' composite outputs are actually quite different on the real hardware.

(Meanwhile the RGB out was super clean and absolutely gorgeous. Personally I'm in the Sorgelig camp on this debate, I don't see why people want to deliberately destroy their picture quality for some dubious argument about composite output being the "correct" way to render those graphics (it's not), but to each his own...)

antibolo wrote: ↑Sun Jun 21, 2020 6:46 pm (Meanwhile the RGB out was super clean and absolutely gorgeous. Personally I'm in the Sorgelig camp on this debate, I don't see why people want to deliberately destroy their picture quality for some dubious argument about composite output being the "correct" way to render those graphics (it's not), but to each his own...)

Could not possibly disagree more. The pursuit of fidelity in this case (pixel accuracy) is actually harming accuracy. 80s and 90s developers *ABSOLUTELY* understood how composite dithering could be exploited to increase color palette, and used it to advantage. This is no secret - it's been talked about in *many* contemporary interviews at the time. If you are looking at (nearly all systems' at that time) pure RGB output, you are _not_ looking at what the artist *intended*, whatever your own preferences.

The same is absolutely true of 4:3. *NO* video chip from that era produced square pixels, yet that's how they were drawn - artists had to actually take that into account and compensate for it by drawing art stretched 'thin' so it would appear properly on a 4:3 CRT. "Pixel perfect" (or 1:! square pixels), in retro terms, is *inherently wrong*.

>soapbox> (If you are a wilting flower, the rest is almost certainly going to insult you, so tread carefully!)

I find it interesting that nobody is arguing against a distorted (from a 'pure pixels' standpoint) stretching of output to 4:3, even though it's imperfect by design. Nobody's arguing against the feature to allow stereo mixing on Minimig, despite the fact that it is completely inaccurate (as the system never supported such a thing and output harshly separated audio). There's countless examples, in many cores, of where video and audio output is deliberately "muddied" to achieve either a higher degree of contemporary accuracy and/or player convenience, but somehow only composite blend is controversial. I genuinely don't get it.

For those who seem put off by end users asking for features they find desirable or usable: Please don't code open source. Just code for yourself, use it yourself, enjoy it yourself. I've been doing this for a LONG time, and I assure you that you will quickly tire of this and move on to another shiny, because in reality it's almost certainly people you don't like and has nothing to do with technology. People are the lifeblood of open-source - developers AND users. One has no purpose without the other.

Sorry for being this harsh, but it's getting rather ridiculous. The current spate of devs don't want to implement it, and that's fine - I have no issue with that. But if people want to discuss relevance, and are not just being criticized - but *judged* - for pointing out that _yes, that's really how it was, no matter how much you wish it were otherwise_, I just don't know what to say other than you clearly weren't around to experience it when it was actually happening the first time around. Please take the memories of us old-timers with a little less salt...we sometimes actually know whereof we speak.

I'm also no stranger to coding - I was doing OSS before it was cool (or called that), and I've got a pretty sizable list of very public credits to my name. Rest assured, were I motivated to learn Verilog, I'd *absolutely* do this myself...but I'm not, and I'm older and more tired, and so I'm going to conclude now and hope someone, someday, listens to reason.

</soapbox>

rhester72 wrote: ↑Tue Jun 23, 2020 2:52 pmThe same is absolutely true of 4:3. *NO* video chip from that era produced square pixels, yet that's how they were drawn - artists had to actually take that into account and compensate for it by drawing art stretched 'thin' so it would appear properly on a 4:3 CRT. "Pixel perfect" (or 1:! square pixels), in retro terms, is *inherently wrong*.

Well, sometimes. There are plenty of examples of SNES games where square pixels in the native 8:7 aspect ratio produce true circles, while a 4:3 stretch of that makes ovals. That feature very obviously varies by developer, so you can't just blanket state that one or the other is truly correct.

Sigismond0 wrote: ↑Tue Jun 23, 2020 4:15 pm

rhester72 wrote: ↑Tue Jun 23, 2020 2:52 pmThe same is absolutely true of 4:3. *NO* video chip from that era produced square pixels, yet that's how they were drawn - artists had to actually take that into account and compensate for it by drawing art stretched 'thin' so it would appear properly on a 4:3 CRT. "Pixel perfect" (or 1:! square pixels), in retro terms, is *inherently wrong*.

Well, sometimes. There are plenty of examples of SNES games where square pixels in the native 8:7 aspect ratio produce true circles, while a 4:3 stretch of that makes ovals. That feature very obviously varies by developer, so you can't just blanket state that one or the other is truly correct.

Of course I can. The target display of an SNES *does not show square pixels*. This is demonstrably obvious.

It's certainly correct that some developers didn't follow Nintendo's style guide and couldn't be arsed to actually scale graphics properly (*particularly* with NTSC->PAL conversions in the vertical dimension), but that doesn't suddenly make televisions have square pixels - it makes lazy developers under impossible time constraints. None of this is news, and it doesn't make square pixels 'correct'...or composite blending wrong.

rhester72 wrote: ↑Tue Jun 23, 2020 2:52 pm Sorry for being this harsh, but it's getting rather ridiculous. The current spate of devs don't want to implement it, and that's fine - I have no issue with that. But if people want to discuss relevance, and are not just being criticized - but *judged* - for pointing out that _yes, that's really how it was, no matter how much you wish it were otherwise_, I just don't know what to say other than you clearly weren't around to experience it when it was actually happening the first time around. Please take the memories of us old-timers with a little less salt...we sometimes actually know whereof we speak.

I'm also no stranger to coding - I was doing OSS before it was cool (or called that), and I've got a pretty sizable list of very public credits to my name. Rest assured, were I motivated to learn Verilog, I'd *absolutely* do this myself...but I'm not, and I'm older and more tired, and so I'm going to conclude now and hope someone, someday, listens to reason.

</soapbox>

Not sure what you're talking about. I don't recall seeing anybody say, "that's not how it was", or "that feature has no value".

What I have seen in this thread (and others) is that when developers state that their priorities lie elsewhere (because there are so many things to do, and they need to be prioritized in terms of value versus effort), the thread doubles down to try to persuade them to do it. Now. Because somehow, they feel that if they ask often enough, it will change peoples' priorities. Or that somehow because the feature has relevance to somebody, that it must be implemented by somebody. On their schedule.

Trust me, the developers are thinking about things like composite output and how it differs from RGB. And how some colour shifts from RGB to YUV were not merely translational from colour space to colour space. And how the original developers made use of artifacting. And how NTSC sets were so adjustable that "standard composite" is not easy to define.

But most of all, we are thinking about how much effort it is to implement such a thing, and for what amount of payback, when there are still so many legitimate game-breaking bugs in cores, distorted audio, important cores which aren't ported, poorly-understood hardware, etc. also needing to be done.

Many of the responses to the developers' comments of "acknowledged but not a priority, stop asking" are perceived as "your suggestion has no value", when in fact it is, "your suggestion has already been thought of some time ago, and many other things are more important right now".

So this is the point where, as a developer, I come back to the time-honoured: "If it's so important to you - and especially if you're familiar with open source development - please go ahead and be our guest and implement it yourself". Nobody said such a solution would be rejected.

So. It's somewhere on the list, but not at the top.
Ideally, it would be nice to have a universal solution, but that's a hard problem.
In the meantime, there are filters, please check them out. We know that they don't do 100% of what you want, but chances are - given composite's variability in its history - that any solution would be 'wrong' from some group of the population...

dshadoff wrote: ↑Tue Jun 23, 2020 4:39 pm

rhester72 wrote: ↑Tue Jun 23, 2020 2:52 pm Sorry for being this harsh, but it's getting rather ridiculous. The current spate of devs don't want to implement it, and that's fine - I have no issue with that. But if people want to discuss relevance, and are not just being criticized - but *judged* - for pointing out that _yes, that's really how it was, no matter how much you wish it were otherwise_, I just don't know what to say other than you clearly weren't around to experience it when it was actually happening the first time around. Please take the memories of us old-timers with a little less salt...we sometimes actually know whereof we speak.

I'm also no stranger to coding - I was doing OSS before it was cool (or called that), and I've got a pretty sizable list of very public credits to my name. Rest assured, were I motivated to learn Verilog, I'd *absolutely* do this myself...but I'm not, and I'm older and more tired, and so I'm going to conclude now and hope someone, someday, listens to reason.

</soapbox>

Not sure what you're talking about. I don't recall seeing anybody say, "that's not how it was", or "that feature has no value".

They are right here in this thread, but I'm not going to be more specific because I'm not looking to directly insult anyone or call anyone out. In fact, it was my vitriol over it becoming personal that compelled me to speak out.

dshadoff wrote: ↑Tue Jun 23, 2020 4:39 pm What I have seen in this thread (and others) is that when developers state that their priorities lie elsewhere (because there are so many things to do, and they need to be prioritized in terms of value versus effort), the thread doubles down to try to persuade them to do it. Now. Because somehow, they feel that if they ask often enough, it will change peoples' priorities. Or that somehow because the feature has relevance to somebody, that it must be implemented by somebody. On their schedule.

That's not what I'm talking about either - I agree, all of those things are entirely reasonable. When I see a request being called "stupid" or the intention as "crap", that's just not OK, and (with all due respect) speaks to apparent willful ignorance.

It's not my project, and I have no say - I just feel a line was crossed.

dshadoff wrote: ↑Tue Jun 23, 2020 4:39 pm Trust me, the developers are thinking about things like composite output and how it differs from RGB. And how some colour shifts from RGB to YUV were not merely translational from colour space to colour space. And how the original developers made use of artifacting. And how NTSC sets were so adjustable that "standard composite" is not easy to define.

Perhaps *you* are, but not all - some have been quite clear that either a) that composite blending used to achieve dithering didn't actually exist (of course it did), or b) well even if it did they don't give a crap (and fine, as long as we aren't talking around the point).

dshadoff wrote: ↑Tue Jun 23, 2020 4:39 pm But most of all, we are thinking about how much effort it is to implement such a thing, and for what amount of payback, when there are still so many legitimate game-breaking bugs in cores, distorted audio, important cores which aren't ported, poorly-understood hardware, etc. also needing to be done.

Were that the case, this topic wouldn't exist, because it would never have been implemented for Genesis. To be frank, more effort has been invested (and wasted) in this thread alone than it likely would have taken to port the required code into the SMS core (said from a position of near-total ignorance, but I'm willing to bet I'm not far off at all).

dshadoff wrote: ↑Tue Jun 23, 2020 4:39 pm So this is the point where, as a developer, I come back to the time-honoured: "If it's so important to you - and especially if you're familiar with open source development - please go ahead and be our guest and implement it yourself". Nobody said such a solution would be rejected.

In my experience, most who suggest that do so comfortably because they lack the skill set to do it themselves, but that's just my own observations of 30 years in software development talking.

dshadoff wrote: ↑Tue Jun 23, 2020 4:39 pm In the meantime, there are filters, please check them out. We know that they don't do 100% of what you want, but chances are - given composite's variability in its history - that any solution would be 'wrong' from some group of the population...

As described before, simple filters can't achieve color blending, which is what's been specifically requested (and repeated ad nauseam) here.

My diatribe wasn't a "me too" - it was a combination of a) hey, can we please not rewrite technology history because some people prefer pixel "perfection" and b) let's bring it back over the line from personal attacks to a discussion of the merits of historical accuracy, if nothing else.

It's a forum. Nobody HAS to read this thread. Nobody HAS to respond to this thread. And if developers truly have better things to do, I'm going to take it as read that they are off doing them versus telling others they shouldn't be having a discussion.

dshadoff wrote: ↑Tue Jun 23, 2020 4:39 pm What I have seen in this thread (and others) is that when developers state that their priorities lie elsewhere (because there are so many things to do, and they need to be prioritized in terms of value versus effort), the thread doubles down to try to persuade them to do it. Now. Because somehow, they feel that if they ask often enough, it will change peoples' priorities. Or that somehow because the feature has relevance to somebody, that it must be implemented by somebody. On their schedule.

Would you care to post examples of the behaviour you're talking about from this thread?

rhester72 wrote: ↑Tue Jun 23, 2020 4:24 pm

Sigismond0 wrote: ↑Tue Jun 23, 2020 4:15 pm

rhester72 wrote: ↑Tue Jun 23, 2020 2:52 pmThe same is absolutely true of 4:3. *NO* video chip from that era produced square pixels, yet that's how they were drawn - artists had to actually take that into account and compensate for it by drawing art stretched 'thin' so it would appear properly on a 4:3 CRT. "Pixel perfect" (or 1:! square pixels), in retro terms, is *inherently wrong*.

Well, sometimes. There are plenty of examples of SNES games where square pixels in the native 8:7 aspect ratio produce true circles, while a 4:3 stretch of that makes ovals. That feature very obviously varies by developer, so you can't just blanket state that one or the other is truly correct.

Of course I can. The target display of an SNES *does not show square pixels*. This is demonstrably obvious.

It's certainly correct that some developers didn't follow Nintendo's style guide and couldn't be arsed to actually scale graphics properly (*particularly* with NTSC->PAL conversions in the vertical dimension), but that doesn't suddenly make televisions have square pixels - it makes lazy developers under impossible time constraints. None of this is news, and it doesn't make square pixels 'correct'...or composite blending wrong.

Now you're trying to have it both ways. It's disingenuous to argue that "artists worked hard to make their art in a way that it would display properly in 4:3, so the correct way to view that art is 4:3" and then in the next comment say "artists that made their work with a 1:1 ratio were just lazy and you should still stretch their work". You're trying to both argue for and against an artist's intent in the same breath. If you want to make the technical argument that "4:3 is correct because that's what the final product would be seen on", that's fine. If you want to make an artistic argument that that "viewing the art in an aspect ratio that matches the artistic intent is correct", that's fine, too. But you can't have both, because those two statements are in direct conflict.

And just to be clear, many of these examples of designs that clearly used square pixels were done by Nintendo themselves. We're not just talking lazy third party devs here, we're talking massive tentpole first-party releases like Super Metroid, Super Mario World, and more. Nintendo is the one setting the example of making art for square pixels, and not accounting for the final 4:3 output. If you have an actual style guide that Nintendo published for SNES developers, that would be a very interesting read. But just looking at their own biggest titles, it looks like that may not actually exist.