Hi, Leonard, If you're talking HW textures (which require a hardware display context), one can have multiple renderers; and it can be beneficial to do so. The renderer determines blend mode and other aspects. It could be more manageable and preferable to have a renderer for every occasion, so to speak.
Textures are not very compatible with the surface paradigm. It would behoove us to examine these side by side, and figure out a way to foster both. Surface code will likely just drop in if you keep the same API, but working with textures is a departure from the surface workflow. We do not want to try and make textures behave like surfaces, or vice versa. E.g. one does not blit a texture, and one does not flip the screen buffer. It requires one to be cognizant of what data structure one is dealing with. IMO, support for textures should not be an afterthought. They are a premiere feature of SDL2, and will likely be appreciated and preferred as people delve into them. You folks are probably already realizing this at least a little bit. If so, then good. :) Respectfully, Gumm On Sun, Apr 16, 2017 at 11:01 PM, Lenard Lindstrom <le...@telus.net> wrote: > 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 > > >
