-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tatsumi rotating sprite device refactor take 2 #13470
base: master
Are you sure you want to change the base?
Conversation
This comment was marked as abuse.
This comment was marked as abuse.
I'm not saying this is an improved PR, it's one that should actually get accepted though, as it has none of the bits that were being pulled up on for insane/pointless reasons in it. My desire is to make progress, simple as that. Having to take my work backwards and jump through ridiculous hoops just for that to happen isn't exactly my idea of fun, but here we are. There should be nothing objectionable remaining in this because I've stripped it all back to the parts that weren't having extra unreasonable demands placed on them so it should be fine. If it's still not fine, I really don't know at this point. |
This comment was marked as abuse.
This comment was marked as abuse.
I see forks as counterproductive, I've no interest in doing that. I'll stop working on MAME altogether before I go that route. As an autistic person, I will keep doing what I do, in ways that I'm comfortable with, and try to find some enjoyment out of it, even if some people want to make it as miserable as possible and bully me the whole time. It is not a me problem if Vas keeps overloading PR feedback with out of scope demands, it's a Vas problem. I've worked this back to where those demands no longer apply. MAME loses a bunch of the clean-ups that I was doing, but as I said, if that's how it has to be to move forward, that's how it has to be to move forward. The scope of this PR is now smaller than the old one, which yes, reminds me just how much of MAME development under his management is walking on eggshells, but I'm used to it by now. Everything in here was in the previous PR without being flagged, so there's absolutely no logical reason why there would be a problem with this one. |
This comment was marked as abuse.
This comment was marked as abuse.
Just no. My motivation is contributing to MAME, things being merged is what
keeps me going with that, keeps me interested.
You do not understand at all and your words are painfully condescending.
…On Thu, 13 Mar 2025, 03:05 modusc896d352, ***@***.***> wrote:
"pushing PRs makes things easier for me!"
no.
just no.
PRs are counterproductive *by design*; it constitutes pushing changes
into a gitbase you have no control over.
so whenever those changes are rejected, protested or objected to by the
people who do control that base (not you), your choices are actually pretty
limited: counterargue in favor of your changes (risky), engage in a
good-faith discussion on what's the best way to make it easier for your
work to be accepted (even riskier) or in the worst cases you can just leave.
pushing changes into a gitbase you do have actual control over is actually
pretty trivial, provided you're all alone in it; doing so into a gitbase
you can't control however is another matter entirely.
if forks slow you down so much and makes you so unfocused that you need to
make PRs for MAME no matter what, forks were designed so you can focus only
on the changes you want to make as opposed to making changes to the entire
gitbase. if all you care about is your work, stash your changes from that
fork first. then, when the time hits to work on your changes again, get
back to that fork and apply the stash to that fork you just stashed your
changes to so you can get back to doing the changes you want.
"Vas feedback is incredibly erratic and he'll reject my changes in just
about any time now but i'm sticking the guns with this one anywat so as to
demand my changes be accepted into the codebase NOW!"
going so far as to suggest i'm punching down on you and i'm bullying you.
what i'm actually trying to do (and actually nearly succeeding in doing) is
to give you a way to preserve that comfortable working process you cherish
so much without having to fight for your changes to be included.
—
Reply to this email directly, view it on GitHub
<#13470 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/BBR6GZNWFU2HMRX5DJTPCRD2UDYZBAVCNFSM6AAAAABY4LVKJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJZG4YTAOJYGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
[image: modusc896d352]*modusc896d352* left a comment (mamedev/mame#13470)
<#13470 (comment)>
"pushing PRs makes things easier for me!"
no.
just no.
PRs are counterproductive *by design*; it constitutes pushing changes
into a gitbase you have no control over.
so whenever those changes are rejected, protested or objected to by the
people who do control that base (not you), your choices are actually pretty
limited: counterargue in favor of your changes (risky), engage in a
good-faith discussion on what's the best way to make it easier for your
work to be accepted (even riskier) or in the worst cases you can just leave.
pushing changes into a gitbase you do have actual control over is actually
pretty trivial, provided you're all alone in it; doing so into a gitbase
you can't control however is another matter entirely.
if forks slow you down so much and makes you so unfocused that you need to
make PRs for MAME no matter what, forks were designed so you can focus only
on the changes you want to make as opposed to making changes to the entire
gitbase. if all you care about is your work, stash your changes from that
fork first. then, when the time hits to work on your changes again, get
back to that fork and apply the stash to that fork you just stashed your
changes to so you can get back to doing the changes you want.
"Vas feedback is incredibly erratic and he'll reject my changes in just
about any time now but i'm sticking the guns with this one anywat so as to
demand my changes be accepted into the codebase NOW!"
going so far as to suggest i'm punching down on you and i'm bullying you.
what i'm actually trying to do (and actually nearly succeeding in doing) is
to give you a way to preserve that comfortable working process you cherish
so much without having to fight for your changes to be included.
—
Reply to this email directly, view it on GitHub
<#13470 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/BBR6GZNWFU2HMRX5DJTPCRD2UDYZBAVCNFSM6AAAAABY4LVKJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJZG4YTAOJYGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Also can I kindly ask that you leave me alone, and stop shitting all over this PR, because this is meant to be the clean one, that can be merged without issue. |
I banned that user, PR comments is not the place for... that. |
I just want to point out, Haze, that that person is most likely TwinAphex/SquarePusher, the guy you were considering joining forces with a short while ago before he hit you with the demand that you remove all of the MAME-related videos from your YouTube channel, which as I recall was the bridge too far. The fact that he actually describes you and I as friends should make it pretty clear how wildly out of touch with reality Daniel De Matteis really is. On an actually relevant note, this seems like a reasonable starting point for refactoring. Nothing appears to be super contentious, it should go in pretty smoothly. |
Let's not go there, I really doubt Modulus is the libretro maintainer. |
This is a stripped version of #13418
The larger part of the clean-ups which involved moving functions around and splitting the driver into more logical files from that PR has been removed as it seems impossible to do so without falling foul of further demands.
This contains the sprite device code and updates to make use of it only, the rendering code is still mostly unchanged from what's in MAME, although the way some bits work has been slightly changed to avoid having to mess with graphic data at init time.
It's definitely a worse version of the PR as from an objective point of view it's missing many of the clean-ups I had worked on prior, but if that's what it takes, that's what it takes. It's still an improvement on what's in MAME right now, just less of one.