Hi Ian,
Thanks for replying.
On 17-04-16 01:43 AM, Ian Mallett wrote:
On Thu, Apr 13, 2017 at 3:25 PM, Lenard Lindstrom <le...@telus.net
<mailto:le...@telus.net>> wrote:
"""Render an image to a window
This is adapted from the SDL 2 example at
<http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world
<http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world>>.
"""
Heh, I'm friends with Will. We're at the same university.
import pygame
from pygame.display import RendererWindow
import os
def get_resource_path():
my_dir = os.path.dirname(os.path.abspath(__file__))
return os.path.join(my_dir, 'data')
def run():
pygame.display.init()
title = "Hello World!"
rect = (100, 100, 640, 480)
flags = RendererWindow.SHOWN
with RendererWindow(title, rect, flags) as win:
ren = win.renderer
flags = (ren.ACCELERATED |
ren.PRESENTVSYNC )
ren.open(flags)
image_path = os.path.join(get_resource_path(), 'hello.bmp')
bmp = pygame.image.load(image_path)
tex = ren.new_texture_from_surface(bmp)
for i in range(3):
ren.clear()
tex.copy_to_renderer()
ren.update()
pygame.time.delay(1000)
pygame.quit()
if __name__ == '__main__':
run()
A window with renderer and a window with surface are implemented
as distinct subclasses of a standard Window extension type. Each
Window instance is an open window on the display. Window updates
are perform by methods on the corresponding renderer or surface.
Window and renderer specific constants, such as SDL_WINDOW_SHOWN
and SDL_RENDERER_ACCELERATED are class attributes, though they
could also be included in pygame.locals.
This is preliminary design work, so feedback is not only welcome
but also necessary.
Is it possible to combine the renderer with the window? I don't see
why the renderer needs to be pulled out of the pygame.draw module, and
indeed, this could be confusing for existing code.
I don't quite understand. The renderer associated with the
RendererWindow instance is returned by the window's renderer property.
Why are the window and the renderer separate objects? There is a
one-to-one relation between a window and its renderer or a display
surface. And a window cannot have both. To avoid duplicating a bunch of
window specific methods I created a Window class, with RendererWindow
and SurfaceWindow (not shown) as subclasses. Also, a surface can have a
renderer, and a combined surface-renderer object makes no sense. Still,
I haven't ruled out renderer-window and surface-window types yet.
However it is done, I don't see an elegant representation of the
relationships among SDL windows, surfaces, renders, and textures.
For maximum backcompatibility, something like the following would seem
to fit better with the existing API:
surf1 = pygame.display.Window(rect1,flags)
surf2 = pygame.display.Window(rect2,flags)
#...
surf1.blit(...)
surf2.blit(...)
#...
pygame.display.flip()
I don't recall what was decided about the feasibility of implementing
SDL2-style or hardware-accelerated rendering, but I'd hazard that this
sort of API wouldn't map well to it. OTOH, I don't think the decision
to implement a modern graphics interface was decided in the first
place (just that we're currently adding some SDL2 stuff).
The user can choose either a renderer or a display surface for a window.
And pixels can be copied between textures and surfaces. So hardware
accelerated rendering is available, as shown in the example.
As for set_mode(), flip(), and update(), they remain in Pygame SDL 2.
Keeping as much of the Pygame SDL 1 API in Pygame SDL 2 is a priority.
This example explores how new SDL 2 specific capabilities can be added
to Pygame. It uses a Python feature unavailable when Pygame was created,
the new-style class.
It's worth noting that switching the graphics context between windows
(to do hardware draws) isn't free, and simple code (that e.g. draws a
bunch of things on two windows, switching every draw call for code
clarity) might not run very well. Perhaps the API should discourage
this somehow, especially if full HW drawing is encouraged.
Again I don't understand. Given a window, its renderer, and a bunch of
textures: render the textures to various locations on the window, update
(expose) the renderer, then repeat. How is this not hardware drawing.
What am I missing?
SDL 2 supports multiple open windows. Pygame will too. Let the designer
choose how many windows are open, and if hardware acceleration is
appropriate. Not all Pygame applications need be fast-paced games.
Lenard Lindstrom
