Hi Gumm,
Renderers and textures will be a part of Pygame. They will be new
features rather than disguised as blits to a display surface. SDL 2
supports display surface as well, so Pygame will continue to do so as
well. My intention is add all this, plus multi-window support, with the
addition of new classes to what already exists in Pygame.
An SDL Window can have only one rendering context, or renderer. Now a
renderer can have multiple textures, with render mode a per-texture
feature. All that will be supported.
Lenard Lindstrom
On 17-04-17 04:17 PM, B W wrote:
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. :)
