Adding features to SDL vs creating a satellite library

SDL Development
41

Actually, the last I heard about the SDL_RenderGeometry patch was
that because software rendering of textured polygons was "too slow"
and “just bloat”, it was not wanted.

Which is precisely what I’m “bitching” about:

PATCHES ARE NOT WANTED.

Sik is having to fight tooth and nail to get accessibility support to
even be accepted as a concept because “it doesn’t belong in SDL”,
despite the established fact that it cannot be done anywhere else.
To listen to this mailing list, absolutely NOTHING belongs in SDL,
including some of the stuff that’s already there.

So I’ll “gtfo” now. Somebody else can fix the joystick mapping thing
I guess, or it will stay unfixed. My solution (for which I have had
code for a year BTW) got caught up in “breaks compatibility”. (It
didn’t actually, though Steam obviously won’t know what to do with
half- or inverted-axis maps until it was updated?)

JosephOn Fri, Jan 23, 2015 at 04:05:54PM -0300, Gabriel Jacobo wrote:

Dude, enough bitching. The SDL_RenderGeometry patch is there for the
taking, add software rendering support to it, test it on our main target
platforms (or get someone to test it) and it goes in, simple as that. The
situation for many users will be better with that “simple” act.

No amount of pouting will change things, at some point the ugly truth
is…patches or gtfo.

2015-01-23 15:55 GMT-03:00 T. Joseph Carter <@T_Joseph_Carter>:

Great, more external dependencies! Oh, and in this case the need to write
my code for OpenGL ES which is almost but not quite OpenGL.

I’m beginning to remember all too clearly why I stopped working on SDL.
It isn’t worth fighting with people over every single detail and watching
patches go unused because they do something, anything.

Joseph

On Fri, Jan 23, 2015 at 02:48:44PM -0400, Alex Szpakowski wrote:

https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter < @T_Joseph_Carter> wrote:

OpenGL dependency, which kind of means no WinRT.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

42

[…]

It’s a 2D game.
[…]

They’re all 2D games. What we’re all doing (well, most of us, at
least) is using various hardware and software to render stuff into a
2D array of pixels. What is typically referred to as a “2D API” is
just an arbitrary subset of the graphics rendering capabilities that
are explicitly supported by commonly available platforms.

So, where do we draw the line? If we don’t, “2D” becomes irrelevant,
and what we end up with then (as of now) is one of the mainstream 3D
rendering APIs. There is no golden feature set that will cover
everything everyone considers 2D. There will always be another missing
feature.

Anyway, FWIW, I pretty much agree that the one missing feature in the
current API is SDL_RenderGeometry(), mostly because it seems close
enough to what’s already in there, while eliminating lots remaining
"must use OpenGL" situations. Going much beyond that (more blending
modes, z-buffering, custom shaders etc) is a slippery slope, leaning
towards Yet Another 3D API That Still Doesn’t Please Everyone.

If SDL_RenderGeometry() is not enough, my position is still that you
should use OpenGL. Or Direct3D, directly, or via Angle. There’s more
than one 3D API, and there’s nothing much we can do about it! Just be
glad that the days of coding umpteen different machines directly to
the metal are over for most of you! Spoiled kids… ;-)On Fri, Jan 23, 2015 at 7:46 PM, T. Joseph Carter wrote:

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

43

2015-01-23 16:22 GMT-03:00 T. Joseph Carter :

Actually, the last I heard about the SDL_RenderGeometry patch was that
because software rendering of textured polygons was “too slow” and “just
bloat”, it was not wanted.

Which is precisely what I’m “bitching” about:

PATCHES ARE NOT WANTED.

This is not true. I’ve never met Sam or Ryan in my life, I’m just some
random dude from the other side of the world, yet I got a lot of patches
accepted, even patches that added to the render API like SDL_RenderCopyEx
and SDL_SetRenderTarget. The trick to doing that is simple…start by
having the patch, not the idea of a patch or a feature request, then listen
to the feedback provided in good faith, and don’t lash out against it.
Easier said than done, I know.

