[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Pygame for SDL 2, and how it may look.

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'):
raise ICannotDoThatDaveError # legacy group will not render a texture sprite 


# TextureSpriteGroup.draw
for sprite in self._hw_sprites:
renderer.render_copy_ex(sprite.tex,
None,
sprite.rect,
sprite.rotation,
sprite.origin,
sprite.flipped)
The group module should become simplified. Choose a group type that works well for software sprites, and develop a new one for Renderers. Add some checks to legacy groups to prevent Sprites with textures from being added. 

==============================================================

# pygame.display will be an alias for a Window


pygame.init()
window = pygame.display.get_window(0) # return instance of created window 

>>> window is pygame.display
True


==============================================================
# Consider the following

  * When a renderer is created for a window, the window will raise an
    exception if a blit or draw is attempted on it.
  * All windows are py1 until a renderer is created on it.
  * Once renderer is created, leave window in renderer mode. (or not?)
  * Blits between software surfaces will always work, regardless of
    the window mode.

screen = pg.display.set_mode(...)  # automatic py1 window
screen.blit(legacy_cruft) # works!
renderer = pg.display.create_renderer() # works b/c display is alias to first window renderer = pg.renderer.Renderer() # implicit 1st window as target of renderer 

screen.blit(oops) # raise ThouShaltNotBlitError
pg.draw.lines(screen, ...) # raise ThouShaltNotDrawUponThyScreenError 

==============================================================
There is no way forward to give old pygame apps free performance. New pygame apps will need to choose to use the accelerated graphics API, or not.