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

Re: [pygame] Re: pygame with SDL2 proposal

Hi Ian,
I think people are hung up on option 2), SDL1/SDL2 compile option, thinking it means no SDL2 features, or no option 3), transition to SDL2 only. First, I gather René's proposal to keep Pygame development on a single branch is not about freezing the Pygame at SDL1 only functionality. Rather it is about logistics: How do we continue to distribute Pygame while updating the automated building systems for SDL2? How do we avoid breaking every Pygame program that has been written up to now?
I won't argue whether be kept as one branch or split into two. But I don't think creating an SDL1/SDL2 compiler switch will be overly difficult. It will also encourage keeping SDL1 support alive while SDL2 development proceeds.
Next issue, backwards compatibility. The SDL1/SDL2 compiler switch is just the starting point. It is the foundation upon which new, SDL2 specific code is written. Pygame has become more than a thin wrapper over SDL. It should be quicker to add a few new classes to support the window/texture/renderer framework of GPL acceleration than to start from scratch. Meanwhile Pygame maintains the display surface/blit interface, which is also supported in SDL2, for backward compatibility.
Much of the work in adapting Pygame to SDL2 has been done. This will reduce the time taken until coding for new SDL2 features begins. Using Cython will reduce coding time further, and hopefully allow more people to participate. All in all I believe this incremental approach will give quicker, more solid, results than writing a new package from scratch.
Finally, I threw together a code example of how I envision Pygame 2 (taken from http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world): 

# Simple Pygame 2 example using a window, renderer, and texture.

import pygame as pg

pg.display.init()
win = pg.display.Window("Hello World!", (100, 100, 640, 480), pg.WINDOW_SHOWN) 
ren = win.renderer(-1, pg.RENDERER_ACCELERATED | pg.RENDERER_PRESENTVSYNC)
bmp = pg.image.load("hello.bmp")
tex = ren.texture(bmp)

for i in range(3):
    ren.clear()
    tex.copy_to_renderer()
    ren.present()
    pg.time.delay(1000)

pg.quit()
Notice that surfaces, as returned by image.load(), still exist. Also, pygame.display.Window is an addition. Module pygame.display functions set_mode(), flip() and, update() remain and work as expected. 

Lenard Lindstrom


On 17-03-21 10:31 AM, Ian Mallett wrote:

​​Hi,
On Mon, Mar 20, 2017 at 11:55 PM, René Dudfield <renesd@xxxxxxxxx <mailto:renesd@xxxxxxxxx>> wrote: 

    There are few people on this mailing list which have a lot of
    knowledge about GPU rendering, and Ian is definitely one of them.
    I think he was genuinely trying to be helpful. His claim isn't
    even controversial - GPU, ASIC, and CPU rendering all have
    different trade offs. As do game libraries like pygame.
On Mon, Mar 20, 2017 at 5:18 PM, Leif Theden <leif.theden@xxxxxxxxx <mailto:leif.theden@xxxxxxxxx>> wrote: 

    Ian, you are really trying to make the case that a software
    renderer making simple shapes around the on the screen is better
    than a GPU?  Why then are basically all games these days using a
    GPU?  Please, don't answer it, because I'm not sure if you are
    trolling or not, and don't want to risk derailing the tread with
    this...honestly quite ludicrous assertion you've made.  The proof
    is in the pudding, so to speak, and the pudding is certainly not
    software rendering anything.
Thanks René! And to clarify: (1) Leif, the answers to your objections are in that wall of text, which is of course why I wrote it. (2) I do not troll. (3) You're right that if hardware acceleration is off the table, then this conversation is orthogonal here. But, it's unclear to me if it /is/ off the table.
At the risk of over-simplification, but in the interest of moving the conversation forward, let's try to put the current issues in context. As I understand it, the proposals vis-à-vis SDL2 are: 

    1: Do nothing

    2: (Progressively) integrate SDL2 patch into existing pygame with
    goal of eventual SDL1/SDL2 compile option (René and Lenard OP,
    many detailed variations)

    3: Transition (as above or rewrite) to use SDL2 only (various)
. . . any of which implemented with the following options, which are not necessarily mutually incompatible: 

    A: Share/relicense pygame_sdl2
    B: Expose a different API designed for performance (for graphics
    especially)
    C: Base largely on hardware acceleration for performance

    D: Expose new SDL2 features in the pygame API
​. . . and under the following serious constraint, which I think is accurate:​ On Tue, Mar 21, 2017 at 6:27 AM, Leif Theden <leif.theden@xxxxxxxxx <mailto:leif.theden@xxxxxxxxx>> wrote: 

    Let's be realistic, there are very few people who have the will or
    ability to deal with the pygame code base
    ​​
I'll keep my opinion short: personally, I'm okay with any proposal, 1, 2, or 3, though I'd pick 3 over 2, despite being a bit dangerous. At the same time, I think option B implies we want to leave our niche (which I'm vaguely against) and option C is implausible (again, for our niche). Saving work is preferable, but otherwise I don't know enough to say anything about A. I support D. 

Ian