In turn, I accepted lots of patches from others, many that add
functionality.

I campaigned for having some features added to the renderer code where some
backends didn’t support them (like SDL_RenderGeometry), mostly because I
don’t care about the software backend. I got turned down on that regard for
reasons I don’t exactly share but that I can respect…but the fact remains
that (and Sam said this before), if that patch can be extended by someone
to run on all backends, it will be accepted, simple as that. The software
backend will suck speed wise, but it will be there…“for reference”, I
guess.–
Gabriel.

44

So, where do we draw the line? If we don’t, “2D” becomes irrelevant,
and what we end up with then (as of now) is one of the mainstream 3D
rendering APIs. There is no golden feature set that will cover
everything everyone considers 2D. There will always be another missing
feature.

The problem here isn?t 2D becoming irrelevant - that?s never going to happen.

The problem is that twiddling bits in a buffer with your CPU and blitting them to the screen has been irrelevant for 20 or so years.

SDL_Render is trying to do two orthogonal things: placate the people who just want pixels in a buffer they can muck around with, and placate people who expect it to resemble a modern, hardware-backed drawing API (and supports things like DPI scaling).

Following with Bob?s point from earlier - the API being available means people are going to (ab)use it. For that reason, I think that, at minimum, SDL_render should actually be frozen and moved into a separate extension library. If people don?t want to invest in modernizing their code for accelerated rendering, fine - at least then it won?t be preventing development of the main SDL library. And if you?re smart (or foolish) enough to be mucking around with it, you?re on your own like it?s 1993.

Ideally, something like SDL_gpu would be promoted to being part of the main SDL library. I won?t say SDL needs it, but 2D rendering is a nice feature to have. And people seem to want a modern 2D renderer. So why don?t we invest in actually making a (sane) renderer that can leverage the accelerated graphics API?s available and do things like provide native Hi-DPI support?

Either way - the two things (GPU backed 2D compositing and raw pixel buffer access) are orthogonal, and trying to support both in a single API is a terrible route forward.

-L> On Jan 23, 2015, at 12:27 PM, David Olofson wrote:

45

2015-01-23 16:22 GMT-03:00, T. Joseph Carter :

Actually, the last I heard about the SDL_RenderGeometry patch was
that because software rendering of textured polygons was "too slow"
and “just bloat”, it was not wanted.

It wasn’t even that, and it wasn’t an issue specific to that function
either, but to just about every proposal for the renderer: in order to
make it to SDL we need an implementation for all the backends. People
are willing to make implementations for the hardware accelerated
backends, but nobody wants to touch the software renderer. In fact I
remember that some years ago there were people demanding to get rid of
it altogether. If I recall correctly, it stayed because it turned out
some developers doing commercial programs needed it since it made
handling YUV formats easier somehow (probably due to the software
renderer internally using surfaces).

(also another good reason to keep the software renderer around: some
magnifiers have trouble with GPU-rendered graphics, so the software
renderer is the only one that works with them - at least let’s keep
the option since it’s working already!)

But yeah, basically the problem with the renderer API is that we get
stuck until we manage to settle on implementing the new stuff on all
existing backends.

46

To go along with what Sik is saying and to add another point… SDL is, at
heart, a platform abstraction layer. Think about this: Which platform are
we targeting with the software renderer?

And to expand on Luke’s: It makes sense to have comparable features
supported via both OpenGL and Direct3D, but maybe software rendering should
not be used as a fallback. Maybe it’s better to fail than to pretend that
hardware accelerated features performed at an unusable speed are worth
delaying development progress?

Jonny DOn Fri, Jan 23, 2015 at 4:16 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2015-01-23 16:22 GMT-03:00, T. Joseph Carter <tjcarter at spiritsubstance.com

:
Actually, the last I heard about the SDL_RenderGeometry patch was
that because software rendering of textured polygons was "too slow"
and “just bloat”, it was not wanted.

It wasn’t even that, and it wasn’t an issue specific to that function
either, but to just about every proposal for the renderer: in order to
make it to SDL we need an implementation for all the backends. People
are willing to make implementations for the hardware accelerated
backends, but nobody wants to touch the software renderer. In fact I
remember that some years ago there were people demanding to get rid of
it altogether. If I recall correctly, it stayed because it turned out
some developers doing commercial programs needed it since it made
handling YUV formats easier somehow (probably due to the software
renderer internally using surfaces).

(also another good reason to keep the software renderer around: some
magnifiers have trouble with GPU-rendered graphics, so the software
renderer is the only one that works with them - at least let’s keep
the option since it’s working already!)

But yeah, basically the problem with the renderer API is that we get
stuck until we manage to settle on implementing the new stuff on all
existing backends.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

47

And also consider this - which platforms don’t have some sort of GPU
and hardware accelerated graphics API these days?

-L

To go along with what Sik is saying and to add another point… SDL
is, at heart, a platform abstraction layer. Think about this: Which
platform are we targeting with the software renderer?

And to expand on Luke’s: It makes sense to have comparable features
supported via both OpenGL and Direct3D, but maybe software rendering
should not be used as a fallback. Maybe it’s better to fail than to
pretend that hardware accelerated features performed at an unusable
speed are worth delaying development progress?

Jonny D

2015-01-23 16:22 GMT-03:00, T. Joseph Carter
:

Actually, the last I heard about the SDL_RenderGeometry patch was

that because software rendering of textured polygons was “too slow”

and “just bloat”, it was not wanted.

It wasn’t even that, and it wasn’t an issue specific to that function

either, but to just about every proposal for the renderer: in order to

make it to SDL we need an implementation for all the backends. People

are willing to make implementations for the hardware accelerated

backends, but nobody wants to touch the software renderer. In fact I

remember that some years ago there were people demanding to get rid of

it altogether. If I recall correctly, it stayed because it turned out

some developers doing commercial programs needed it since it made

handling YUV formats easier somehow (probably due to the software

renderer internally using surfaces).

(also another good reason to keep the software renderer around: some

magnifiers have trouble with GPU-rendered graphics, so the software

renderer is the only one that works with them - at least let’s keep

the option since it’s working already!)

But yeah, basically the problem with the renderer API is that we get

stuck until we manage to settle on implementing the new stuff on all

existing backends.

SDL mailing listOn Fri, Jan 23, 2015, at 01:53 PM, Jonathan Dearborn wrote:

On Fri, Jan 23, 2015 at 4:16 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

48

I understand the frustration at not having patches accepted and not having
features accepted. Believe me, I do. For several years I was a committer, I
could check in my own patches, and I still had patches rejected. I have had
patches rejected for many reasons, but the main one is that* I do not have
the global view* of the project that Sam does. And, you know what, I never
will have it. Sam and Ryan have to look at how every patch affects the
entire design of the existing system, their ideas for the design of the
future system and how the change will affect every person who uses the
system right now. Not to mention things like the documentation and the
demos.

Small changes can cause huge ripples of trouble for people. How much code
has to be debugged and changed to adapt to the change? How many articles
and tutorials have to be rewritten to accommodate a change in SDL
semantics? How many people will wind up posting here wondering why things
changed? The social implications of small changes can be huge. How many
people will lose how many minutes of their time if a small change is made?
It doesn’t have to be very many minutes or very many people before it ads
up to one or more complete human lives. Every change has to be balanced
against that.

Yes, of course you can use the same arguments to justify adding things.
Accessibility may be the perfect counter example. (though you would have to
work a lot harder to convince me it was. Consider that I now use several
accessibility features to be able to use a web browser but have no trouble
playing games.) You also have to consider how much time Sam and Ryan have
to spend evaluating things. They have lives that are separate from SDL. I
don’t know that much about Ryan, but Sam has a family, every minute he
spends on SDL is time he could be with his family. I well bet that on his
death bed Sam will not say “I wish I had spent more time on SDL and less
time with my family”.

Bob PendletonOn Fri, Jan 23, 2015 at 3:04 PM, Luke wrote:

And also consider this - which platforms don’t have some sort of GPU
and hardware accelerated graphics API these days?

-L

On Fri, Jan 23, 2015, at 01:53 PM, Jonathan Dearborn wrote:

To go along with what Sik is saying and to add another point… SDL is,
at heart, a platform abstraction layer. Think about this: Which platform
are we targeting with the software renderer?

And to expand on Luke’s: It makes sense to have comparable features
supported via both OpenGL and Direct3D, but maybe software rendering should
not be used as a fallback. Maybe it’s better to fail than to pretend that
hardware accelerated features performed at an unusable speed are worth
delaying development progress?

Jonny D

On Fri, Jan 23, 2015 at 4:16 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2015-01-23 16:22 GMT-03:00, T. Joseph Carter <tjcarter at spiritsubstance.com

:
Actually, the last I heard about the SDL_RenderGeometry patch was
that because software rendering of textured polygons was "too slow"
and “just bloat”, it was not wanted.

It wasn’t even that, and it wasn’t an issue specific to that function
either, but to just about every proposal for the renderer: in order to
make it to SDL we need an implementation for all the backends. People
are willing to make implementations for the hardware accelerated
backends, but nobody wants to touch the software renderer. In fact I
remember that some years ago there were people demanding to get rid of
it altogether. If I recall correctly, it stayed because it turned out
some developers doing commercial programs needed it since it made
handling YUV formats easier somehow (probably due to the software
renderer internally using surfaces).

(also another good reason to keep the software renderer around: some
magnifiers have trouble with GPU-rendered graphics, so the software
renderer is the only one that works with them - at least let’s keep
the option since it’s working already!)

But yeah, basically the problem with the renderer API is that we get
stuck until we manage to settle on implementing the new stuff on all
existing backends.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

49

[…]

The problem here isn?t 2D becoming irrelevant - that?s never going to
happen.

The problem is that twiddling bits in a buffer with your CPU and blitting
them to the screen has been irrelevant for 20 or so years.
[…]

The point I was trying to make is that “2D” is just a vaguely defined
subset of graphics rendering, whether you’re doing the bit twiddling
in custom code, a software library, or in hardware.

However…On Fri, Jan 23, 2015 at 9:06 PM, Luke Groeninger wrote:

On Fri, Jan 23, 2015 at 9:53 PM, Jonathan Dearborn wrote:

To go along with what Sik is saying and to add another point… SDL is, at
heart, a platform abstraction layer. Think about this: Which platform are
we targeting with the software renderer?

And to expand on Luke’s: It makes sense to have comparable features
supported via both OpenGL and Direct3D, but maybe software rendering should
not be used as a fallback. Maybe it’s better to fail than to pretend that
hardware accelerated features performed at an unusable speed are worth
delaying development progress?

Tough call, actually… Sometimes, like in GUI code, and load-time
preparation of in-game graphics, performance is not all that critical,
but it’s important that it actually works, or you’ll have nothing to
feed to the part that actually is hardware accelerated. (Or, “fast
enough,” provided you actually find something that isn’t hardware
accelerated at all…)

Problem is, even slow software rendering code is a lot of work to
implement, compared to passing parameters on to a rendering API. It’s
easy to say that wrapping this or that makes sense because it’s in
both OpenGL and Direct3D, but, this software renderer… If you need
it at all, do you want it slow but accurate, or ugly but fast?

