Re: [pygame] Best instructions for a Pygame setup on OS-X?
On 15-02-25 12:19 PM, Paul Vincent Craven wrote: See the 'mac installation' part of this section: http://programarcadegames.com/index.php?chapter=forewordlang=en#section_0_1 Paul Vincent Craven Thanks, that is helpful in that it shows what people are doing, but it still seems complex for a novice child. I'll likely point any OS-X users at that and we'll hope. Take care, Mike On Wed, Feb 25, 2015 at 9:24 AM, Mike C. Fletcher mcfle...@vrplumber.com mailto:mcfle...@vrplumber.com wrote: Hi all, I've got a computer club (grade-school) starting up soon, and I'd like some advice wrt how students should set up OS-X machines for Python + Pygame? Should we use the python.org http://python.org OS-X installer or the built-in python? Is there a particular combination of Python and Pygame installers which works reliably and doesn't require a lot of fiddling (again, these are complete novices). I'm more interested in reliable operation, easy setup, etc. as distinct from the ultimate hacker setup, as they will be doing this on their machines at home, rather than the machines in the lab/club. Thanks for any advice, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
[pygame] Best instructions for a Pygame setup on OS-X?
Hi all, I've got a computer club (grade-school) starting up soon, and I'd like some advice wrt how students should set up OS-X machines for Python + Pygame? Should we use the python.org OS-X installer or the built-in python? Is there a particular combination of Python and Pygame installers which works reliably and doesn't require a lot of fiddling (again, these are complete novices). I'm more interested in reliable operation, easy setup, etc. as distinct from the ultimate hacker setup, as they will be doing this on their machines at home, rather than the machines in the lab/club. Thanks for any advice, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] PYGAME EXE runtime or segmentation error
On 13-02-07 09:49 AM, Radomir Dopieralski wrote: You can try to strategically place a couple of print statements to see where exactly it is crashing. My bet is the font loading code, as I had problems with that on Windows before, but it's hard to say anything before you actually have a minimal working example. python -m trace -t your script Is often easier than manually adding print statements. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Alternate to graphics modules
On 13-02-06 06:43 PM, Richard Jones wrote: On 7 February 2013 10:29, Ian Mallett geometr...@gmail.com wrote: On Wed, Feb 6, 2013 at 4:20 PM, Richard Jones r1chardj0...@gmail.com wrote: You'd better start writing then :-) At some level, you need to interface with the graphics drivers. Since Python is an abstraction layer over C, this means either writing in C (not Python), or using a package that does that for you. You must use some package in Python to do low-level graphics--whether you write it yourself or no. For a package that gives you low-level access, my recommendation is PyOpenGL. It's lower-level than PyGlet and much cleaner, I think. That's not quite right. PyOpenGL and pyglet exist at about the same level architecturally. PyOpenGL does not provide an OpenGL context - you need another library (like pyglet or pygame) to provide that. Minor note: PyOpenGL does provide an OpenGL context (via GLUT), it's just not a very elegant or modern one :) . It *can* work with almost any external GUI library as well, but for demos/learning GLUT is often acceptable. Have fun, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] PYGAME EXE runtime or segmentation error
On 13-02-07 12:38 PM, Steven Sabatino wrote: That trace statement only helps me if the script is failing not the EXE ? Oops, missed that it *only* failed in the EXE. You'd probably need to use the programmatic interface then ( http://docs.python.org/2/library/trace.html#programmatic-interface). Or just prints if you prefer. Sorry, should have read the original post more closely, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] SGC 0.1.4 Released
On 12-06-10 03:28 AM, René Dudfield wrote: Great! I like how you have integrated the GUI events with a normal pygame event loop: http://program.sambull.org/sgc/tutorial.events.html For example, a quit button could work like the following: if e.type == QUIT or (e.type == GUI ande.widget == quit_button): raise SystemExit() Could the tutorials be based on examples? Then people can run the example, and learn that way as well. I believe one of them is already (the helloworld.py tutorial). Making all of the tutorials example code does sound like a good idea. You might want to consider putting the examples in sgc.examples with relative imports, so they are easier to run. Likewise, consider adding your unit tests into somewhere like sgc.tests. Keep in mind, that then the user of the library needs to *delete* them from the library when they copy the library into their game (or have extra code and data-files in their project). (Sam moved the examples *out* at my suggestion, actually). If the examples get beyond a few trivial files (which I'm hoping they will, as they begin to show how to use custom images and the like), then that may be a non-trivial size. Similar issue for the unit tests; if there are enough to be worthwhile they'll be a non-trivial amount of code, likely with quite a few data-fixtures. As for relative imports; I'm not sure I follow the logic there. If sgc is on the path (either because you ran setup.py install/develop or because you are in the root source-code directory), then the examples should all run. If it's not, then a relative import doesn't, AFAIK, work (that is, from .. import X will just report Attempted relative import in a non-package)? Anyway, just my thoughts, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Student summer(or winter) of code projects, $5000 from google.
On 12-04-03 11:01 AM, Sam Bull wrote: On Tue, 2012-04-03 at 09:26 -0400, Mike C. Fletcher wrote: We need more concrete details for the proposal. Looking through the code on Launchpad: * you don't seem to have a setup.py or similar traditional installer; that would be a requirement for broad acceptance o even those who are going to copy your code into their trees likely want to experiment with it first To be honest, I'm not entirely sure what a setup.py installer should do. The only thing you need to use the code is to make sure it's importable, either by putting it in the top-level of your project or putting it somewhere PYTHONPATH can find it. I'll be happy to create some kind of installer if it's needed. I would be interested in creating deb and rpm packages to install it globally, if someone can give me tips on how to do this. The setup.py basically allows someone to do: $ pip install sgc and have the package show up on their machine (likely in a virtualenv) so that they can start following along with the tutorial. It also allows you to do: $ python setup.py sdist register upload to release a new package automatically on PyPI. For a package such as yours it should be approximately 20-30 lines of (largely boilerplate). RPM and DEB packaging likely isn't as critical, as most people seeking to make the package part of their game are likely to copy the tree into the game before distribution. That said, both of those packaging tools work best when there's a setup.py available, so that you can use all of the standard, automatic mechanisms specifically set up for Python distutils/setuptools packages. * the selection of widgets is fairly sparse o I don't know that that is really a *bad* thing, games do tend to use a fairly sparse set of widgets With the core of the toolkit stabilising, it is fairly easy to add additional widgets. The radio button and toggle button were created by a friend last week with only a little help from me. It was about a day's worth of work for each widget. With the developer documentation completed I'm convinced that any developer could create new widgets. I still need more widgets for my own games, so I will be adding more sooner or later either way. Other developers working on the library is good to know, that should be mentioned *in the proposal* (you are now covering the idea of others developing for it, but I don't see any mention that others have worked on the project in the proposal). * there doesn't *seem* to be a theme/skinning mechanism o that is, how would I go about making my buttons look like flaming ovals instead of rectangles in order to match my flaming-eggs game? That is a feature that is not fully documented or tested, and a little buggy. This is one of the things I will be completing early on for GSoC. If you'd like to know how it works (or almost works), then the first argument you pass to a widget can be a tuple containing the size, but you can instead pass in a pygame.Surface object, and it will use that surface to draw the widget. There is a slightly more complex option using a dictionary to specify images for different states, such as the up, over and down images of a button. I see the section in the new proposal. o how would I control menu layouts (position, adding preview windows to the right side, etc) * menus don't *seem* to have any keyboard control (at least, none I was able to trigger in the test app) Menu layouts need some more work to be more customisable. At the moment you can only add widgets in a vertical manner (and the format for it is not documented yet). Keyboard support works with TAB, one of the minor features not yet implemented from the list on my spec is to add up/down key support. Ah, okay, had not thought to use tab there. Issues to address in the proposal (note: these are at least things you need to address, I'm not saying do or do not, but provide your rationale): * Reaching a 1.0 release is not a sufficiently well specified goal (after all, you could increment the version number and upload to complete) o What will be accomplished (specifics, what $5000 worth of work needs to be accomplished, on what approximate time schedule)? + What metrics will be used to judge the attainment of the goals? + What level of documentation is required? + Are you going to produce tutorials or just references? + What level of testing is required? Right, I've added a rough timeline to the GSoC proposal, I will expand on it with more details of what the end result should be for each task. Much better now, though I'd still like to see a few more specifics (you'll never satisfy me, of course, I *always* want more specifics :) ). Documentation for individual widgets is done. I will add more tutorials to cover some other aspects
Re: [pygame] Extending OpenGL support in Pygame
On 12-04-05 12:00 PM, Santiago Romero wrote: YES! Very much! In my personal opinion, the lack of simple drop-in OpenGL support that works the same way as the existing Surface class is the biggest weakness of pygame. I don't have knowledge about OpenGL but if I remember correctly, textures (because with opengl your sprites need to be faces with textures, simulating the sprite itself) must be power of 2 in size (16x16, 32x32, 64x64, 128x128...). This introduces a handicap in the sprite sizes that maybe can't allow simple drop-in Surface-class replacement... But, yes, I also agree that the advantages are very important, specially that GPU rendering would allow really hi-res (hdready and fullhd games, even with multiple scrolls!) even in limited hardware (CPU power systems) such as tablets, and so on. Modern OpenGL systems can often handle Non-Power of Two textures (there are ARB extensions for this, and an ATI extension for rectangular textures), but for something like Pygame sprites you'd likely do a POT texture catalogue and pack your NPOT textures into that, using offsets into the catalog texture to get the correct sprite rendered for a given polygon (saves switching out the texture all the time as you render, which is a non-trivial performance hit, and allows you to render all of the geometry using the catalog (i.e. hundreds or thousands of sprites) in a single GL call). Movies need special handling. To be particularly useful, such a port should likely target approximately the GLES2.0 subset of OpenGL, btw. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Student summer(or winter) of code projects, $5000 from google.
On 12-04-02 02:08 PM, Sam Bull wrote: On Fri, 2012-03-30 at 22:51 +0200, René Dudfield wrote: If anyone needs help with a proposal, let us know. I'd like to do some more work on my GUI toolkit. I know it's not directly working on Pygame, but I think it will greatly benefit the community. I'm going to write a proposal with a brief overview of the project, and then link to my project specification. If anybody would like to review the specification, you can find it at http://sambull.org/downloads/spec.odt The spec was initially written a couple of years ago, and much of the stuff on there has already been implemented. I've added an expansion point to the end to list additional things for GSoC 2012. As soon as I send this email, I'll be making another beta release of the project. So, if you would like to see the current state of the project, then please wait for my next email. We need more concrete details for the proposal. Looking through the code on Launchpad: * you don't seem to have a setup.py or similar traditional installer; that would be a requirement for broad acceptance o even those who are going to copy your code into their trees likely want to experiment with it first * the selection of widgets is fairly sparse o I don't know that that is really a *bad* thing, games do tend to use a fairly sparse set of widgets * there doesn't *seem* to be a theme/skinning mechanism o that is, how would I go about making my buttons look like flaming ovals instead of rectangles in order to match my flaming-eggs game? o how would I control menu layouts (position, adding preview windows to the right side, etc) * menus don't *seem* to have any keyboard control (at least, none I was able to trigger in the test app) Issues to address in the proposal (note: these are at least things you need to address, I'm not saying do or do not, but provide your rationale): * Reaching a 1.0 release is not a sufficiently well specified goal (after all, you could increment the version number and upload to complete) o What will be accomplished (specifics, what $5000 worth of work needs to be accomplished, on what approximate time schedule)? + What metrics will be used to judge the attainment of the goals? + What level of documentation is required? + Are you going to produce tutorials or just references? + What level of testing is required? o Are you going to speculatively convert some open source games to use the library to test it's ability to integrate into other projects? * I would like to see some real adoption/interest numbers. GSOC implies creating something that a significant collection of people are going to want to be using the project's results. o Is there a strong interest from third-party developers in the project [You say the library is ready to replace the other toolkits, but don't mention how many people are planning to switch from other libraries to yours as soon as it is stable] o Are other people using the widgets already, if not, what is stopping them? Do you have user feedback on this? If not, it might be useful to ask the Pygame community to weigh in on it over the next day or two. * What is the rationale for a new library over refining an existing/in-production library? That likely needs to be addressed explicitly and in detail. o Why not enhance PGU or the like with better keyboard support? What are the *specific* failings that make it's approach unworkable? Adding tab support or selection-in-text-boxes to an existing library sounds fairly workable, if that is their only failing. o Why not branch/fork an existing library to bootstrap development? o Why not borrow code from appropriately-licensed libraries? * If I understand correctly there have been at least half a dozen Pygame GUI libraries over the years. Devil's advocate says the problem isn't so much getting a GUI library written as keeping it maintained. o How does this project avoid tossing it over the wall (that is, finishing and abandoning the project)? o GSOC AFAIK prioritizes getting new developers into *existing* projects, building the community of developers. How does this project integrate into the larger community of Pygame developers? HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] PyOpenGL Release 3.0.0 (final)
Peter Gebauer wrote: Hi Mike! Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or Python extensions written in C to improve performance? Is there a possibility of mixing ctypes with Python extensions in C for the more critical parts? The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve performance. Yes, you can fairly freely mix C/Cython/Pyrex coded OpenGL-using extensions with PyOpenGL code. The current GL context is used by all PyOpenGL calls (well, the ones that don't explicitly specify contexts, such as those in GLUT or GLX). As for rewriting the core library, I doubt *I* will do another rewrite. But the fact is that someone could easily generate a new Cython/Pyrex wrapper without breaking a sweat. They would just then need to do all the project management and maintenance on the code-base, and I quit working on the SWIG code-base because of the maintenance headaches, so it's not really something I want to go back to. The use of ctypes means that we should eventually be able to run on all of Jython, PyPy, IronPython, Unladen Swallow and CPython with the core Python+ctypes-only implementation. Interpreters that actually *use* the ctypes annotations (PyPy) may eventually be able to use the fact of using ctypes to generate almost-C-level performance from the code. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] GSoC Easy simple software 3d
Ian Mallett wrote: There is an .obj loader on pygame.org already in the cookbook... There's also one in Pyglet with a modified version in OpenGLContext: http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/OpenGLContext/loaders//obj.py Regarding the proposal in general, it sounds fine. BTW, I can't realistically commit to being a full-time mentor this summer, but I'd be willing to help out with mentoring and/or answering questions. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Pathfinding
John Eikenberry wrote: evil monkey wrote: I used this AStar in some of my games, and it works very well: http://www.pygame.org/projects/9/195/ ... http://zhar.net/projects/gameai/ There are a few other python implementations of A* that I know of as well. They are also linked to from that page. Productive has a slightly modified (IIRC faster) version of the A* at: http://arainyday.se/projects/python/AStar/ here: http://dev.laptop.org/git?p=projects/productive;a=tree;f=Productive.activity/astar;hb=HEAD we wound up using a hybrid system, where we'd try dead reckoning first, then try A* . Have fun, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Shaders and Examples not Working
Ian Mallett wrote: Hi, yes, I noticed that for some reason my computer doesn't require this, but nearly everyone I've talked to seems to need it. Is there a reason why glutInit() is required on some computers and not on others? Ian GLUT has some book-keeping stuff that it needs initialized, and IIRC it needs some help with shutting down that we set up in glutInit. Basically if you are calling *any* glut function you need to have glutInit called to be sure it will work. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Shaders and Examples not Working
Ian Mallett wrote: Hi, I get (adding the necessary import ctypes at the top): AttributeError: function 'glCreateShader' not found Thanks, Ian You'll likely need to use the extension-based version (ARB.shader_objects). If you have a modern Nvidia/ATI card it will almost certainly have shader support available in an extension. Note that some older cards (e.g. integrated graphics chips) only support the lower-level APIs (i.e. you can't use GLSL with them). BTW just tested this demo, it works fine with PyOpenGL bzr head (on Linux, with a reasonable Nvidia card): http://bazaar.launchpad.net/~mcfletch/pyopengl-demo/trunk/annotate/2?file_id=shader_test.py-20080923005140-67c17kywpwxa2usj-25 HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Shaders and Examples not Working
Ian Mallett wrote: Perhaps I'm doing something wrong--I get another error when using the OpenGLContext example: File C:\dev\Python25\Lib\site-packages\OpenGLContext\arrays.py, line 2, in module from vrml.arrays import * ImportError: No module named vrml.arrays My intention was be to suggest you just look at the code for the sample. OpenGLContext's setup requires rather a lot of dependencies. I have making installing those dependencies easier on my list of things to do, but little time to address that list. Good luck, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Shaders and Examples not Working
René Dudfield wrote: Hi, at one point they did work... However pyopengl 3 is still in beta and has been changing a lot recently... causing some things to fail. There's been a recent fix in cvs to get them working on windows again (I think your platform). Actually, I'm using bzr these days for PyOpenGL. I know that recently a bunch of shader examples were added to cvs too. So... use pyopengl cvs, and help out with bug reports and patches :) Mike is pretty responsive over there, but if you have any patches I can apply them as well if you need. I can't claim to be all that responsive, but I try. There is working code in OpenGLContext/tests/shaderobjects.py which compiles and renders with a comic shader. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
[pygame] Re: [OLPC-Games] PyQNet project on Launchpad
Noah Kantrowitz wrote: Mike C. Fletcher wrote: Hi all, Those of you who were at PyCon in Chicago for the OLPC sprint may remember Phil Hassey's impromptu lecture on how to build a networking API [1]. I've been hacking together a preliminary implementation of something like that API and have just moved the project to Launchpad[2] so that other people can play with the code. It's definitely not finished yet, so if you want to work on something low-level and network-y, feel free to play. A similarly designed (and much smaller) library is also up at https://coderanger.net/svn/school/2007/fall/egd/magnoball/pygamenet.py . Also a WiP. PyQNet is split over 8 modules, but the actual number of code-lines in the library (excluding the tests) is pretty small (640 incl. comments and docstrings), pygamenet is around 591 when you take out the comments. Though PyQNet is likely to grow substantially once I get all the features I want implemented. The difference in size currently is likely because PyQNet is implemented as UDP with ordering and retry controlled by the Python code instead of using TCP-level operations. The UDP operations should allow us to code adaptations into the library to optimize for low-latency game-y operation. pygamenet.py seems nice, but it's not really the direction I was looking to explore. I don't see a problem with having both libraries under development. Have fun, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
