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 <ren...@gmail.com
<mailto:ren...@gmail.com>> 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.the...@gmail.com
<mailto:leif.the...@gmail.com>> 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.the...@gmail.com
<mailto:leif.the...@gmail.com>> 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
