Thanks for the link. I had not even thought of OpenGL yet. OpenGL was
something to be tackled later.
One thing to note though, a programming choice in C may not make sense
in a higher level language such as Python. C encourages choices based on
physical data representations. Python types and objects allow for
abstractions independent of physical representation. So Classes can be
designed around what you want to do, not what you are actually working
on. Too me, if there was a strict one-to-one relation between a window
and a renderer, then why not have an object that can be both a renderer
and a window.
But yes, if a separate Window and Renderer is more intuitive to most
people, then that is the way to go. Anyway, the complicated, and unclear
to me, window/renderer relationship makes a combined object a
questionable choice.
Lenard Lindstrom
On 17-04-19 10:54 PM, Leif Theden wrote:
While I have not personally tested it, there seems to be more evidence
that windows can contain (use? manage?) more than one Renderer:
https://forums.libsdl.org/viewtopic.php?t=10187&postdays=0&postorder=asc&start=15&sid=3fe959dc04bb7cd484c3ee453df8f5de
I'll just stop the back-and-forth and say that I don't support
RendererWindow, but I support separate Window and Renderer objects.
On Wed, Apr 19, 2017 at 11:12 PM, Lenard Lindstrom <le...@telus.net
<mailto:le...@telus.net>> wrote:
Hello,
On 17-04-19 04:26 PM, Leif Theden wrote:
While I can understand why you wouldn't like the create_XXXX
syntax, I'm not convinced that combining the window and the
renderer makes sense for the API. As was mentioned, a window
can have multiple renderers (or none at all!), so I'm not sure
what combining them together grants for pygame users.
No, a window can have only one renderer at a time. And a renderer
will have only one window in its lifetime.
However, after a bit of experimenting I find a window can have
both a renderer and a display surface. This does support a
separate window object. Whether or not it is useful, I don't know.
Anyway, I am still getting a handle on SDL 2, so don't favor any
particular approach yet.
Lenard Lindstrom