EDIT: not interested in this huge post -> scroll down to TL;DRDefinitely I'm having a bad day getting myself understood. I didn't say you're disrespectful.
What I said is that *my* way to show respect to users is to not treat them as idiots. I'm afraid I have a personal crusade against the "don't get too technical" attitude (journalists, etc.).
Wait, it never occured to you that you could
actually get too technical pushing too much volume at once, too fast, and it's not the guy's fault but yours if he's lost and makes mistakes?
I hope you don't believe the world is made of people with training and experience in computer engineering, because most people can't even edit a text file or use command promp, and that includes tons of gamers, it's not their fault, just the majority of people simply learn other trades, and Microsoft/Apple/Google have done everything in their power for decades to help users NOT to learn about computers and everything related. All these people they use tech but don't live in the same world as the people that make it, not at all.
I don't want users that follow a guide blindly. I expect them to understand what they're doing. If they don't at first, no problem, I'm here to answer questions.
And yes, my guide could be better, it was put together in a rush.
Wrong way of thinking if you realize where people stand, when you address random beginners (the status is important) with no experience, and introduce them to a whole lot of new things and terms, you absolutely have to be as broadly understandable, detailed and specific, otherwise it's obvious that if you skips some parts, you will lose a lot of the readers or audience and will inevitably have to deal with a ton of - what will also inevitably at some point in your eyes come as - stupid questions.
Let those who've already graduated from the beginners classes do some individual research and thinking, not the clueless beginners. They
can't guess, and they
will ask you about a myriad of things you
will come to think they do with ill will/motivation or by stupidity, and you'll be wrong.
... and the user complains I didn't warn the -resolution option had to be edited in mame.ini... how would you rewrite that in a simpler way?
No, as I said before I got lost starting with the vmmaker part which was confusing as hell, and it led me to mix up some things with the final part, which is why I asked for further explanations/confirmations, and it's where you made fun of my understanding.
You still don't seem to really realize how tricky this all is to assimilate and manage for a first timer who's barely at the level of monkey-ing a few ini settings and drop logs, how full of pits and traps this was, the volume was just too big.
Seriously I didn't imagine for second you would have produced a guide in such a short time, and I felt compelled to try it asap to honour your time spent on it, while I would have been happy and ok just trying the static method for a while since I was curious and willing to try it first, then wait until you had time to do a writeup for the full method no matter if in months if not longer.
I suggested this method because I did believe it was simpler.
How on earth? maybe from your perspective, but for the layman it involves several more actions and new non-trivial things to deal with compared to using what one already has (just his pc with gpu, regular drivers and GM).
It literally took me minutes to create about 10 resolutions in the amd panel and update a bunch of my already existing game or source ini's in GM, no change of drivers nor dealing with new softwares and manipulations my newbie-self wouldn't really understand so early.
One of the first things you learn when starting with GM is how to use its #1 feature which is framedelay, and therefore to create and manage individual ini's
At that level (call it 'beginner+' lol) it's already there, the knowledge and the material required to benefit from the static method, after creating about 10 custom resolutions (took me 3 minutes) only needed is to update the game or source .ini's with the resolution you want switchres to lock to, and eventually adjust the tolerance.
It's incredibly simpler and most of the knowledge needed is already in the user's head.
The only information he needs and can't guess at his level is in the first part of your guide; how to extract and modify the crtrange, and a couple of precisions like setting monitor custom and turning off modeline generation of course etc (minding that I'm still talking about the amd case here of course)
Now, I'll explain why the NVidia/AMD-regular method is worse. You need to create a mode for each refresh, ok. The problem is arcade systems require hundreds of different refresh rates. You can only add 10 different refresh rates between 50 and 60, each one for an integer Hz value. That sucks.
Want to have 59.18 and 59.61 Hz available? Impossible
57.50 and 57.00 Hz? No way
You may arguee that for a regular user, this doesn't matter. That's subjective.
...
The thing is, there's a method that avoids that limitation and allows any refresh rate in the range, freely available without having to create individual modes. And because this method exists, I believe it deserves to be known. It's implemented in GM and can be potentially used, but it's not been documented until now.
And I thought you were a good candidate to test it, since you already had an AMD card available, that's all.
Well it seems you assumed I didn't know about that... But since I know how to use GM with a LCD - at least the very basic 'monitor lcd' setting - and the basics of SwitchRes for lag reduction since again those are among the very first things one learns when beginning with GM - then I know what it does in practice (playing) and how it locks to the available fixed refresh.
Adding more fixed refreshes from my PC/system would logically make them available to GM for doing the same with those, which naturally results in small game refresh speed variations, but in practically all cases now; smaller ones (about 1% at worst from my tests from ~54 to 61+ hardwares) massively expanding the number of games playing smooth and at even closer-to-correct speeds than before, without doing the often considerable compromises (more % off-speed or triplebuffer) the base 'monitor lcd' configuration alone allows.
It's simple and considerably expands the power and greatness of GM for anyone with very little effort and changes to make to his PC/system.
No perfect results
of course but at least this 'static' method doesn't require the user to change his drivers (which can defnitely be a problem) nor to spend like 20Hrs figuring out what's going on.
For someone who is not chasing after an ideal of accuracy and only needs a simple way to improve his GM experience for a handful of games in an accessible fashion, it's absolutely fantastic, universal.
Then of course there's the real thing you wrote a guide for, but it's not up to you to judge what method people should use, from the beginning you should have simply introduced both methods and simply state what they do and why the 'full' one is better, then let it to the users to choose which one they need/want.
Someone who usually just plays a couple of games if not just one (many users get mame for one single game they love), will be happy to benefit from a degree of improvement, let him weigh and judge how far he's ready to involve himself and his system for the results each method achieves.
I think you should really not assume in advance the motivations, level of knowledge and experience, and expectations in place of users kind of like you had the ability to read their minds, you can't, and naturally you shouldn't attempt to force them to do exclusively what
you want, only your way.
You've declined to let me know about the static method - despite my stating I was interested in
both - and for whatever reason assumed I would be a good ginea pig in an intense/rushed first time experiment, just because I owned an AMD ?
Listen I'll tell you what I think all devs/engineers need to hear as often as possible: 99% people who are using your work don't think like you, not in the least, they can't and won't (only a handful might catch up in time) and that's normal.
That doesn't mean they're wrong nor idiots, when you create something you do it for either yourself only, or a restricted number of same-world initiates, or both
plus the broad public audience.
MAME is the latter, but GM even expands the possibilities thanks to what you've brought in it, and it has several levels of use and therefore levels of accessibility, each with a corresponding level of skills and output.
If you want to force all users to go straight to the lets say 'intermediary' levels, you're cutting off and chasing away all the beginner's audience that obviously can't, will give up and even curse GM for making them powerless. Yet that beginner's base, as you say 'uneducated', makes nearly ALL of the users pool.
Seriously I'm baffled that this ability to use more refreshes on even non-VRR LCDs has been there for so many years and everyone unaware of it, it's yet another KILLER power feature of GM that shows how superior it is, afaik no other emulator does this, even the static method which is accessible to almost anyone is crushing all other variants of the emulator.
It allows people who play retro games to break free from the fixed 60Hz prison, even the static method as limited as it is a HUGE leap forward for any user.
Almost-to-actual-VRR without a full freesync/gsync setup? that friggin' MAGIC to a MAME user !
I don't know how long you've known about it, but if you have for a long time yet weren't aware how much users value that and how much popularity exposing it - and I mean both methods - and let people choose which they're going to go for, would have earned GM, then you're living in a dimension paralled to the user's.
I'm very much aware you're - as far as I'm concerned - the greatest contributor to MAME when it comes to the video performance and flexibility, and more! I've been following GM for years so of course I know, and I admire what you've done, but despite that you share with most devs/engineers (mamedev or not) a bit of their unawareness of the fact that it's you as a developer who should adapt to their condition/level if you expect to be understood and not clash with them, not the other way around, of course since almost all of them share no knowledge similar to yours.
If you can't measure how big the gap is and that it's you making a mistake when you get too technical too fast, again doing so you'll alienate too many users and your achievements will remain stuck in a niche where only a handful of people with enough level will ever use it and talk with you, basically remaining in a small bubble world, which is a shame considering the place GM deserves.
You can repeat "it's not GMs original intended use" if you want and limit your support if you are maybe unpleased with the perspective of seeing more people - mostly noobs - flocking around GM after they realize the FACT that it's also the greatest for LCDs but for some not in the manner you personally wish for.
But if you do wish for that yet another incredible side of GM to come out in the light and be known, then by all means listen to people like me, if you need a guinea pig for something it should be for writing those guides in a manner that works for even the layman starting from scratch.
This way people learn, it's the best way, show them everything without skipping portions and in the best understandable formulation (sometimes you suddenly use terms I have no idea about, latest: 'header', I don't know what that is). You can use me; ask me anytime if I understand and if I can do it, and listen every time I tell you I don't get it/can't - and don't misinterpret or make fun of my ignorance when it shows - that is if you plan to expand/refine your guide(s), of course.
In short if you don't know what people don't understand, use them to learn about their ignorance. I don't know if you've ever taught people, but trust me: half the job you learn it from your pupils.
TL;DR To conclude;
- I've found the way to the static method on AMD's by deducing bits from here and trial-and-error. I haven't posted it yet, do you want me to tell it here and see about maybe arranging a writeup or did you already know but really don't want people to learn about it ?
- I'll gladly do the crt_emudriver method from scratch again this time being aware I'm a guinea pig, but only if you accept to listen when I tell you there's something I don't get/can't do and should be reformulated/redone in your guide, only if you keep in mind the knowledge/skill gap at all times. If you won't consider this then let's forget about that.
- Yes again I believe the Groovy for LCDs guide should be a multi-chapters one, starting with the basic 'monitor lcd' level (done), then static for nVidia (done) followed by AMD, then the full/VRR level one for crt_emudriver compatible AMD owners (done but definitely in need of some refinement IMO)
- On that topic; you said there was no problem coming from crt_emudrivers but since updating to the most recent AMD regular drivers I've witnessed something different and that could be important, are you interested in knowing what it is ?
--
@Paradroid; I won't answer your post because it's a school case of yet another person who assumes a ton of things really wrong about someone out of nothing but misuderstanding and prejudice.
--
Listen guys I'm not here to start a war against GM, it's
exactly the opposite, I think it's so great, even greater now with what I've witnessed these few days, it's insane how much more powerful it is compared to other options, yet IMHO impaired by a too narrow perception of its worth and its potential audience, and that's SO frustrating.