If given the choice, I prefer rolling my own software renderer for any
"advanced" stuff I might need (that would probably be something weird
anyway, like ZeeSpace), to having to deal with various variants of
OpenGL and Direct3D on multiple platforms. I’d rather not actually
code and debug my own Direct3D code, as I do all work on GNU/Linux
normally, whereas software rendering code will nicely cross-compile to
any target.

So indeed, maybe it’s the platform abstraction layer aspect of SDL
that should have top priority, and anything beyond that should be
dropped if the effort/usefulness ratio is too bad…?

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

50

(I’ve been down with the flu for the past list, so I’m just catching up
on this discussion now.)

Which is precisely what I’m “bitching” about:

PATCHES ARE NOT WANTED.

I still think the RenderGeometry patch is worth adding, but it needs
some work. It’s not just the software renderer part. I believe the
necessary work will get done eventually, maybe even by me, although not
for 2.0.4. But I do want to see this API make its way into SDL2 sooner
or later.

This is worth noting, though: my experience with open source is that
lots of patches get rejected. Some of them are "this needs more work"
and some are "this isn’t something we’re interested in,"
and–crucially–some are “this is a serious piece of work and I need to
find time to wrestle with this.” Even perfect changes, if large
enough, or making API changes, tend to be overwhelming to maintainers.
Because the one fixing the software texture mapper later is almost never
the person that wrote the patch, it’s me.

Sik is having to fight tooth and nail to get accessibility support to
even be accepted as a concept because “it doesn’t belong in SDL”,
despite the established fact that it cannot be done anywhere else. To
listen to this mailing list, absolutely NOTHING belongs in SDL,
including some of the stuff that’s already there.

Well, the mailing list has as many opinions as it has subscriptions.

That is a blessing and a curse. Since it works like that, I wouldn’t
expect you to go out and sell everyone on your idea. In many cases, you
don’t have to sell anyone, either.

It’s been a crazy year for me for many reasons, and a lot of these sort
of things haven’t been on my radar as well as they should be: I honestly
have no idea what the status of Sik’s patch is.

Sik: let’s correct that. Can you get me up to speed? (even just give me
the bugzilla link? I should know already, but I don’t.)

Somebody else can fix the joystick mapping thing I guess, or it will
stay unfixed. My solution (for which I have had code for a year BTW)
got caught up in “breaks compatibility”.

I didn’t realize code was written; last I heard, a long time ago, it was
still a basic proposal. I’m still interested in talking about this if
you still have it. Adding features to the game controller config string
is a TODO list item for me, so I’d like to see where it was left.

–ryan.

51

I don’t know that much about Ryan

I have a daughter that turns three on the 31st. :slight_smile:

–ryan.

52

It was left at “get a consensus about the best way to handle it”. One wasn’t happening, so I wrote code in the hopes that a working example was more useful than endless blather about what wasn’t possible.

I lost a couple of things last October including the diff file and part of the source tree which implemented that (and a couple of other things), but I can extract the appropriate bits from it. The implementation wasn’t hard, but it does feel kind of inefficient to me.

JosephSent via mobile

On Jan 23, 2015, at 19:25, Ryan C. Gordon wrote:

(I’ve been down with the flu for the past list, so I’m just catching up on this discussion now.)

Which is precisely what I’m “bitching” about:

PATCHES ARE NOT WANTED.

I still think the RenderGeometry patch is worth adding, but it needs some work. It’s not just the software renderer part. I believe the necessary work will get done eventually, maybe even by me, although not for 2.0.4. But I do want to see this API make its way into SDL2 sooner or later.

This is worth noting, though: my experience with open source is that lots of patches get rejected. Some of them are “this needs more work” and some are “this isn’t something we’re interested in,” and–crucially–some are “this is a serious piece of work and I need to find time to wrestle with this.” Even perfect changes, if large enough, or making API changes, tend to be overwhelming to maintainers. Because the one fixing the software texture mapper later is almost never the person that wrote the patch, it’s me.

