Reopening Project #88
Comments
|
I wouldn't mind spending some time on the project. Maybe I will have some time this spring to look into it. I've only worked with one other cython library, kivy, and it is a nightmare to get a build environment going. Does this require a special cython version? |
|
I intend it to work with the latest cython. |
|
I still think this is the best pygame like for SDL2, because it seems that pygame will never evolve. But I did not have much time to use and learn your code at the time. |
|
I don't think you'd have to learn how the existing modules work to add some of the new ones. And I'd love it if someone could help with things like testing. |
|
May I suggest testing on target hardware as you continue? I have four Android devices from 4.0 to 7.0 and the performance is not very good. As in very slow graphics. It does work on all, unlike pgs4a which doesn't support 7, but the performance is less that optimal. I am going to have to switch to Android Studio and Java and essentially throw out a years worth of code. Which is unfortunate. |
@martan3d Any modern SDL2 app will have to abandon the "blit" based API and use the new "Renderer" API, which is based on hardware-accelerated graphics. This is not a problem unique to pygame_sdl2, any game/application using SDL 1/2 has to make the changes; pygame_sdl2 apps are not exempt. The SDL team removed code which made software blitting somewhat fast. Adding it back in would be a non-trivial undertaking. See #36 for some discussion.
As a community (really just one person!) developed project, its not really possible to test a huge range of devices. A repository of testing results would be nice. Care to put your data on the wiki to get something started? https://wiki.libsdl.org/MigrationGuide#Setting_up_a_game_with_the_new_video_API TLDR; you need to update your projects to properly use the new graphics capabilities of SDL2. Hope that helps! |
|
I'm currently tinkering with pygame_sdl2 on windows as a possibility for supporting an isometric game. I'm very familiar with pygame as I use it for teaching a programming class. I'd love it if this library could become actively developed again as a sort of pygame+. From a windows developer perspective the current basic user frustrations are:
If we could clear up those issues then it would immediately be a lot more attractive for end users on windows to get started. Might even make it feasible to use in schools. After that there are a couple of areas I can think to focus on for specific improvements:
|
|
I should also mention, a probably related issue, which is making it possible to package pygame_sdl2 projects with pyinstaller. So far I've found pyinstaller the most user friendly python distribution tool and it works with pygame and pyglet projects on windows but dies a death with pygame_sdl2. As I mentioned I suspect this is tied to the general issues with packaging up and installing pygame_sdl2. As to why I care, with my quick hacks in place and the general benefits of SDL2 there is big boost to framerate from using pygame_sdl2. Here's my proto-type scrolling isometric rendering in vanilla pygame: And here it is using pygame_sdl2: Which is nearly eight times faster. |
|
renpytom, can you say a few more words (or point me to a post, if there is one) regarding your initial statement:
I take from this you proposed SDL2 as the path forward for pygame, and the "powers in charge" whomever they are, declined. Is there any indication that others pathways to SDL2 are being considered? Or is their position that SDL1 is "good enough" so why bother with the significant graphical speed improvements that SLD2 offers? I'm just curious what the future for pygame holds. |
|
I think everyone wants to see pygame support SDL2. I suggested that the existing pygame library should go into 'maintenance mode', and bless pygame_sdl2 as the successor using SDL2. But the people that do the work on pygame preferred to port the existing codebase to SDL 2. I don't think there was ever an explicit rejection of pygame_sdl2, but the main pygame developers didn't really engage with the 'successor' idea. You can find the discussion here: pygame/pygame#174 My feeling is that Pygame has chronic overambition: the plans for where it's going always seem to need far more developer time than the project has. But I was pleasantly surprised to discover that there is an active branch with work to support SDL 2: |
|
I feel like pygame_sdl2 needs a more visible place to discuss the goals and direction of the project and how to get there from where it is now. Personally I'd like to see (some mentioned up-thread already):
|
|
To some extent, we don't need discussion - we need commitment. There are plenty of things to be done, but I'm not just going to accept a drive by list of "You should do ____", without people willing to step up and actually do some of the work here. Pygame_SDL2 scratches my itch - it's served as a reasonable basis for porting Ren'Py to SDL2, including the iOS and Android platforms. It's enabled about a thousand games to be made, at this point, with one played 3 million times. But there are a few things that I wasn't able to do - the *array modules, and the test suite. Nobody stepped up to do them, so why bother. If people are willing to step up and add the things they want, I'll do my part and merge them, or add people to the project so you can commit them yourself. But at this point, when Ren'Py is the only project using pygame_sdl2, and we get drive-by people who ask for features without giving back, it's hard to be bothered. I don't think Ren'Py's Text support could be dropped in directly, though some of it might make sense to merge. I'd also be interested in contributing the new uguu (Unified GL Wrapper) stuff here, to support GL/GLES/ANGLE, but again, would have to see people contributing to bother. |
|
Well I do have a couple of pull requests sitting in the queue :) I wasn't
sure whether those were accepted/appreciated or not so I thought I'd pause
at three before going on.
I can definitely try to fix up the text stuff I've done over the summer (my
schedule as an invigilator/instructor is a bit bound to the school term) as
a starting point for others to critique and improve upon. I also saw a list
posted over on the pygame repo a while ago of the 'missing modules' in
pygame_sdl2 would be happy to attempt one of those at random too. Perhaps
mask since it seems to come up a lot in the issues.
I believe there is also at least one other non-renpy game on steam using
pygame_sdl2:
https://store.steampowered.com/app/442210/
…On Mon, May 7, 2018 at 6:41 PM, Tom Rothamel ***@***.***> wrote:
To some extent, we don't need discussion - we need commitment. There are
plenty of things to be done, but I'm not just going to accept a drive by
list of "You should do ____", without people willing to step up and
actually do some of the work here.
Pygame_SDL2 scratches my itch - it's served as a reasonable basis for
porting Ren'Py to SDL2, including the iOS and Android platforms. It's
enabled about a thousand games to be made, at this point, with one played 3
million times.
But there are a few things that I wasn't able to do - the *array modules,
and the test suite. Nobody stepped up to do them, so why bother. If people
are willing to step up and add the things they want, I'll do my part and
merge them, or add people to the project so you can commit them yourself.
But at this point, when Ren'Py is the only project using pygame_sdl2, and
we get drive-by people who ask for features without giving back, it's hard
to be bothered.
I don't think Ren'Py's Text support could be dropped in directly, though
some of it might make sense to merge. I'd also be interested in
contributing the new uguu (Unified GL Wrapper) stuff here, to support
GL/GLES/ANGLE, but again, would have to see people contributing to bother.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#88 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMwzGotVwQBoQ6FdL5f2vKvrvNMYPVuEks5twIdhgaJpZM4R2caj>
.
|
|
Some people asked about pygame and SDL2 here. I asked @renpytom again about contributing back to pygame and joining forces for great win... #109 (comment) but there is still no interest on @renpytom 's side. So, I wish renpytom and this project luck, and will continue to cheer it on and support renpy from the sidelines. Where is pygame and SDL2 at? The SDL2 branch has been merged into the main pygame branch now. So building from source works, and many-many games also work. Things like the pygame test suite took multiple person years of really hard effort, as did the packaging work. And pygame is around 18 years old now... so all those little bits of polish would take a long time to re-implement. It's not surprising people don't step forward to do this type of hard 'boring' work. SDL1 is still useful to some of us, so the 1.9.5+ series will be done with SDL1, and the pygame 2.0.0 series is to be released with SDL2 as default. Backwards compatibility is important, so our aim is still to be mostly backwards compatible with SDL1 and existing pygame games(plus the 87 books, university and online video courses, and various websites out there). Given the current state of pygame_sdl2 development vs pygame development; I think we made the best choice - for most of pygame users, the python community and us. Our internal API had a massive cleanup, we've removed lots of cruft from the repo, and the developer guide is getting better. Our community feels like a community again - not a silent irc channel where no one responds. The new open source website is getting more submissions and traffic than ever before(even though it still needs lots of work). After the move to github (at the request of renpytom), our PRs from external people are merged quickly. and we have made outreach to our external maintainers (like the pygame Debian maintainer who is awesome, and the Raspberry pi folks) and people from projects like pypy who helped with getting pygame running on pypy. The next big step is moving under the Python Software Foundation, which will help pygame in a number of ways including legally and financially. That's all I'll say here about pygame now (there is a Ludumdare about to start after all!). I'll leave you with an old quote from the year 2000: Ciao for now, |
|
Now that pygame 2 is about to come out with SDL2, what will happen to this project? |
|
My plan is to keep it as a dependency of Ren'Py. I realized that I basically don't have the energy to support pygame - which has almost two decades of work in its own right - as well as my primary project. If people want to use it for mobile ports or something like that, great, but for the desktop I think the new version of pygame might be the better option. Pygame looks a lot healthier now than it had been, so there's less of a need for a rewrite to replace it than there was, say, 3 years ago. |
Honestly, after this was rejected as the future of Pygame, I've just been working on pygame_sdl2 to support Ren'Py. Do people want me to add them to the project and start merging PRs so that this is useful for other games?
The text was updated successfully, but these errors were encountered: