Re: [pygame] pygame with SDL2 proposal
I'll be honest and say I really haven't had any time to improve the features of pygame_sdl2 that aren't used by Ren'Py. It's hard enough to support one large project, and I just don't think I have another one in me at this time. I'd love to work with anyone who wants to bring pygame_sdl2 to parity with pygame, or to share/relicense any code that people want to move to other projects. (This could also include stuff distributed with Ren'Py at the moment, like Steam or IAP support.) Assuming that nobody wants to take this up as a project, I'll probably rename pygame_sdl2 to something else, so as not to overly confuse people on what it's about. I'd suggest there are three things a future pygame needs to focus on: 1) Mobile support - I think any game development platform that doesn't support mobile devices is just going to get increasingly marginalized. 2) Providing access to modern graphics APIs, like OpenGL/OpenGL ES/Vulkan/DirectX - perhaps via something like ANGLE, and then supporting the rest of the stuff required to make a game around them - opening windows, loading images, audio, haptics, etc. 3) I would suspect that a non-backwards-compatible pygame would be poorly received if it keeps the same name and breaks the existing code. It would require any book mentioning pygame to be rewritten - and is it likely anyone would do that rather than try to teach people some other API/language? But this is all backseat driving, since I really am kind of full up, schedule-wise. That being said, when evaluating SDL2 migration requirements, it's probably a good idea to first decide what the actual needs are. On Sun, Mar 19, 2017 at 6:46 PM Leif Theden wrote: > I think that rewriting the extension modules in cython would be a great > way to make the project accessible to new developers. > > Writing extensions in C, as it is now, requires that developers have 1. > Good C skills, 2. Understanding of the Python C library, 3. Knowledge of > the SDL library, 4. Understanding of low-level details about the platforms > it supports, and finally, 5. a good sense of how pygame works. > > If you can imagine those skills charted as a Venn diagram, it's not > difficult to understand why it is hard to maintain pygame as is, because > only a handful of people have those skills and actually care. > > Cython is not difficult to learn and looks like Python. It would be less > of a barrier of entry for new developers to contribute. > > Also, let's not forget that C in general is losing mindshare, as new > developers tend to learn JS, java, and Python for their classes. > > At that point however, Toms python_sdl2 is already doing that so, where > does that leave pygame2? > > If cython is chosen, better to let pygame 1.9 die gracefully and move on > to a better platform and not duplicate effort (by moving to python_sdl2). > > Good night, sweet prince, in that case. > > > On Sun, Mar 19, 2017 at 5:02 PM Lenard Lindstrom wrote: > > Hi René and everyone else, > > I like this approach. My patches achieve the first step, using SDL2. The > next step is to introduce new SDL2 features as new modules and classes. > > I suppose the SDL2 patches can be incorporated as conditionally compiled > code. They can be added one at a time, but must all be in place to work > properly. Then any new Pygame modules will expose SDL2 features only, so > not be built for SDL1. > > As a long term goal SDL1 can be removed and SDL1 legacy modules > reimplemented on top of the SDL2 specific code. > > Is there any reason new modules should not be written in Cython? If not > then we could try to use parts of pygame_sdl2 to quickly introduce SDL2 > specific features. > > Lenard Lindstrom > > > On 17-03-18 05:02 AM, René Dudfield wrote: > > Hello, > > > > so, I've spent some more time reading source code, and investigating > > SDL2 and the options a lot. > > > > I *think* this plan below could be the best way forward for us. > > > > tldr; > > * have a single source SDL1, and SDL2 code base with a compile time > > option. (like we have single source py2 and py3). > > * move bitbucket/pygame repo to github/pygame. > > > > > > Rather than reimplementing everything, and introducing lots of > > compatibility bugs, Instead I think a gradual approach would work > > better. I'm starting to think that perhaps pygame_sdl2 by Tom, is not > > such a great way forward (for the pygame project, I think it was > > necessary and good for Ren'Py). > > > > A big breaking change is kind of silly for how little resources we > > have. Python 3 managed to pull it off... after a decade, and with > > massive resources having poured into it. And it only took off once > > they put compatibility code back in. Here's the thread where some > > discussion has been happening. > > > https://bitbucket.org/pygame/pygame/issues/174/pygame-20-the-sdl2-edition > > > > > > What we do have is some patches to get the current code base working > > with SDL2. > > https://bitbucket.org/llindstrom/pygam
Re: [pygame] New pygame.org website
Can I suggest foregoing development of the games list for the time being, and just linking to the appropriate tags on steam, itch.io, gamejolt, etc? A games list is a bit of effort to develop, and a lot more to keep going and curated against spammers. It's an ongoing burden that will likely wear out those that take it on, and divert effort away from the rest of the website and the project. On Sat, Dec 17, 2016 at 2:06 AM Christopher Night wrote: > Sign me up to help, please. > > I would like to humbly vote against using github or anything similar to > submit games. I think there should be a dead-simple web interface. > > Yes making a pull request is easy for you and me, and yes I think that all > game developers need to learn github sooner or later, but there are many > people who are not there yet, and I think it needs to be as easy for them > to use pygame and share their results as possible. > > Obviously pygame is never going to be powering AAA games, but it's > excellent for beginners. In order to fill that niche and remain relevant, > however, there need to be as few barriers to entry as possible. > > However I will concede that anything is better than the current setup. > > On Fri, Dec 16, 2016 at 5:21 AM Radomir Dopieralski > wrote: > > Hi, > > I would be happy to help. I didn't get involved much in the previous > efforts, because I didn't think they were the right way to do it, but I > am all for a low-maintenance, simple, static website that won't get old > fast. > > As for the tools, I wonder if we could just use Sphinx like all the > PyGame documentation does, and not get extra tools involved. We will > need to make a custom Sphinx theme anyways, to make the documentation > look and feel match that of the rest of the website, and once we have > that, we can as well just use Sphinx for all the rest. This way it will > all be done with the same markup and using the same tools, and if any > Python programmer doesn't know Sphinx yet, I think it's only a good > thing to have to learn this tool, as it is pretty much a standard in > the Python community. I did that before with Sphinx for at least two > projects, and I can say that it's doable, even though some of the > extension mechanism that Sphinx offers for doing custom stuff are not > the most convenient. > > As for the list of games, I wonder if we could just make people commit > their entries into a github repository, together with an image and > description? I mean, this is interface for people who are making games > already -- so we don't necessarily have to make it super-easy and open > to spammers. Github has their own anti-spam measures, we could take > advantage of that. This way we avoid the need for a custom database and > app hosting. We can just generate static html for the game list daily, > or from a github hook. > > What do we want to do with the wiki? Do we want to "migrate" it to some > other engine, or just leave it as it is for now? Maybe put it into > github wiki too? > > > On Thu, 15 Dec 2016 20:23:50 + > Thomas Kluyver wrote: > > > Hi all, > > > > I know several people on this mailing list have proposed overhauling > > the Pygame website in the past. Now's your chance! > > > > The current Pygame website contains outdated information, relies on a > > (not so) secret sign up link for people who want to submit games, and > > as we can't currently contact René, we don't have access to change > > it. Peter Shinners, who registered the pygame.org domain, is on board > > with building a new site and making it pygame.org. > > > > The first steps are assembling a team of people who're interested in > > working on the website, and working out what technologies we'll use > > for the new site. I think the best way to tackle it is as two > > separate components: the static information and the game feed. I've > > copied in more details about what I think we need at the bottom of > > this email. > > > > If you're interested in helping to build this, or you have ideas > > about how best to do it, please reply to this email! > > > > Thanks, > > Thomas > > > > - > > Details: > > > > General info: > > > >- > > > >Designs, mockups and prototypes are welcome, but please don’t > > spend a lot of time building anything yet; we might go for another > > option. - > > > >Assembling a team to build and maintain the site is an important > > part of this. An average architecture with several people happy to > > maintain it is better than a genius architecture with one quarrelsome > > maintainer. - > > > >I’d like to preserve the informal, playful feel of the old green & > >yellow site, so bright colours and cartoonish graphics are > > acceptable (but not required, if you want to go a different way). > > > > > > Part 1: Information > > > >- > > > >Information about the project, how to install it, links to > > documentation & support forums, etc. Including content from the wiki > > on the old site. (Craven: Based
Re: [pygame] Registration disabled.
I'd suggest at this point, the pygame project has "too much" of a web presence. It seems like the current website requires a lot of ongoing effort, compared to the amount of time people are able to commit to pygame. I think it might make sense to just cut the pygame website back to the basics - a brief introduction, a download/install instructions page, and the definitive documentation and release notes. Things like a games lists can be hosted elsewhere - indiedb or itch.io both come to mind. Same thing with tutorials. Or they can profitably be left to the community.
Re: [pygame] Pygame_SDL2 Nightly Builds
On Sun, Jan 24, 2016 at 3:35 PM Wout Goud wrote: > Nice to see a proper release of Pygame_SDL2! > > Thanks. > Pygame handles multiple screens on another way than Pygame_SDL2... (at > least ~5 months ago) > > I'm not sure what you mean by this. Are you talking about the recent changes to list_modes? Or something else? > Do you mean RAPT with "the Android version of Pygame_SDL2"? > If yes, is it still as slow as ~5 months ago on Android? > It really depends on what you're doing. Startup time should be significantly improved, but at the end of the day a mobile device can't push as many pixels as a desktop can - especially when using the software renderer, which is what pygame assumes. >
[pygame] Pygame_SDL2 Nightly Builds
Hello again. I'm getting ready to make the first proper release of Pygame_SDL2, a mostly compatible reimplementation of the Pygame API on top of the SDL2 libraries. As part of that, I've been fixing a number of outstanding of issues, and I've set things up so that we're producing nightly builds of the source tarball, and nightly wheels for 32- and 64-bit versions of Python 2.7 and 3.5 on Windows. Pygame_SDL2 can be found on github: https://github.com/renpy/pygame_sdl2 And the nightlies can be found at: http://nightly.renpy.org/pygame_sdl2/ The eventual goal - in the next couple of weeks - is to get Pygame_SDL2 up on pypi so that it can be installed via pip on Windows. While I think Pygame_SDL2 is getting to be usable for other projects, more work can be done. Testing is still ad-hoc and minimal, so any help getting the pygame test suite working would be appreciated, as would any other contributions people want to supply. Ps. I was able to use the Android Runtime for Chrome to get the Android version of Pygame_SDL2 working inside the Chrome web browser. While it still needs some work in order to properly handle things like multiple-button mice, this paves the way for Chrome OS joining iOS and Android as a new platform the Pygame API runs on.
Re: [pygame] Steam Controller
It works for me on both Windows and Linux, although it seems to work a lot better under Windows. It only works when steam is running, and really only works when steam launches your game. Steam does let you add shortcuts to non-Steam games, and when you launch through the shortcut, the controller works, but only in the window that was just launched. You also need to configure the controller as a gamepad in the big picture mode as well. I've tested this using pygame on Linux, and pygame_sdl2 on Linux and Windows. Basically, this is a "Steam" controller in a literal sense - it's hard to use it with games that are outside of the Steam environment. On Wed, Oct 21, 2015 at 7:21 PM Bartosz Debski wrote: > Hi All, > > I know this is quite fresh but if anyone wonders do Steam Controller works > with PyGame? > Well answer is a NO at the moment. I have tested it on Win and on Linux. > Results are the same. > > > >>> import pygame > >>> pygame.init() > > (6, 0) > > >>> pygame.joystick.init() > > >>> pygame.joystick.get_count() > > 0 > > Some of Linux dmesg > [ 3144.851372] usb 7-3: new full-speed USB device number 6 using ohci-pci > [ 3145.005095] usb 7-3: New USB device found, idVendor=28de, idProduct=1142 > [ 3145.005103] usb 7-3: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [ 3145.005108] usb 7-3: Product: Steam Controller > [ 3145.005111] usb 7-3: Manufacturer: Valve Software > [ 3145.012350] input: Valve Software Steam Controller as > /devices/pci:00/:00:13.0/usb7/7-3/7-3:1.0/0003:28DE:1142.000F/input/input14 > [ 3145.012525] hid-generic 0003:28DE:1142.000F: input,hidraw0: USB HID > v1.11 Keyboard [Valve Software Steam Controller] on > usb-:00:13.0-3/input0 > [ 3145.018076] hid-generic 0003:28DE:1142.0010: hiddev0,hidraw1: USB HID > v1.11 Device [Valve Software Steam Controller] on usb-:00:13.0-3/input1 > [ 3145.025307] hid-generic 0003:28DE:1142.0011: hiddev0,hidraw2: USB HID > v1.11 Device [Valve Software Steam Controller] on usb-:00:13.0-3/input2 > [ 3145.032304] hid-generic 0003:28DE:1142.0012: hiddev0,hidraw3: USB HID > v1.11 Device [Valve Software Steam Controller] on usb-:00:13.0-3/input3 > [ 3145.039105] hid-generic 0003:28DE:1142.0013: hiddev0,hidraw4: USB HID > v1.11 Device [Valve Software Steam Controller] on usb-:00:13.0-3/input4 > > Looks like drivers for controller are provided with Steam client as > controller kind of works when you are logged into Steam. This mimics > keyboard and mouse which sort some of the problems. > > I have full controller support in my game and as long as gamepad is > recognised by system then pygame can make use of it. Seems like we need to > wait for OS level support for it as i got nothing on system level for it. > > I have tested also on Super Meat Boy (standalone, non-steam, Linux) and > gamepad works only if Steam is running as well, so this is broader issue > and not just pygame. > > Thought I share my findings. > > Cheers > Bart >
Re: [pygame] multi-touch with pygame_sdl2
Yes, as of a little while ago. We've added support for the SDL2 FINGERDOWN, FINGERUP, FINGERMOTION, and MULTIGESTURE events. On Tue, Aug 25, 2015 at 2:25 AM tom arnall wrote: > is it possible? >
Re: [pygame] advantages of pygame_sdl2 for android apps
The big advantage is that there isn't an alternative. Pgs4a used a private port of SDL for Android, which proved difficult to maintain as the platform changed. Pygame_SDL2 is based on SDL2, which is supported on Android and iOS, as well as desktop platforms. Pygame_SDL2 is also trying to support newer hardware in a compatible way - it supports internationalized text input, the gamepad API has been added recently, and support for touch events will be coming soon. On Tue, Aug 11, 2015 at 6:18 PM tom arnall wrote: > I am interested in moving an app to the pygame_sdl2 environment. For > someone writing games in Pygame to be ported to Android, what would be > the advantages of using pygame_sdl2? >
Re: [pygame] Pygame site
On Sun, Aug 9, 2015 at 3:01 PM gilga gilga wrote: > How about a wiki-style website ? (with a forum of course!). I don't have > enough time to contribute to a full website project, but I'm sure lot of > people could easily cooperate on little sections of a wiki-style website > (putting correct tutorials, tips etc...) > > Having used a wiki with Ren'Py and abandoned it, it's usually a bad idea. If you can't find people to contribute now, you're unlikely to find people to contribute to the wiki. At the same time, wikis wind up having a large ongoing cost when it comes to account approval, spam protection, etc.
[pygame] Pygame_SDL2 Extensions
I've made a little bit of documentation for Pygame_SDL2 available at: http://pygame-sdl2.readthedocs.org/en/latest/ Right now, it focuses on the places where Pygame_SDL2 extends the Pygame API. A goal of these extensions has been to be backwards-compatible - an application that is ignorant of the new features should be able to run unchanged. Comment on these extensions is welcome.
Re: [pygame] having problem with font objects in pgs4a ports to android
On Sun, Jul 26, 2015 at 2:50 AM tom arnall wrote: > Thanks again for yr help. I'm very interested in pygame_sdl2 and it > seems to me that porting my game project to it would be fairly simple > and worth the effort as well for future projects. But I shudder at the > delay to my project which I suspect wd be required to create and > master a new packaging environment. And all of it to get some simple > text on the screen. The packaging code should be similar - the pygame_sdl2 android stuff uses a newer version of the original pgs4a code. The Android packaging should be the same, except for some newer library versions. > Is it simply the case that pgs4a does not support > font rendering? > > The answer is, "I don't know." Font rendering worked when it was first released, so I think it should probably work. But at the same time, I'd rather put effort into what I think the future should be, rather than the past.
Re: [pygame] having problem with font objects in pgs4a ports to android
Have you tried your entire app under RAPT/pygame_sdl2? The general idea is that pygame_sdl2 should run all pygame games unchanged except for the import code. Insofar as it doesn't, that's something we should investigate and try fix. (The one exception is the dropping of support for non-32 bit surfaces, which have probably been obsolete for a while now, and complicate everything by requiring 4 code paths.) On Fri, Jul 24, 2015 at 8:46 PM tom arnall wrote: > Tom, > > Thanks again for the help you have been giving me. And thanks of > course for your work on pygame_sdl2. > > Is it possible to take just the font rendering capability from > pygame_sdl2 and use it without changing the rest of my application? I > would like to avoid rewriting the application in order to deal with > drawing a line of text > > Are there any areas in which pygame_sdl2 is not compatible with python 2.7 > ? > > If I use the pygame_sdl2 font rendering, do I need to use RAPT instead > of pgs4a for the port to android? (Yes, this is an obviously lazy > question, but please cut me a break on it.) > > Thanks in advance for any help you can give me, > > Tom Arnall > Baja Norte > > > > > > On 7/24/15, Tom Rothamel wrote: > > Have you tried the newer RAPT-based tool? PGS4A is getting very old, > hasn't > > been updated for newer android versions. (Part of the reason for > > pygame_sdl2 is that it was easier and more productive to use SDL2 to port > > to Android/iOS than to continue maintaining an Android SDL1 port.) > > > > On Fri, Jul 24, 2015 at 7:37 PM tom arnall wrote: > > > >> I think I'm making progress on the issue, but I am still having > >> problems with font rendering. The code below runs on my PC under > >> Linux, i.e., it prints "hello world" on the window it produces. But > >> when I make it into an apk with the pgsa-0.9.4 kit and run it on my > >> phone, it puts garbage on the screen. I posted this item y'day except > >> I have changed creation of the font object. Instead of using > >> font.SysFont, I'm using font.Font with argument of a font file name, > >> as in: > >> > >> font = pygame.font.Font(“data/Vera.ttf”, 25) > >> > >> No change in results but I think closer to good ones because I read on > >> the net that SysFont will not work for android ports. It also stands > >> to reason that it is better to include the data for the font in the > >> apk. > >> > >> Again, I’ve put pygame apps on the phone which don’t use the Font > objects > >> and > >> they run fine. And this one runs fine under Linux. > >> > >> > >> > >> > >> import pygame, sys, os, random > >> from pygame.locals import * > >> import time > >> > >> try: > >> import android > >> except ImportError: > >> android = None > >> > >> def stop(interval=3): > >> print “stopping >> ” + str(interval) > >> time.sleep(interval) > >> > >> pygame.init() > >> > >> BLACK = (0, 0, 0) > >> WHITE = (255, 255, 255) > >> > >> width = 400 > >> height = 400 > >> > >> screen = pygame.display.set_mode((width, height)) > >> > >> background = pygame.Surface(screen.get_size()) > >> background = background.convert() > >> background.fill(WHITE) > >> > >> surface = pygame.Surface((width,height)) > >> > >> font = pygame.font.Font(“data/Vera.ttf”, 25) > >> > >> itemSurface = font.render(“hello world!”, True, BLACK, WHITE) > >> surface.blit(itemSurface, (0,0)) > >> background.blit(surface, (0,0)) > >> screen.blit(background,(0,0)) > >> > >> pygame.display.flip() > >> > >> stop(20) > >> > > > > > -- >
Re: [pygame] having problem with font objects in pgs4a ports to android
Have you tried the newer RAPT-based tool? PGS4A is getting very old, hasn't been updated for newer android versions. (Part of the reason for pygame_sdl2 is that it was easier and more productive to use SDL2 to port to Android/iOS than to continue maintaining an Android SDL1 port.) On Fri, Jul 24, 2015 at 7:37 PM tom arnall wrote: > I think I'm making progress on the issue, but I am still having > problems with font rendering. The code below runs on my PC under > Linux, i.e., it prints "hello world" on the window it produces. But > when I make it into an apk with the pgsa-0.9.4 kit and run it on my > phone, it puts garbage on the screen. I posted this item y'day except > I have changed creation of the font object. Instead of using > font.SysFont, I'm using font.Font with argument of a font file name, > as in: > > font = pygame.font.Font(“data/Vera.ttf”, 25) > > No change in results but I think closer to good ones because I read on > the net that SysFont will not work for android ports. It also stands > to reason that it is better to include the data for the font in the > apk. > > Again, I’ve put pygame apps on the phone which don’t use the Font objects > and > they run fine. And this one runs fine under Linux. > > > > > import pygame, sys, os, random > from pygame.locals import * > import time > > try: > import android > except ImportError: > android = None > > def stop(interval=3): > print “stopping >> ” + str(interval) > time.sleep(interval) > > pygame.init() > > BLACK = (0, 0, 0) > WHITE = (255, 255, 255) > > width = 400 > height = 400 > > screen = pygame.display.set_mode((width, height)) > > background = pygame.Surface(screen.get_size()) > background = background.convert() > background.fill(WHITE) > > surface = pygame.Surface((width,height)) > > font = pygame.font.Font(“data/Vera.ttf”, 25) > > itemSurface = font.render(“hello world!”, True, BLACK, WHITE) > surface.blit(itemSurface, (0,0)) > background.blit(surface, (0,0)) > screen.blit(background,(0,0)) > > pygame.display.flip() > > stop(20) >
Re: [pygame] pygame to android
The theory is that pygame_sdl2 will be able to run the pygame test suite at some point. On Wed, Jul 22, 2015 at 9:30 PM tom arnall wrote: > " And pygame_sdl2 is far from ready - there's no test suite, for example." > > what happened to "write tests first!" ? > > > > On 7/22/15, Tom Rothamel wrote: > > On Wed, Jul 22, 2015 at 4:37 PM Luke Paireepinart < > rabidpoob...@gmail.com> > > wrote: > > > >> Tom, > >> Is sdl2 Pygame the way forward for Pygame? > >> > > > > I think it is - but I'm biased about this. And pygame_sdl2 is far from > > ready - there's no test suite, for example. All I can say is that I > > need/plan to maintain pygame_sdl2 indefinitely to support Ren'Py. (Or at > > least until a better implementation of the Pygame API comes about.) > > > > I would be interested in assisting with a generic Pygame packager for > cross > >> platform applications. Where would we get started in doing that, to > >> separate it from Ren'Py in a generic way? > >> > > > > I'd suggest grabbing a copy of the Ren'Py SDK (from www.renpy.org), > > creating a new project, and building distributions of it, just to get a > > feel for what the tools can do in terms of installing text editors and > > packaging games for various platforms. > > > > My thinking is the right thing to would be to modify the Ren'Py launcher > so > > that it can be rebranded and released as a pygame tool, as opposed to > > trying to make something standalone. This is for pragmatic reasons - > > maintaining a split version would be more ongoing work that coming up > with > > a variant of the launcher that can launch and package arbitrary pygame > > apps. > > > > That being said, all the Ren'Py packager does is to copy various files > into > > zip or tar.bz2 files with appropriate permissions info, so if someone > wants > > to make a standalone tool or distribution, they can. > > > >> > > > > > -- > .. > Faced with the possibility of its extinction, every species finds > within itself powers unimaginable in the days of its complacency. >
Re: [pygame] pygame to android
On Wed, Jul 22, 2015 at 4:37 PM Luke Paireepinart wrote: > Tom, > Is sdl2 Pygame the way forward for Pygame? > I think it is - but I'm biased about this. And pygame_sdl2 is far from ready - there's no test suite, for example. All I can say is that I need/plan to maintain pygame_sdl2 indefinitely to support Ren'Py. (Or at least until a better implementation of the Pygame API comes about.) I would be interested in assisting with a generic Pygame packager for cross > platform applications. Where would we get started in doing that, to > separate it from Ren'Py in a generic way? > I'd suggest grabbing a copy of the Ren'Py SDK (from www.renpy.org), creating a new project, and building distributions of it, just to get a feel for what the tools can do in terms of installing text editors and packaging games for various platforms. My thinking is the right thing to would be to modify the Ren'Py launcher so that it can be rebranded and released as a pygame tool, as opposed to trying to make something standalone. This is for pragmatic reasons - maintaining a split version would be more ongoing work that coming up with a variant of the launcher that can launch and package arbitrary pygame apps. That being said, all the Ren'Py packager does is to copy various files into zip or tar.bz2 files with appropriate permissions info, so if someone wants to make a standalone tool or distribution, they can. >
Re: [pygame] pygame to android
On Wed, Jul 22, 2015 at 4:11 AM tom arnall wrote: > what is the relationship between RenPy and Pygame? > > Ren'Py is a game engine that people use to make specific types of generally narrative-heavy games. Visual Novels, Life Simulations, and simple RPGs are all within what Ren'Py was intended to help make. For ten years, Ren'Py was based on Pygame, to the point where the Pygame API is included in various places in the Ren'Py API. About a year ago, it became clear that SDL2 would be necessary for Ren'Py to keep supporting Android and add iOS support, so we wrote Pygame_sdl2, a reimplementation of the Pygame API over SDL2. (Pygame_sdl2 isn't complete, as it needs help from people who understand buffers and the pygame test suite.) Ren'Py has a number of tools that are used to package games for mobile platforms - RAPT is used for Android, while Renios is used for iOS. These tools are generally written in a way that they can be used to package arbitrary games written using pygame_sdl2. Ren'Py itself also comes with a launcher that can one-click package a Ren'Py game for Windows, Mac OS X, and Linux - with a few more clicks, it also takes care of Android and iOS packaging. This isn't designed to work with arbitrary pygame code, but could plausibly be changed to do so. Due to terrible social skills, I haven't really contributed much of this Ren'Py work back to pygame - and the one project I did contribute, pygs4a, turned out to be a technological dead end. I'm trying to change this, if people are interested.
Re: [pygame] pygame to android
Um... basically, the docs are out of date, and since pgs4a was a technological dead-end from the start (it used a private fork of SDL1), efforts to update its documentation are kind of wasted. On Wed, Jul 22, 2015 at 12:00 AM tom arnall wrote: > Tom > > thanks very much! > > btw at: > > http://pygame.renpy.org/android-packaging.html > > there are instructions for putting a pygame application into an apk, > but there is no mention of what must be done to the pygame application > code to make it android-ready. For exampe, there is no mention of > 'import android'. why is this? > > regards, > > Tom Arnall > > .. > Faced with the possibility of its extinction, every species finds > within itself powers unimaginable in the days of its complacency. > > > On 7/21/15, Tom Rothamel wrote: > > Pygame_sdl2, as packaged with RAPT is probably the best solution - > > depending on if it supports the subset of pygame that you're using. > > > > I threw together a git repository that has a sample game that can be > > packaged. You can check it out at: > > > > https://github.com/renpytom/rapt-pygame-example > > > > The main.py in there shows how to handle the APP_WILLENTERBACKGROUND > > (sleep) and APP_DIDENTERFOREGROUND (resume) events, which most Android > apps > > will want to handle. > > > > Hope this helps, and let me know if you're having trouble - this code > works > > well with Ren'Py, but I don't think many people have tried it with more > > general Pygame code. > > > > > >> On Tue, Jul 21, 2015 at 7:14 PM tom arnall wrote: > >> > >>> are there any people on this list who are big into porting pygame apps > >>> to android? > >>> > >> > > > > > -- >
Re: [pygame] pygame to android
Pygame_sdl2, as packaged with RAPT is probably the best solution - depending on if it supports the subset of pygame that you're using. I threw together a git repository that has a sample game that can be packaged. You can check it out at: https://github.com/renpytom/rapt-pygame-example The main.py in there shows how to handle the APP_WILLENTERBACKGROUND (sleep) and APP_DIDENTERFOREGROUND (resume) events, which most Android apps will want to handle. Hope this helps, and let me know if you're having trouble - this code works well with Ren'Py, but I don't think many people have tried it with more general Pygame code. > On Tue, Jul 21, 2015 at 7:14 PM tom arnall wrote: > >> are there any people on this list who are big into porting pygame apps >> to android? >> >
Re: [pygame] erratic behavior with 'display.update(Rect)'
On Mon, Jul 13, 2015 at 6:54 PM tom arnall wrote: > > If display.update()' doesn't work with OPENGL, what do you use to > update just one area of the display? > > > There isn't a way to update a portion of the display using OpenGL. OpenGL expects you to redraw the screen from scratch every frame, and then flip to the next frame. How are you drawing to the screen? Are you using GL calls? Or pygame blits to the screen surface? The later doesn't work with OPENGL.
Re: [pygame] Which project is actually pygame2?
On Sun, Jul 12, 2015 at 1:34 PM Jake b wrote: > - Ren'Py > - aka pygame_sdl2 > - https://github.com/renpy/pygame_sdl2 > > Just to clarify, pygame_sdl2 is not the same thing as Ren'Py. Just as Ren'Py < 6.99 was based on pygame, Ren'Py >= 6.99 is based on pygame_sdl2. Pygame_sdl2 is meant to be a mostly-compatible reimplementation of pygame, usable by other pygame applications and libraries. pygame_sdl2 fundamentally supports Android and iOS, but parts of that support are in Ren'Py-branded tools. Removing that branding would be relatively easy. When I say mostly-compatible, the only thing I think it makes sense to drop is support for < 32-bit surfaces, since doing so simplifies the code greatly. We could add support back, but doing means doing 4x the work whenever code touches the pixels. There are a number of modules that haven't been implemented yet, mostly involving python's buffer support. And pygame_sdl2 hasn't been thoroughly tested outside of the parts of it used to support Ren'Py.
Re: [pygame] What's next for Pygame project?
On Sun, Jul 12, 2015 at 12:52 PM Jake b wrote: > I think there's (a lot?) of new non-backward compatible features? [multi > windows, default hardware support, touch events, etc]. Are there other > changes that were previously skipped because it wasn't backward compatible. > > What I mean is maybe pygame2 should start with design changes, rather than > worrying on making a completely backward compatible choices? > I don't think trying to come up with a backwards-incompatible version of pygame is the right way to go. Pygame is the sort of API that's taught in books meant to teach children how to program - I think it makes sense to avoid obsoleting that knowledge. Similarly, people have a lot of time and code invested in pygame. Some of that code exposes the pygame API - for example, in Ren'Py, we expose pygame events to game code. I imagine other pygame-based libraries are similar. It's also not terribly necessary. In pygame_sdl2, we were able to add support for SDL2 functionality without materially changing the pygame API. For example, take the pygame(_sdl2).display module: https://github.com/renpy/pygame_sdl2/blob/master/src/pygame_sdl2/display.pyx We added a new Window class to that module to represent SDL2 windows. display.set_mode creates a Window instance that display.update and the other methods access - but you could call .update on a Window instead. At least in theory, old code works, while new code can take advantage of new features. We did something similar with events - kept the existing events while adding new events such as application state and text input events. (The application has to opt into the latter with new functions in pygame_sdl2.key.) As long as code is written in a way to ignore unknown events and fields on events - which should always be the case, or pygame1 would have been unable to add anything - it should work. We've added support for a lot of other SDL2 functionality in the same way. I'm pretty sure it should be possible to make a version of pygame that runs existing pygame code while exposing new features to new code - allowing people to exploit much of their existing knowledge. Some other thoughts: It's probably impossible to implement something compatible with pygame without compiling at least some C code. One problem is blend modes - many of the pygame blend modes, including the default alphablend mode, aren't in SDL2. I'm a little skeptical of ffi-based approaches on mobile platforms - linking everything together seems more likely to work.
Re: [pygame] What's next for Pygame project?
As long as it doesn't interfere with the development of Ren'Py, I'd like to contribute as much as possible of the technology stack that underlies Ren'Py to the pygame project. Pygame_sdl2 is the obvious choice for inclusion, as it was really meant to be an API-compatible successor to Pygame. I think it would benefit from being merged with pygame proper, as much of the missing functionality is based on C code found in the Pygame project. The rapt and renios modules - which are used for Android support and iOS support, respectively - are also good candidates. Both are already capable of packaging arbitrary pygame(_sdl2) programs, at least in theory. A problem that needs to be solved is how to include arbitrary python modules in the distribution. There's also a bit of code in Ren'Py that should really belong in pygame, that I've been avoiding adding because it's a completely new API. In-app purchase support is one of these, and achievement support is another - although the latter may be complicated by licensing issues. A project I've been contemplating is extending Ren'Py's launcher to support arbitrary pygame code. For those not familiar, the Ren'Py launcher supports: - Automatically downloading and installing text editors and other applications needed for development. - One-click packaging for Windows, Mac, and Linux - including all three in a standalone zip file. - Automatic installation of rapt and the various android tools, and creation of Android apps. - Automatic installation of renios and creation of iOS apps. While the launcher is part of Ren'Py, I'd be happy to add pygame-specific code to Ren'Py. My one worry is that Linux distros would wait for stable releases of pygame_sdl2 before packaging Ren'Py, leading to substantial holdups. My hope is that could be solved by trying to keep master in a releasable state, and making it clear to distros that it's acceptable to package master up for releases. On Sat, Jul 11, 2015 at 12:45 AM Daniel Foerster wrote: > > On 07/10/2015 09:47 PM, Peter Shinners wrote: > > I haven't been paying close attention to Pygame, but it doesn't seem > > controversial to say things have stalled. > Not at all, unfortunately. > > * Getting 1.9.2 actually released > At the least we need a stable release so that Python 3 support can land > in official repositories. > > * Moving on to "Pygame 2", whatever that means > I don't know how the rest of the mailing list feels, but looking at SDL > 2 (perhaps along the lines of Ren'Py's pygame_sdl2 project?) seems like > a decent starting point. > > * Catch up on the Bitbucket pull requests > > It seems there are still many great people involved with the Pygame > > project. Perhaps I can help by getting those people the control they > > need to make progress. > We're suffering from a lack of people who have the time and power to > review and approve the PRs as much as anything. > > * Website replacement and love > It's definitely overdue for an overhaul, I'd be willing to work on that > if I can get some information on what server-side tools are available > (time for some modern Python web frameworks and templating abilities!). > > * Migrate forum to Reddit (or community forum) > I would suggest checking out Discourse, it seems like a pretty well > engineered solution, much better than phpBB would be at the least! > > I'm completely detached from things at this point, so I don't have any > > context to jump in and try to change anything. What parts of the > > project are going well these days? > People are still writing cool stuff in Pygame and bugs seem to still be > getting fixed. > >
Re: [pygame] android pygame app not functioning
For the (now-ancient) PGS4A, you have to import android, and then call
android.init(). That's discussed here:
http://pygame.renpy.org/writing.html
Pygame_sdl2 changes things a lot, to the point where none of this is
needed, but it needs better documentation on how to run in on
windows/mac/linux for testing purposes.
On Sun, Jun 14, 2015 at 2:36 AM Rob Hagemans
wrote:
> Hi Tom,
>
> There's quite a few things that work on pygame that pygame-for-android
> doesn't support, so perhaps you're running into one of those. For example,
> any print command or output to sys.stdout would cause the app to silently
> fail as you describe. It can be very frustrating to find out.
>
> Are you getting any useful information out of android.py logcat or adb
> logcat? You should see some messages appearing while your device is
> connected by USB in developer mode and starting the app. At the very least
> I would expect something related to 'window death' or some such and some
> message from Python before that that may give an indication of what's amiss.
>
> Rob
>
>
> On Sunday, 14 June 2015, 5:47, tom arnall wrote:
>
>
> I am able to get the following code to build and create apk, following
> the instructions athttp://pygame.renpy.org/android-packaging.html. It
> installs normally on the android device, but when I run it flashes
> junk and goes away. The only abnormal things I can see are when it
> configures and builds:
>
> pgs4a-0.9.4/$./android.py configure apps/test
> buildlib/jinja2.egg/jinja2/__init__.py:31: UserWarning: Module
> colorama was already imported from buildlib/colorama/__init__.pyc, but
> /usr/lib/python2.7/dist-packages is being added to sys.path
> __version__ = __import__('pkg_resources') \
>
> pgs4a-0.9.4/$ ./android.py build apps/test/ release
> buildlib/jinja2.egg/jinja2/__init__.py:31: UserWarning: Module
> colorama was already imported from buildlib/colorama/__init__.pyc, but
> /usr/lib/python2.7/dist-packages is being added to sys.path
> __version__ = __import__('pkg_resources') \
>
> Here is the code:
>
> import pygame
> import pygame.font
> import pygame.event
> import pygame.draw
> import string
> from pygame.locals import *
> black=(0,0,0)
> green=(0,255,0)
>
> #Tne next step is to make a function to create the display box.
>
> def display_box(screen,mess):
> fontobject = pygame.font.Font(None,18)
> pygame.draw.rect(screen,black,((screen.get_width() / 2) - 100,
> (screen.get_height() / 2) - 10,200,20), 0)
> pygame.draw.rect(screen,green,((screen.get_width() / 2) - 101,
> (screen.get_height() / 2) - 11,200,20), 1)
> if len(mess) != 0:
> screen.blit(fontobject.render(mess, 1, (25,255,25)),
> ((screen.get_width() / 2) - 100, (screen.get_height() / 2)
> - 9))
> pygame.display.flip()
>
> #Let's start the pygame window and display the box.
>
> if __name__ == '__main__':
> pygame.init()
> pygame.display.set_caption("Hello world")
> screen = pygame.display.set_mode((320,240))
> pygame.font.init()
> mess = []
> while 1:
> display_box(screen,"Hello world text")
> pygame.display.update()
> pygame.time.delay(10)
> for event in pygame.event.get():
> if event.type in
> (pygame.QUIT,pygame.KEYDOWN,pygame.MOUSEBUTTONDOWN):
> raise SystemExit
>
>
>
Re: [pygame] Pygame_sdl2
On Wed, Apr 8, 2015 at 12:22 PM diliup gabadamudalige wrote: > This is too good to be true! May I ask if we can bundle the current Pygame > 2.7 / Pygame 1.9.2 with this? > > I'm not sure if I understand the question. The whole point of doing pygame_sdl2 was that trying to maintain an SDL1 port for Android and iOS was painful and impossible (respectively), so we wanted to get the pygame API working on SDL2. That being said, your current code might be able to run if you add import pygame_sdl2; pygame_sdl2.import_as_pygame() before the first import of pygame. (You might as well try it on the desktop before attempting an Android or iOS port.) In retrospect, I'm not sure what the sound story is on Android and iOS - I don't think we're currently compiling the format dependencies.
Re: [pygame] Pygame_sdl2
For now, you have to use a pair of packaging tools we've written to package Ren'Py apps for Android and iOS. Despite the names, they're both intended to package arbitrary pygame_sdl2 apps. (For now, there is some Ren'Py branding, especially in the iOS tool, but that branding should probably be changed before release anyway.) You can get them both from http://nightly.renpy.org/current/ , as -rapt.zip and -renios.zip. RAPT (Ren'Py Android Packaging Tool) still works approximately as documented at http://pygame.renpy.org/, especially when it comes to building android applications. The big change is that the lifecycle events are now different - see below. (Some other modules, like lifecycle management, are also different.) Renios is the iOS packaging tool. You can create a new project by running ./ios.py create MyProject That will copy the prototype directory to MyProject, and make some changes to the various plist files. You can then place a main.py in MyProject/base, and use Xcode to build the project. We've exposed the SDL2 application lifecycle events to pygame_sdl2 users: https://wiki.libsdl.org/SDL_EventType#Android_and_iOS_Events The mapping is pretty straightforward - SDL_APP_TERMINATING becomes pygame_sdl2.APP_TERMINATING. In Ren'Py, I handle these as follows: On APP_TERMINATING, we save the game (in a special save file) and immediately quit. On APP_WILLENTERBACKGROUND, we stop all sound, timers, and screen updates; save the game (in a special save file), and sit in a tight pygame.event.wait() loop. If that loop gets an APP_DIDENTERFOREGROUND event, we delete the save file, and resume screen updates and sound. If the loop gets an APP_TERMINATING event, we just quit. When Ren'Py starts, it checks for the special save file, and if found loads it, restoring the player's state. Right now, the mobile stuff is still somewhat raw. RAPT has been used to ship a number of Android apps, so it works well enough - but I haven't spent a lot of time trying it with arbitrary pygame_sdl2 games, so there might be some minor problems there. Renios is still quite beta. Both are Python 2.7-only at the moment - making the version of python configurable will be a challenge. On Wed, Apr 8, 2015 at 2:13 AM Gino Ingras wrote: > you mentioned that it is better to use pygame_sdl2 for mobile apps. > how do you do that? > > 2015-04-08 5:01 GMT+02:00 Michael Lutynski < > mich...@callthecomputerdoctor.com>: > >> I too am very stoked to hear about the pygame1 release and the >> pygame_sdl2! This is wonderful!! >> >> >> >> ~ Michael >> >> >> >> On Tue : Apr 7, 2015 3:13:02 PM you wrote: >> >> > pps. yes, I think it would be nice to join forces. Including testing, >> >> > porting, doing missing modules, and re-licensing or rewriting LGPL code >> >> > where needed. Maybe moving the repo under the pygame organisation on >> >> > bitbucket (perhaps?). >> >> > >> >> > I have holidays in 3 weeks, which I've planned to try and push the >> pygame1 >> >> > release out the door. Probably the last major pygame 1 release. >> >> > >> >> > Trying to port existing games to pygame_sdl2 is probably a nice effort >> >> > everyone can do to help :) I'll report back on my games later. >> >> > >> >> > >> >> > best, >> > >
[pygame] Pygame_sdl2
I mentioned this in passing a few months ago, but I think it's time to formally announce Pygame_sdl2. Pygame_sdl2 starts with the premise that the Pygame API is important. The Pygame API has been used by thousands of games, libraries, and engines, and is being taught to beginning programmers. Preserving the Pygame API is important, as it means that those games, libraries, and engines will keep running, and those programmers' experience will not become obsolete. At the same time, SDL2 support is beneficial for a number of reasons. SDL 1.2 is now obsolete, and has been for a while. New features, and ports to new platforms - especially the important mobile platforms - have been added to SDL2, and SDL2 only. For a while, I tried to add Android support by maintaining, as part of PGS4A, a port of SDL 1.2 to Android, but that proved to be very difficult as mobile platforms keep evolving. In October of last year, Patrick Dawson and myself began work on Pygame_sdl2, a reimplementation of the Pygame API using SDL2 and related libraries. The goal of the project is to allow games written to the Pygame API to run, using SDL2, on desktop and mobile platforms. We've also exposed some SDL2-provided functionality in a way that remains compatible with older code. At least for now, Pygame_sdl2 is available at: https://github.com/renpy/pygame_sdl2 It's been used - as part of my Ren'Py engine - to release multiple games on Windows, Mac OS X, Linux, and Android, and I've been able to get Pygame_sdl2 to run on iOS, but haven't submitted to the App Store yet. This process, which included at least one Steam release, helped to shake out the more obvious problems. Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the Cython code massively simplified the project - by not having to worry about the details of python bindings, we were able to get the initial version of Pygame_sdl2 running in a short amount of time. Newly-written code is licensed under SDL2's Zlib license, while the code we imported from Pygame is licensed under the LGPL. (The LGPL's terms control distribution.) Pygame_sdl2 implements a large portion of pygame, but not all of it. Currently implemented modules are: * pygame_sdl2.color * pygame_sdl2.display * pygame_sdl2.draw * pygame_sdl2.event * pygame_sdl2.font * pygame_sdl2.gfxdraw * pygame_sdl2.image * pygame_sdl2.joystick * pygame_sdl2.key * pygame_sdl2.locals * pygame_sdl2.mixer (including mixer.music) * pygame_sdl2.mouse * pygame_sdl2.scrap * pygame_sdl2.sprite * pygame_sdl2.surface * pygame_sdl2.sysfont * pygame_sdl2.time * pygame_sdl2.transform * pygame_sdl2.version Experimental new modules include: * pygame_sdl2.render Current omissions include: * Modules not listed above. * APIs that expose pygame data as buffers or arrays. * Support for non-32-bit surface depths. Our thinking is that 8, 16, and (to some extent) 24-bit surfaces are legacy formats, and not worth duplicating code four or more times to support. This only applies to in-memory formats - when an image of lesser color depth is loaded, it is converted to a 32-bit image. * Support for palette functions, which only apply to 8-bit surfaces. There are a few additions to the pygame API, including support for the application lifecycle events on Android and iOS, IME-based text input, and SDL2 renderers. While I plan to, at the very least, maintain this indefinitely to support Ren'Py, my hope is that it could be useful to the larger Pygame community. For now, Pygame_sdl2 could probably benefit from testing, both informal reports of missing APIs and incorrect implementations, and someone helping to integrate the relevant portions of the pygame test suite. The modules that have not been implemented are often that way because we don't have much experience with them - for example, I've never been able to wrap my head around the array modules. So help implementing those, or porting the Pygame implementations, would be appreciated. For now, pygame_sdl2 has been maintained as part of the Ren'Py github organization, but if there's enough interest in contributing and expanding it, it might make sense to break it out into its own project. Anyway, thank you for reading through this message, and for trying out pygame_sdl2.
Re: [pygame] create account on pygame.org
On Mon Feb 16 2015 at 12:29:12 AM diliup gabadamudalige wrote: > How does a URL that is given to many people keep being referred to as a > "secret URL" or is this some kind of secret code message? > > I've found what works very well to fight spam is a small bit of domain specific knowledge. Questions like "What pygame function should be called to create a window?" should be relatively easy for someone who uses pygame to answer, but would likely work surprisingly well to keep spammers at bay.
Re: [pygame]
On Thu, Dec 4, 2014 at 11:28 AM, Paul Vincent Craven wrote: > What features would we look for in PyGame 2? > > Moving to SDL 2 would be a large change from what we have now. > > It doesn't have to be. For the past month or so, Patrick Dawson and myself have been working on on a rewrite of pygame on top of SDL2, trying to preserve support for most* of the pygame python-level API, while adding support for SDL2 features. You can see what we have at: https://github.com/renpy/pygame_sdl2 It's enough to run some non-trivial games without major changes, on Windows, Mac, Linux, and Android, although it's probably closer to pygame 1.8 then 1.9. I'm currently working on iOS support, after which nightly builds will start coming out. At some point, we'll be exposing new features based on SDL2, while still trying to hew relatively closely to the pygame API, so people's existing code and experience can be preserved. * I think it makes sense to drop support for surfaces with depths of less than 32bpp - doing so is a big simplification.
[pygame] Py_BEGIN_ALLOW_THREADS in surface.c
I'm curious - why are Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS commented out (and otherwise missing) in surface.c? It seems like those would be the most expensive functions, and hence the ones that would benefit most from running in a threaded environment. They're used in many other parts of pygame.
Re: [pygame] Professional games made with Pygame?
Analogue: A Hate Story is the other Ren'Py game that's on Steam. On Sun, Feb 17, 2013 at 5:16 PM, Noel Garwick wrote: > Isn't Renpy's codebase pretty divorced from pygame these days? > I don't think divorced is the right word. Ren'Py is built on top of Pygame, to the point where there are several places where Pygame's API is incorporated into Ren'Py's. (For example, creator-made GUI widgets are expected to handle pygame events, and Ren'Py's drawing canvas support is a thin wrapper around pygame.draw.) Ren'Py also uses Pygame services where suitable - all image loading goes through Pygame, and Ren'Py makes extensive use of Surfaces internally. At the same time, there are several modules that Ren'Py has its own implementations of. Like many games, Ren'Py uses OpenGL (as well as OpenGL ES and ANGLE) for graphics rendering. It has its own libav-based music and movie playback system, so it can play multiple sounds at the same time, and a range of movie formats. Finally, it has its own text rendering module, which seemed necessary to deal with text-heavy games. I'll claim that Ren'Py is still based on pygame - but I'm willing to bypass it when necessary.
Re: [pygame] Re: p4a development activity?
Pgs4a development is limited by several factors. The biggest is that PGS4A is using an unofficial port of SDL to Android. There's a version of SDL 1.3 for Android, but SDL 1.3 hasn't been released yet. I also don't know if Pygame runs on SDL 1.3 - I don't think it does. I don't want to get into a situation where I'm spending a lot of time modifying SDL, only to have to do it again when the new version comes out. Right now, my plan is for the next release of pgs4a to sync up with the next release of Ren'Py. The focus will be on making it easier to set up a development environment to create packages - that will be an outgrowth of Ren'Py's new launcher tool.
[pygame] Pygame Subset for Android 0.9.3 Released
We've released version 0.9.3 of the Pygame Subset for Android to: http://pygame.renpy.org/ as well as the Android Market. This new release adds the following features: * Python has been upgraded to version 2.7.1. * Better support for Honeycomb tablets. * APIs for getting the screen DPI, and showing/hiding the keyboard. * New python modules: urllib2, io, uuid, json; optionally PIL and sqlite3. * New encodings: idna, base64, hex This release requires a change to existing programs; the android.init() method must be called before a program will receive input. I'd like to welcome Patrick Dawson to the PGS4A development team - all of the new features in this release were based on his contributions.
Re: [pygame] Pygame Subset for Android 0.9.2 Released
On Sat, Mar 12, 2011 at 5:33 PM, René Dudfield wrote: > Hi again, > > build_all.sh seems to have worked! > > If you don't mind me asking questions... How do I know make it into an .apk > that I can install? > > Run build.py with the --launcher argument, or run it with --dir or --private to include a game as part of it. > I had to fix a few instances for getattr in the pyrex, that used the third > argument as a default argument. I think the version that comes with ubuntu > only works with 2 arguments. I submitted a branch to merge a fix if you > want it. I had been using cython instead of pyrex, as it seems to support a larger subset of Python.
Re: [pygame] Pygame Subset for Android 0.9.2 Released
On Sun, Mar 6, 2011 at 8:43 PM, wrote: > Couldn't you just make it an eclipse project, and have the developer drop > the files (Pygame, .py's, data files)into assets, and have the java compiler > do the rest? Pardon my ignorance, but is there any reason this wouldn't work > for packaging? > > There are several limitations as to the size of assets on Android, and what you can do with particular assets. With the exception of already-compressed assets, you're stuck with a 2M uncompressed size limit. Also, to read assets from Python, one would have to do a lot of JNI bridging, and probably some emulation of the filesystem, since games might want to do things like list a directory tree. Uncompressing to the filesystem makes all of this easier. Writing an Eclipse project might be possible - I don't know what it entails.
Re: [pygame] Pygame Subset for Android 0.9.2 Released
On Thu, Mar 3, 2011 at 7:53 PM, René Dudfield wrote: > Hi again, > > today I messed around with porting one of my old games to Pygame Subset For > Android (PSFA). > Cool. When it's ready, I'd love to see it. > I haven't tried compiling PSFA itself yet, I just use the `adb push ...` to > copy the files whilst the device is in debug mode. Is there a way to get > that to only copy the files that changed? Since this game has a heap of > files... it takes a while to transfer each time I want to run a change. > > I don't know of any way, offhand. Most of what I've tested with has been uploadable within a few seconds, so I haven't encountered the issue. (It may also be device-sensitive.)
Re: [pygame] Pygame Subset for Android 0.9.2 Released
On Wed, Feb 23, 2011 at 5:24 AM, René Dudfield wrote: > Do you build it on ubuntu? If so, what packages do you need to install to > package it? > Yes. From Ubuntu I grabbed the jdk and ant, while I downloaded the android-sdk and android-ndk directly from google. If you're not using 64-bit ubuntu, you'll need to compile python 2.6.4 and copy the python and pgen binaries into Python-2.6.4 as hostpython and hostpgen, respectively. Is there a way to install it without the market? My cheapo tablet doesn't > have the market on it yet(without a hack), since it's still android 2.2, and > apparently they're not supposed to put the market on 2.2 with 10 inch > screens. I guess I can just build packages which include pygame for people > to download manually. > Two ways (both of which require you to enable "Unknown Sources" on the Applications Settings screen): - You can just download the .apk file using the web browser, go into downloads, and choose it. That should install the app. - Once you have the sdk set up, you can connect to the computer and run "adb install -r app.apk". (This also requires you to enable U > Is the web cam supported? I'd guess not. My device has one, so it'd be > neat if it was working. I wonder if we can use normal linux video interface > (then we can use the code included in pygame already) or if we'd need to use > some other API. > I don't believe that the NDK supports accessing the camera directly. So we'd probably have to use JNI to access the camera. > What do you think of including other common game modules? For example, > numpy, pybox2d ( http://code.google.com/p/pybox2d/ ), pyaudio, etc. > Is there a chance to get ctypes working? Or is that not possible with the > python? It probably makes sense to have a way of including these modules, if they can be cross-compiled. With the new model (where each application ships with its own copy of python and pygame), it probably makes sense to have a way for people to choose which modules should be included. That's what I'm doing with the Ren'Py-specific modules. At the same time, convincing Python to cross-compile is something of a challenge, since there isn't a supported way of doing so.
[pygame] Pygame Subset for Android 0.9.2 Released
After spending the long weekend on the project, I'm pleased to announce the release of version 0.9.2 of the Pygame Subset for Android, which allows one to use a large subset of Pygame to develop Android applications. The new release is available from the Android Market, or at least will be in a few hours. Documentation is available from the new website: http://pygame.renpy.org This release features a new packaging tool, which generates stand-alone packages. It also adds support for developing on Windows, and for the icon, splashscreen, and permissions to be specified on a per-application basis. Hardware support is improved, with it now being possible to control vibration, and to read the accelerometer. Finally, this release fixes some bugs. Behind the scenes, there were several changes to how PGS4A is developed. The same source code is used for the launcher package, the packaging tool, and the Ren'Py equivalents of the same. This should make it easier to release new version in the future. I've also moved the project to a model where PGS4A is included with applications that use it. This means that I can release new versions of PGS4A without having to worry about breaking old applications. While applications written using 0.9.1 are still supported (and will be indefinitely), I recommend updating them to use 0.9.2. Note that the arguments to build.py have changed. Finally, there is a new PGS4A forum, which is probably the best place to ask questions: http://pygame.renpy.org/forum/ Thanks to everyone who gave feedback about version 0.9.1. I've integrated most of the feedback from the older versions, but if you didn't have your issue addressed, please email me or post on the forum. (Chances are I misplaced it.) Since releasing is now easier, I can act more quickly to get releases out, if need be.
Re: [pygame] Slide Puzzle For Android
On Tue, Feb 15, 2011 at 10:18 AM, Nikhil Murthy wrote: > I have installed the slide puzzle for android on my Olive Pad to test out > pygame for the android, and there are two problems with it. The first is > that when I launch it from the applications screen and then press the home > button while it is still generating a puzzle, the home screen displays, but > it seems that the application screen reads where I touch. The second is that > it does not prevent the android from turning off while running. > I will look into these two. I suspect that the first may just be incorrect handling of the pause and resume events. The second is because we don't take out a wakelock. That should be fixed in the next release. > I was also wondering if there is any way that I can work on improving > pygame for the Android. If nothing else, I was anyway about to start a game > for the Android, but if there is any useful work that I can do otherwise, I > would really be interested in helping. > I'm probably going to put together a forum for the android port this weekend. I also plant to spend the next few days improving the port. Among other things, I'd like to figure out how to let people distribute the android port as part of their app, so that users don't have to deal with a second download.
Re: [pygame] speculation: a JIT for Pygame
Is spending a lot of effort on software blitters the right strategy for pygame? It seems like SDL 1.3 is moving in the direction of API-based rendering, which wouldn't benefit much from new software blitters. I'm not sure it makes sense to make pygame bigger and harder to compile, only to duplicate functionality provided by hardware. By API-based rendering, I mean things like OpenGL and DirectX, which generally are accelerated by hardware. But you also have renderers like Mesa, which (IIRC) is moving to use LLVM to accelerate blitting, as proposed above.
Re: [pygame] Pygame Subset for Android 0.9.1
On Fri, Jan 7, 2011 at 5:40 PM, Alex Nordlund wrote: > On Thu, Jan 6, 2011 at 5:30 AM, Tom Rothamel wrote: > > I've also made available a packaging tool that can be used to create > Android > > packages from Pygame games. > > Do you have any networking support in it? > If you mean the packaging tool, no, I haven't included that. Google recently updated the maximum package size to 50 MB, which should be large enough for most reasonably-sized games. What I'll probably do sometime in the future is to add the networking permission to pygame, so that a larger game could run a downloader to grab its own data files.
Re: [pygame] Pygame Subset for Android 0.9.1
On Thu, Jan 6, 2011 at 1:35 PM, stas zytkiewicz wrote: > Do we discuss pysubset here or is there a dedicated ML ? > At least for now, why don't we discuss it here? We can always move when the amount of traffic increases. > Do you plan on providing some "cookbook" for code samples and examples ? > I suspect we run into problems that would have some common solutions and > it would be nice to post them somewhere. > That's a good idea - when I get a chance, I'll set up a wiki or something. > The python module Configparser isn't included, is it possible to include > it ? > I haven't figured out which parts of the standard library should be included. For pure-python modules, even if the module isn't included, it can be used by including it with the app, so that might be the better approach for rarely-used modules. (Now the question is - is configparser rarely used?) Is there support for the android sqlite dbase ? > No. I don't believe that's accessible from the NDK.
[pygame] Pygame Subset for Android 0.9.1
After taking a break for the holidays, I have released version 0.9.1 of the Pygame Subset for Android, which makes some of Pygame's functionality available on Android devices. This release adds support for packaging applications, and is the first release to be made available on the Android Market. I've also made available a packaging tool that can be used to create Android packages from Pygame games. The tool has only been tested on Linux, and requires you have Python, the JDK, Ant, and the Android SDK installed. Documentation and downloads are available from: http://www.renpy.org/pygame/ I plan to keep compatibility between this and future versions, and I believe that this is now ready for use, at least for noncommercial games. (The packaging story for commercial projects isn't there yet.)
Re: [pygame] Pygame for Android
On Mon, Dec 20, 2010 at 4:12 PM, wrote: > Re: [pygame] Pygame for Android > I am porting over a game. Will I be able to put it on the Android market? > Thanks for all that you have done. I will send you feedback soon! > > Yes. Right now, I'm still trying to get the packaging story figured out. At least right now, it's not ready for commercial games, but I think free ones are close to ready to go, once I upload the pygame subset package to the market. (I'm waiting for more testing feedback before uploading - it's a bit of a chicken-egg scenario for now.) Right now, the packaging test for Ren'Py is ongoing - you can see an example of what we have here: http://lemmasoft.renai.us/forums/viewtopic.php?f=32&t=8673 Everything is pretty much parameterized so that tweaking a few strings is enough to get it working for pygame as well.
[pygame] Re: Pygame for Android
I've released a new version (0.9) of the Pygame Subset for Android, which is my project to develop a Pygame release for Android. This is getting close to being releasable, I think, at least for the early adopter crowd. (Thanks for the website mention.) I've changed the name of the project to "Pygame Subset for Android", in order to not mislead people as to what the project is about. Not every python and pygame API is supported, and many don't make sense on the Android platform - so I'm picking and choosing what to implement. There's a new web presence, at least for now. http://www.renpy.org/pygame/ I'm not sure if this should be the permanent location, or if it makes sense to make this part of the regular pygame website. Anyway, the website tries to explain how to port simple games. There are a lot of changes in this version: - The project has been refactored a bit, so it's plausible to have a single instance of pygame on a phone, and then have multiple game downloads use it via intents. That last part, the packaging story, isn't implemented yet - I want to have some games before I put time into that. The org.renpy.android (Ren'Py for Android) and org.renpy.pygame (Pygame Subset for Android) projects now share 100% of the code, with just data files different. This simplifies long-term maintenance, as releases of both will be easy. - It works in the emulator, as well as anything works in the emulator (that is, slowly). While it's still better to test on an actual device, the emulator is used. (Thanks to stas for reporting this.) - There's a new android_mixer module that is a clone of pygame.mixer. While I don't want to try to port across the dependency-heavy SDL_mixer stack, I think this is the next best thing. - It's now possible to choose if a game runs in landscape or portrait orientation. - There's a project selector, that allows the user to choose between multiple pygame projects stored on their sd card. - The new android.map_key function lets you map an android key to a pygame keysym. - The splashscreen works better. - There's some documentation. I think the next step from here is to port some games. To do this, I'd like it if people could volunteer their time and projects. I'm especially looking for games that are suited to a touch-oriented platform - once where only mouse clicks and drags matter, essentially.
Re: [pygame] Pygame for Android
On Mon, Dec 6, 2010 at 10:49 AM, Stuart Axon > wrote: Wow, super cool - I guess it has python inside it? > Is it now possible to make android apps with python like this ? Yes. The basic strategy is to use JNI to communicate between Python and Dalvik. libpython2.6 is distributed as part of the package, along with pygame. For now, the launcher is an app that runs code it finds on the sdcard. At some point, I'll try to add the ability to bundle the launcher and a project together as a single app. (This is made a little difficult by android changing the names of certain classes it generates based on the name of the application.) On Mon, Dec 6, 2010 at 11:16 AM, stas zytkiewicz wrote: > Are you planning to eventually port the pygame.mixer ? > I'm not sure what the strategy for this would be. At the very least, I'll document the sound playback code I have now - and perhaps I'll try to write a compatibility layer. René Dudfield wrote: > It would be good to merge your changes in to pygame subversion. Do you > already have subversion access? > I don't, but I don't think it's necessary - there weren't any changes to pygame required. Once SDL and Python work on a platform, pygame works as well. I've released a version 0.2 to: http://www.renpy.org/android-test/pygame_for_android-0.2.zip (Let's retroactively call the first version version 0.1.) This fixes a local reference leak in the sound code which would cause a crash after 255 sounds were played. I've also put the source code up at: https://code.launchpad.net/~renpytom/renpy/pygame-for-android Well, this is less source code, and more a collection of build scripts and various other project files that are required to convince everything to cross-compile and play well together.
[pygame] Pygame for Android
Hi. I'm the creator of the Ren'Py visual novel engine (http://www.renpy.org), a tool for digital storytelling. Ren'Py has been using Pygame since at least 2004. For the past month or so, I've been porting Ren'Py to the Android platform. A few days ago, I had the first success. This required porting Python and Pygame to Android. (I used an existing port of SDL to Android.) As I don't believe I've seen a port of Pygame to Android, I thought it would be useful if I broke out the pygame support into its own distribution. The result is Pygame for Android, which can be downloaded from: http://www.renpy.org/android-test/pygame_for_android-1.0.zip Despite the number in the URL, this is far from a 1.0 release, having just begun testing. There is essentially nothing in the way of documentation or error handling - I'm releasing this publicly just to show that the project has begun. It requires an Android 2.0 or higher device, with working OpenGL support. To use it, unzip the zip file, install PygameLauncher-debug.apk on your device, and copy the pygame/ directory to the root of the device's sd card. Then run the launcher icon. After showing the Pygame logo for a few seconds, a small test program is loaded and run. The test program can be changed by editing /pygame/main.py on the sdcard. main.py is imported as a module, and then has its main function called - so code should live in the main function. The main.py file has a few comments in it. The functionality included is largely selected by what I use in Ren'Py. Most notably, the mixer module is not included - the android_sound module uses the Android media player code, which potentially might use hardware acceleration. My eventual plan for this, apart from bug-fixes and documentation, is to put together a launcher, that allows users to select from projects that live on the SD card. Again, this hasn't been tested on may devices - so feedback is encouraged. I'll try to get the full source code up shortly. The following modules are available in this release, although many of them have not been tested thoroughly. android android_sound pygame.base pygame.bufferproxy pygame.colordict pygame.color pygame.compat pygame.constants pygame.cursors pygame.display pygame.draw pygame.event pygame.fastevent pygame.font pygame.gfxdraw pygame.imageext pygame.image pygame.__init__ pygame.joystick pygame.key pygame.locals pygame.mask pygame.mouse pygame.overlay pygame.rect pygame.rwobject pygame.sprite pygame.surface pygame.surflock pygame.sysfont pygame.time pygame.transform pygame.version _abcoll abc aliases array ast atexit base64 bisect binascii calendar cmath codecs collections compileall contextlib copy copy_reg cStringIO cPickle datetime difflib dis dummy_threading dummy_thread encodings.__init__ encodings.raw_unicode_escape encodings.utf_8 encodings.zlib_codec errno fcntl fnmatch functools __future__ genericpath getopt glob gzip hashlib heapq inspect itertools keyword linecache math md5 opcode optparse os operator parser pickle platform posix posixpath pprint py_compile pwd Queue random repr re select sets shlex shutil site socket sre_compile sre_constants sre_parse ssl stat StringIO string struct subprocess symbol symtable strop tarfile tempfile textwrap _threading_local threading time tokenize token traceback types UserDict warnings weakref webbrowser zipfile zipimport zlib
