Re: [pygame] Pygame for SDL 2, and how it may look.
Hi, I dug around in the SDL 2 source (mostly "src/render/*"). As I suspected, for hardware renderers, a renderer is essentially a graphics context. This means that: 1: A renderer is more-or-less decoupled from a window. Each window can be bound to up to one renderer, and each renderer can be bound to up to one window. 2: There can be many renderers and many windows. On Thu, Apr 20, 2017 at 12:30 AM, Greg Ewing wrote: > If that's true, then it might make sense for the Renderer to have > a 'window' attribute. The Renderer would then be the thing you > keep a long-term reference to, and you would obtain the Window > from it when needed. I like this idea a lot, modulo that you should also store the reference to the window. If draws are done through the renderer, then to change the window, you need to change the renderer's pointer. This makes the problem I described a few days ago less hidden to the user. Exposing things in this way feels somehow "right" to me. Ian
Re: [pygame] Pygame for SDL 2, and how it may look.
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: If that's true, then it might make sense for the Renderer to have a 'window' attribute. The Renderer would then be the thing you keep a long-term reference to, and you would obtain the Window from it when needed. -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
Lenard Lindstrom wrote: However, after a bit of experimenting I find a window can have both a renderer and a display surface. In that case, I'd suggest the Window object should have 'renderer' and 'surface' attributes. If the Renderer or Surface keeps a reference back to the window, it should probably be a weak reference, so that they won't keep each other alive. If code that uses the Renderer or Surface obtains it from the Window when needed and doesn't store a reference to it long-term, then dropping the Window will cause the whole lot to disappear. -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
Lenard Lindstrom wrote: Extension type WindowSurface would add an SDL window C pointer to its pygame.Surface parent. This window pointer cannot be factored out into a separate WindowBase parent class. And any methods which access that pointer will be specific to WindowSurface's C structure type. And consequently, it would be impossible to write code that generically works with either type of window at the C level without going through Python method or property dispatch. * Cython has an include statement. Unfortunately, include statements are not allowed in class declarations. Even if it worked, the effect would be no different from writing out a copy of the code in each class. You would still have two unrelated sets of fields with different offsets. Splitting it into two objects sounds like the best solution to me. Then you can have a Window object with the same interface whether it has a Renderer or a Surface attached, and a Renderer with the same interface whether it's attached to a Window or something else. -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
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 wrote: > Hello, > > On 17-04-19 04:26 PM, Leif Theden wrote: > >> While I can understand why you wouldn't like the create_ 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 > >
Re: [pygame] https://pygame.org/
@DiliupG: Couldn't you use any networking library for that?
Re: [pygame] https://pygame.org/
python/pygame game client/server info https://www.raywenderlich.com/46843/multiplayer-game-programming-for-teens-with-python-part-2 On 20 April 2017 at 10:20, DiliupG wrote: > GENTLEMEN! (Strange I have NEVER come across ladies here! :) ) > > Python/Pygame playable over the Internet is here.. > https://www.youtube.com/watch?v=EYn2uTJkUSE > > On 19 April 2017 at 12:42, Thomas Kluyver wrote: > >> On 19 April 2017 at 07:28, DiliupG wrote: >> >>> This is a good point for us to pivot in the direction of sdl2 >>> permanently for the sake of the future. Is it really difficult to do that? >>> Rene, Thomas what about it? >> >> >> There's ongoing work on supporting SDL 2 being discussed in another >> thread (though I'm not involved in it, to be clear). Hopefully it won't be >> too difficult, but it's not totally straightforward either. >> >> Thomas >> > > > > -- > Kalasuri Diliup Gabadamudalige > > https://dahamgatalu.wordpress.com/ > http://soft.diliupg.com/ > http://www.diliupg.com > > > ** > This e-mail is confidential. It may also be legally privileged. If you are > not the intended recipient or have received it in error, please delete it > and all copies from your system and notify the sender immediately by return > e-mail. Any unauthorized reading, reproducing, printing or further > dissemination of this e-mail or its contents is strictly prohibited and may > be unlawful. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. The sender does not accept liability for any > errors or omissions. > > ** > > -- Kalasuri Diliup Gabadamudalige https://dahamgatalu.wordpress.com/ http://soft.diliupg.com/ http://www.diliupg.com ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] https://pygame.org/
GENTLEMEN! (Strange I have NEVER come across ladies here! :) ) Python/Pygame playable over the Internet is here.. https://www.youtube.com/watch?v=EYn2uTJkUSE On 19 April 2017 at 12:42, Thomas Kluyver wrote: > On 19 April 2017 at 07:28, DiliupG wrote: > >> This is a good point for us to pivot in the direction of sdl2 permanently >> for the sake of the future. Is it really difficult to do that? >> Rene, Thomas what about it? > > > There's ongoing work on supporting SDL 2 being discussed in another thread > (though I'm not involved in it, to be clear). Hopefully it won't be too > difficult, but it's not totally straightforward either. > > Thomas > -- Kalasuri Diliup Gabadamudalige https://dahamgatalu.wordpress.com/ http://soft.diliupg.com/ http://www.diliupg.com ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Pygame for SDL 2, and how it may look.
Hello, On 17-04-19 04:26 PM, Leif Theden wrote: While I can understand why you wouldn't like the create_ 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
Re: [pygame] Pygame for SDL 2, and how it may look.
Hi, On 17-04-19 03:23 PM, Daniel Foerster wrote: On 04/19/2017 01:16 AM, Lenard Lindstrom wrote: Now I have experimented with separate Window and Renderer. I found a somewhat acceptable solution to the problems mentioned above. But it still felt clunky. Then, when I combined the window and renderer into on class, much of the complexity went away. The only real downside is that the window management code, the window method definitions, will be duplicated in both the WindowRenderer and WindowSurface classes. But then that is just cut and paste, provide one remembers to do it. Why cut and paste when you can factor it out into a WindowBase class? Extension type WindowSurface would add an SDL window C pointer to its pygame.Surface parent. This window pointer cannot be factored out into a separate WindowBase parent class. And any methods which access that pointer will be specific to WindowSurface's C structure type. The Renderer extension type will differ from Surface, so the WindowRenderer subclass will also differ from WindowSurface. What is missing are mixins. I am writing new code in Cython. I believed I had found a way to create a rudimentary mixin, but it failed*. Anyway, I am still trying to make sense of SDL 2, so I may find a functional reason to keep windows and renderers separate in Pygame. * Cython has an include statement. Unfortunately, include statements are not allowed in class declarations. Lenard Lindstrom
Re: [pygame] Pygame for SDL 2, and how it may look.
While I can understand why you wouldn't like the create_ 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. > Does the renderer keep a reference to the Window? Does the Window keep a reference to the renderer? How is a reference cycle prevented? I don't believe that you would need to keep references to a parent window for renderers, or that you would need them for windows. The SDL2 API will take care of those details. (hopefully?) I don't agree that separate renderers and windows should feel clunky. Pygame's API is rife with the pattern of creating objects for something, then setting attributes and using them. Why would it be any different if you create a Renderer? My last point about Windows tracking if they have a renderer or not (and raising exceptions when using the old surface api) was simply a way to allow the pygame API to remain backwards compatible and also use the renderer api, if desiredWithout resorting to different window classes, as your API demo suggests. On Wed, Apr 19, 2017 at 1:16 AM, Lenard Lindstrom wrote: > Hi Leif, > > On 17-04-18 09:10 AM, Leif Theden wrote: > >> The renderer should have its own class, and for simplicity, I think it >> should be instanced by calling a method on the window that contains it. >> Just preference. >> >> Having both a Window and a Renderer class makes sense if renderers are > cheap to create and discard. For practical purposes, a window's renderer > will live as long as it's window. If a Window class has a create_renderer() > method, then what happens when it is called more then once. Also, what > happens to the renderer instance when the window is closed. Does the > renderer keep a reference to the Window? Does the Window keep a reference > to the renderer? How is a reference cycle prevented? > > To complicate matters, a window can have a display surface instead of a > renderer. So we add a create_surface() method. Now the Window class must > track whether it has a renderer or a surface. And a Pygame Surface does not > know about windows. So if we want the Surface instance to reference a > window we need a new WindowSurface subclass. > > My thinking is if we need a WindowSurface to reference a window, then it > can directly manage the SDL window as well. The same goes for a > WindowRenderer Renderer subclass. Everything relating to a particular > window is in one convenient place. And when the window is closed, there is > only one, not two, dead objects lying around. > > Now I have experimented with separate Window and Renderer. I found a > somewhat acceptable solution to the problems mentioned above. But it still > felt clunky. Then, when I combined the window and renderer into on class, > much of the complexity went away. The only real downside is that the window > management code, the window method definitions, will be duplicated in both > the WindowRenderer and WindowSurface classes. But then that is just cut and > paste, provide one remembers to do it. > > Lenard Lindstrom > > Renderer does not below with the draw module, because it is not for >> drawing lines, and primitives on software surface. It is a cross-platform >> and simple API for high-speed accelerated graphics with textures and >> includes some facilities for drawing primitives. >> >> == >> What about something like this? >> >> >> import pygame as pg >> >> window = pg.display.new_window()# new Window class method >> screen = pg.display.set_mode(...) # creates a new window, return >> surface >> >> renderer = window.create_renderer() # renderer, yay! >> renderer = pg.renderer.Renderer(window) # alternative. "window" optional >> >> >> surf = pg.image.load(filename) >> texture = renderer.create_texture(surface=surf) # clean syntax? >> texture = pg.texture.from_surface(surface, renderer) # alternative, >> "renderer" optional >> >> >> while running: >> renderer.clear()# you should do this each frame >> >>for tex, rect in textures: >> renderer.render_copy(tex, rect) # this is analogous to "blit", but >> is HW accel'd >> >> renderer.present() # like display.flip() >> >> >> == >> # texture sprites >> >> sprite = pg.sprite.TextureSprite() >> sprite.texture = tex >> sprite.rect = text.get_rect() >> sprite.origin = 0, 0 # where the origin of texture is >> sprite.rotation = 76 # rotation of the sprite >> >> group = renderer.create_group(all_the_sprites, flags=0xDEADBEEF) # clean? >> group = pg.sprite.TextureSpriteGroup(renderer) # alternative >> >> == >> # sample of a SpriteGroup >> # Group.add >> >> if hasattr(sprite, 'texture'):
Re: [pygame] Pygame for SDL 2, and how it may look.
On 04/19/2017 01:16 AM, Lenard Lindstrom wrote: Now I have experimented with separate Window and Renderer. I found a somewhat acceptable solution to the problems mentioned above. But it still felt clunky. Then, when I combined the window and renderer into on class, much of the complexity went away. The only real downside is that the window management code, the window method definitions, will be duplicated in both the WindowRenderer and WindowSurface classes. But then that is just cut and paste, provide one remembers to do it. Why cut and paste when you can factor it out into a WindowBase class?
Re: [pygame] https://pygame.org/
On 19 April 2017 at 07:28, DiliupG wrote: > This is a good point for us to pivot in the direction of sdl2 permanently > for the sake of the future. Is it really difficult to do that? > Rene, Thomas what about it? There's ongoing work on supporting SDL 2 being discussed in another thread (though I'm not involved in it, to be clear). Hopefully it won't be too difficult, but it's not totally straightforward either. Thomas