Sik is having to fight tooth and nail to get accessibility support to
even be accepted as a concept because “it doesn’t belong in SDL”,
despite the established fact that it cannot be done anywhere else. To
listen to this mailing list, absolutely NOTHING belongs in SDL,
including some of the stuff that’s already there.

Well, the mailing list has as many opinions as it has subscriptions.

That is a blessing and a curse. Since it works like that, I wouldn’t expect you to go out and sell everyone on your idea. In many cases, you don’t have to sell anyone, either.

It’s been a crazy year for me for many reasons, and a lot of these sort of things haven’t been on my radar as well as they should be: I honestly have no idea what the status of Sik’s patch is.

Sik: let’s correct that. Can you get me up to speed? (even just give me the bugzilla link? I should know already, but I don’t.)

Somebody else can fix the joystick mapping thing I guess, or it will
stay unfixed. My solution (for which I have had code for a year BTW)
got caught up in “breaks compatibility”.

I didn’t realize code was written; last I heard, a long time ago, it was still a basic proposal. I’m still interested in talking about this if you still have it. Adding features to the game controller config string is a TODO list item for me, so I’d like to see where it was left.

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

53

2015-01-24 0:25 GMT-03:00, Ryan C. Gordon :

It’s been a crazy year for me for many reasons, and a lot of these sort
of things haven’t been on my radar as well as they should be: I honestly
have no idea what the status of Sik’s patch is.

Sik: let’s correct that. Can you get me up to speed? (even just give me
the bugzilla link? I should know already, but I don’t.)

Didn’t get time around it yet, I said I was gonna do one a couple of
days ago but I was busy dealing with some HTML problem (incidentally
related). The thread is “Outputting text to accessibility tools” if
you want to look into it, though.

The gist of the thing is this: I was looking around to do screen
reader support and realize it’d be easier to just implement it in SDL,
especially since to do it I need to run code from within the window
procedure (in the case of Windows). So I propose the idea and also ask
for information on what other requirements may be there for other
platforms to take into account. Shortly after the thread devolves into
an argument that it shouldn’t be added to SDL and should be made a
separate library (despite what I said about the window procedure
thing), which eventually itself devolved into this thread getting
created in response. I think you can guess where it’s going…

Now things have calmed down over there so I can proceed to start
writing some code, but I think it shows the issues whenever something
new is proposed for SDL.

54

Hi Sik!

Just letting you know that I haven’t forgotten, err I’m still planning on spending some time here soon at looking at accessibility options / API on the OS X front. I’m hoping that after a short preliminary peek at the sample code I have stashed away, I could help start considering the real challenge with you; SDL2’s side of things with the API internals. I’m excited to delve into it.

I’m more or less at the end of the sub-project I’ve been working on, and now just adding last-minute polish and house cleaning up now. mumbles I was crazy enough to do extensive unit testing on an animation action engine, and it has cost me an enormous amount of time upfront… better now than later, though :stuck_out_tongue:

Cheers,
Jeffrey Carpenter <@Jeffrey_Carpenter>

-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1572 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20150124/8978ddc8/attachment.bin

55

2015-01-24 21:25 GMT-03:00, Jeffrey Carpenter :

Hi Sik!

Just letting you know that I haven’t forgotten, err I’m still planning on
spending some time here soon at looking at accessibility options / API on
the OS X front. I’m hoping that after a short preliminary peek at the sample
code I have stashed away, I could help start considering the real challenge
with you; SDL2’s side of things with the API internals. I’m excited to delve
into it.

This probably belongs in the other thread ^^;

Yesterday I got some speech-dispatcher code up quickly, although I
think I’m going to rewrite it to account for windows from the get-go.
In any case the code is simpler than what I had in my original
implementation.

My biggest issue will be dealing with the SDL internals since honestly
I have absolutely no idea about it (I have the feeling somebody else
will have to cope with that). There’s a reason why I’m making a
"mock-up" rather than a proper patch.