Re: [pygame] Drawing efficiency question
On 2/03/22 12:02 pm, Irv Kalb wrote:> I'm wondering if my code to check if an element is within the viewable area, is actually doing more work than not bothering to check at all. If the drawing of each object is just a blit call, then your checks are probably just duplicating what pygame is already doing itself much more efficiently. The only way to find out for sure is to try it, which it sounds like you've already done and found it only makes a small difference. To do better you'll need some kind of spatial index to quickly find objects that might be in view. A simple way would be to divide the world into a grid of cells, each one about the size of the window, and maintain a collection of objects in each cell. Then you can draw just the objects in cells that overlap the window. -- Greg
Re: [pygame] Time to load font with pygame.font.SysFont on Mac
On 5/04/21 9:29 am, Irv Kalb wrote: If I load a font like the system font using None with a call to pygame.font.font, it happens almost immediately. But if I load a font by name using pygame.font.SysFont, it's taking over 7 seconds on my Mac to load. It doesn't seem to matter which font I try to use. Is it slow every time you run it, or are subsequent runs faster? I don't have an OSX 11 system handy to try it on, but I tried it on 10.12.6 and got this: First run: Loading System font took 0.015527009963989258 Loading Arial font took 4.879987001419067 Second run: Loading System font took 0.00061798095703125 Loading Arial font took 0.05048775672912598 Third run: Loading System font took 0.0006070137023925781 Loading Arial font took 0.0516507625579834 So for me it took about 4.9 seconds the first time, but was a lot faster once it was warmed up. -- Greg
Re: [pygame] Confusing values from mixer.Channel.get_sound()
On 26/12/20 10:57 pm, Pavils Jurjans wrote: As you can see, in my case the channels point to different addresses, but still behave as if they are linked. Maybe it is important on what platform I am running this code? Perhaps. I suspect they still refer to the same channel id, even though they're different objects. Unfortunately there doesn't seem to be a way to get the channel id from a channel object, so I can't think of a way to test that. I am aware of the channel end_event but since the number of custom event IDs is very limited, I had to implement my own solution Yeah, it's annoying that you can't specify any other data to attach to the event. That part of the API doesn't seem to have been thought out very well. -- Greg
Re: [pygame] Confusing values from mixer.Channel.get_sound()
On 26/12/20 3:38 am, Pavils Jurjans wrote: I first play a sound (get the channel object in return), and let it play until the end. channel.get_sound() returns None, as it should. Then I play this sound a second time (storing the returned channel object in another variable). While the sound is still playing, if I query the first channel.get_sound(), I get the reference to the sound object. Because you started playing the second sound after the first one finished, it re-used the same channel. I added a couple of lines to print out the repr of the sound object returned by each play() call. This is what I got: Play the sound on channel1 channel1 = After 1 second: channel1 - True After 7 seconds: channel1 - False Play the sound on channel2 channel2 = After 1 seconds: channel1 - True , channel2 - True After 4 seconds: channel1 - True , channel2 - True After 7 seconds: channel1 - False , channel2 - False You can see that channel1 and channel2 are actually the same channel object. I don't think there's anything you can do about that; you'll have to re-think your method of detecting whether a sound is still playing. Note that you can use Channel.set_endevent() to arrange for an event to be posted when a sound finishes playing. -- Greg
Re: [pygame] Bug: Circle tearing with mouse clicks within the window.
On 15/12/20 4:00 pm, Michael Baca wrote: The following code, when run, causes an issue where the circle starts to tear as it moves across the screen You could try screen = pg.display.set_mode((600, 400), flags = pg.HWSURFACE | pg.DOUBLEBUF) According to the docs, this will cause screen.flip() to wait for a vertical retrace. -- Greg
Re: [pygame] Can the pygame infrastructure be used for non-graphical text-mode games?
You might like to look at these: https://pythonhosted.org/tale/ https://github.com/lordmauve/adventurelib -- Greg
Re: [pygame] Can the pygame infrastructure be used for non-graphical text-mode games?
On 18/06/20 12:40 pm, pjfarl...@earthlink.net wrote: Is it possible to use the pygame infrastructure to implement text-mode-only games? Without having to pick window sizes and resolutions and set fonts and font sizes, etc., etc., on a graphical surface? Or am I just looking at the wrong library to use for such games? I think you're looking at the wrong library. Pygame is all about graphics (and sound and music). It can produce text, but only by turning it into graphics using some fairly low-level APIs (essentially just "draw this string of chars here using this font and this size"). In my opinion, the best way to do an adventure-style text-only game in this era is to just use standard I/O and run it in a console window. If you want more control over the layout of the text (e.g. showing a status bar at the top of the screen and things like that) you could look into a library such as curses. By the way, do you know about any of the modern text adventure creation systems such as Inform, TADS and ALAN? There is still a very active community using and working on these. They're not based on Python, but they could be useful as a source of ideas on how to structure Python-based text adventure games. -- Greg
Re: [pygame] Python/pygame version compatibility
On 24/03/20 5:52 pm, Irv Kalb wrote: But I've read here that Python 3.8 doesn't, or at least didn't, work with the current version of Pygame. Is this still true? I've just been through the process of trying to get pygame 1.9.6 working with python 3.8 (mainly because they're the current versions and nobody told me to do otherwise). I had a few problems, but they were mainly about getting the right libraries in the right places. So far I haven't noticed any incompatibilities between python and pygame. I compiled both python and pygame from source on MacOSX Sierra. I don't know what the experience would be like for someone installing them from binary distributions. Would it be best to have my students use the same set up as me with Python 3.7.x ? If you have a combination and installation procedure that you know works, it would seem like a good idea to recommend it to your students. -- Greg
Re: [pygame] pygame.display.flip slow
On 20/02/20 8:57 am, Nuno Maltez wrote: when I run my test program, Machine B reports FPS > 200, and pygame.display.flip taking 0.002 per call, while machine A reports FPS < 60, and pygame.display.flip taking 0.016 per call. This looks to me like machine A is synchronising its flips with the monitor's refresh rate, but machine B is not. Why that would be when you're creating the surface with the same flags I don't know. Maybe a difference in the display driver? -- Greg
Re: [pygame] Initializing and Reinitializing Instance variables
Irv Kalb wrote: I hadn't thought of the extra "Session" object, it sounds like an interesting approach. However, I'm looking for a clear solution that I can teach to students who are just learning about OOP. Don't think of it as an extra session object, rather think of it as creating a new Game object for each game. I think that's actually a clearer and more OO way to approach the problem than trying to clear out and re-use an existing object. -- Greg
Re: [pygame] Initializing and Reinitializing Instance variables
mspaintmaes...@gmail.com wrote: class ApplicationContext: def __init__(self): self.session = GameSession() def reset(self): self.session = GameSession() Nope, this doesn't solve your fundamental problem of getting rid of a duplicate assignment, I'd probably do it like this: class ApplicationContext: def __init__(self): self.session = None reset() def reset(self): self.session = GameSession() -- Greg
Re: [pygame] Practice Game code ?
You could also try PyWeek competition entries. -- Greg
Re: [pygame] Some way to pickle or otherwise save a pygame.mixer.Sound object?
Alec Bennett wrote: 16 bit wav files. 1411 kbps. About 5 megs each but one is very long (a 13 minute medley of all of them, 133 megs). Okay, I didn't realise they were that big -- I was thinking short horn sounds, not substantial pieces of music! You bring up a good point, I can certainly make them mono. Also maybe 8 bit -- a horn probably doesn't need terrifically high sound fidelity. But surely there must be some way to save a preloaded state? That's over 200MB altogether, which may be why it takes so long. Have you tried simply reading all the files to see how long it takes? If that takes just as long, then reading a preloaded state isn't going to gain you anything -- you've still got over 200MB of data to read in. You could also try using a compressed format such as mp3 or ogg/vorbis to see if it loads any faster. Another thought -- instead of loading the medley as a separate file, could you assemble it on the fly from parts of the others? Another other thought -- instead of storing entire tunes as sound files, just use samples of the horn sounds and write a sequencer to play the tunes with them. -- Greg
Re: [pygame] Some way to pickle or otherwise save a pygame.mixer.Sound object?
Alec Bennett wrote: since it needs to load each of the 20 sounds on startup it takes about 30 seconds to load. I'm running it on a Raspberry Pi, which doesn't help of course. How big are the sound files? Unless they're really enormous, that sounds excessive, even for an R. Pi. What format are they in? If they're in some kimd of compressed format, try saving them as .wav files. That might be faster to load even though the file is bigger. -- Greg
Re: [pygame] Only first call to Sound.play() is working
Pablo Moleri wrote:
import time
import pygame
pygame.mixer.init()
sound = pygame.mixer.Sound("my_sound_file.wav")
sound.play()
time.sleep(10)
sound.play()
If that's you're entire program, I'd say it's finishing before
the second sound gets a chance to play. The sound.play() call
only *starts* the sound playing, it doesn't wait for it to
finish.
Try putting another time.sleep(10) after the second play.
--
Greg
Re: [pygame] pygame.key.get_pressed() works unpredictably
gmail aprekates wrote: The problem i get with the following code is that the rect moves as if i pressed a key more than one times. For me, it works the way I would expect from the code, i.e. the rect continues to move as long as an arrow key is held down. If instead you want it to move one step each time you press a key, it would be better not to use get_keys at all, and just drive it from key events, the way you're handling the space key. But is vague how that 'state' is created, accessed and how it's changed. It returns a map telling you which keys are being held down at the moment you call it. That's what it means by 'state'. -- Greg
Re: [SPAM: 6.600] Re: [pygame] Re: removing 'experimental' notice from pygame.math
Russell Jones wrote: IDK about physics, but AIUI, Z points from side to side, Y points down and X points diagonally; it's Λ that points up. Only if your computer screen is oriented vertically. If you're using a tablet in your lap, Λ points forward and Y points backwards. So obviously the code should interrogate the orientation sensor of the device it's running on, if it has one, to figure out the correct naming of the unit vector constants. -- Greg
Re: [SPAM: 5.011] [pygame] Re: removing 'experimental' notice from pygame.math
René Dudfield wrote: Length is also confusing because... length of the container. Yes, in Python terms the "length" of a vector should really be the number of components it has. (BTW, there's a similar problem in Python itself with using len() for the size of containers in general. I find the "length" of a dictionary to be a somewhat weird concept, because I don't think of it as a linear data structure. Even more so with sets!) -- Greg
Re: [SPAM: 5.011] Re: [SPAM: 6.600] Re: [pygame] Re: removing 'experimental' notice from pygame.math
René Dudfield wrote: So it might be nice to return the length(magnitude) there? BTW, I don't really like the name "length" for a function that returns the magnitude of an arbitrary vector. It only makes sense for vectors representing a physical distance; it's nonsense for anything else (velocity, acceleration, electric field, etc.) -- Greg
Re: [SPAM: 6.600] Re: [pygame] Re: removing 'experimental' notice from pygame.math
Daniel Pope wrote: Y points up in real physics? No, no, no. Z points up in real physics! -- Greg
Re: [pygame] Opening Python project in PyCharm - Mac
Alex Nordlund wrote: No, that's the toolbox, the toolbox app is free. It's also confusingly named :-) But does it do anything on its own? According to the web page about it, it's just something for managing their other tools, which are not free. If I'm wrong about that, and it actually has functionality of its own, then it's not just confusingly named, but very badly advertised. -- Greg
Re: [pygame] Opening Python project in PyCharm - Mac
Alex Nordlund wrote: The toolbox app from jetbrains already does that but better :-) Also a LOT more expensively, from the looks of their web site. -- Greg
Re: [pygame] Opening Python project in PyCharm - Mac
Leif Theden wrote: you could maybe create a context menu helper (i'm not familar enough with os x to advise how to do that) that launches pycharm with the correct path appended to the pycharm launcher. It looks like you should be able to do this using Automator: https://davidwalsh.name/mac-context-menu -- Greg
Re: [pygame] Building paths & pygame.image.load documentation
Ian Mallett wrote: Hmm I didn't know this, never really viewing Macs as suitable for development. Classic MacOS wasn't great for development, but MacOSX is a flavour of Unix, so you get all the usual developer comforts. -- Greg
Re: [pygame] Building paths & pygame.image.load documentation
Irv Kalb wrote: I started working in that environment in the days of Mac OS9. At that time, the Mac folder separator character was the ":" colon character. Yes, in those days it was vitally necessary to use the os.path functions for cross-platform code. VMS is another example of a system which had wildly different pathname syntax. We're fortunate right now that the three major platforms have partially-compatible pathnames. Whether that will continue in the future is impossible to tell. I didn't realize it but the character on a Mac is now the "/", same as the Unix character - probably changed when OS X came out. Yes, MacOSX is essentially Unix in many ways. I think either one will work on a Mac. If mean either "/" or ":", no, that's not true -- ":" is just an ordinary filename character in MacOSX, same as Unix. But, if you create a filename containng ":", the Finder displays it as a "/" -- suggesting there's still something in there somewhere that works with Classic MacOS style pathnames! When I started using Python, I thought it was very clever that I can use just the "/" character in Python, and Python seems to do whatever translation it needs to do to make the path work on the target system. Which is an illusion caused by some degree of conversion in the major platforms. -- Greg
Re: [pygame] Building paths & pygame.image.load documentation
Ian Mallett wrote:
As far as I know, the os.path version does a string conversion to the
platform-preferred way of specifying paths.
No, it doesn't -- that only happens if you use normpath():
>>> os.path.join("abc/def", "ghi")
'abc/def\\ghi'
>>> os.path.normpath('abc/def\\ghi')
'abc\\def\\ghi'
"\" was just not a good idea, and Windows ought to give up already
It's not just Windows itself that would have to give it up,
there's application software that (incorrectly) believes "\"
to be the only true path separator on Windows.
--
Greg
Re: [pygame] Building paths & pygame.image.load documentation
Irv Kalb wrote:
But then I point out how Python solves this issue by
allowing programmers to use the "/" character as the folder separator
character - and how Python maps that character into the appropriate
character for the operating system on which the program is running.
This is WRONG. Python does no such thing. You are seriously
misleading your students by telling them this.
What's happening is that most Windows system functions
accept either forward or backward slashes as path separators.
So *most* of the time you can get away with using forward
slashes, but there are situations where that won't work.
the documentation says:
You should use |os.path.join()| for compatibility.
My question is: Is there any reason to do it this way?
It's the only way that's guaranteed to work on all platforms
in all situations, so it's a good habit to teach and to get
into.
Any reason NOT to use:
ball = pygame.image.load('images/ball.png')
If MacOSX, Linux and Windows are the only platforms the code
will be required to run on, this will probably work. But you
should point out to your students that you're taking a
shortcut by relying on this.
--
Greg
Re: [pygame] Line Collision
gabrielslo...@gmail.com wrote: Hey, supose i have a Rect and a Line, i just want to see if the line intercepts the rect, is that possible somehow in a kind of optimized way For axis-aligned rectangles you probably want the Cohen-Sutherland algorithm: https://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland_algorithm If all you want to know is whether they intersect or not, you can just use the first part (calculating the outcodes and ANDing them together). -- Greg
Re: [pygame] How to prevent mouse initialization in Pygame
Роман Мещеряков wrote: I instruct pygame to not use X Window server (which, if I understand right, should set $DISPLAY environment variable), but to use framebuffer. Probably the framebuffer device is owned by root and only allows access by root. Changing the permissions on /dev/fb might let you avoid the need to run as root. -- Greg
Re: [pygame] take screenshots of desktop and any app running (even with direct3d, opengl, sdl, ...)
Martin Kühne wrote: There appears to be a glReadPixels(0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, pixels) function for that purpose in the OpenGL C library, maybe pyopengl has an equivalent function? That will only give you a snapshot of your own OpenGL drawing area, not anything else on the screen. Getting a full screenshot will need help from the OS and be very platform-dependent. -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
Lenard Lindstrom wrote: I was certain I had read about restrictions regarding a window's surface and a renderer. But I can't find anything in the SDL API docs. I don't know about SDL, but as far as OpenGL goes, usually the way it works is that a context can only be bound to one window (or part of a window) at a time, but it can be bound to different windows at different times, and can be bound to other things (textures, offscreen drawing areas, etc.) All that stuff is platform-dependent, though -- there's nothing in the OpenGL spec about it. -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
Lenard Lindstrom wrote: Unfortunately, the special parser machinery to support Cython includes is only implemented at the module level. It was never generalized to work in any code block. The include statement in Pyrex was something of a hack that I used for sharing declarations before the cimport mechanism existed. I regarded it as more or less obsolete after that and didn't develop it any further. You could put in a feature request to the Cython developers. -- Greg
Re: [SPAM: 5.011] Re: [pygame] Pygame for SDL 2, and how it may look.
Ian Mallett wrote: I like this idea a lot, modulo that you should also store the reference to the window. The Renderer would hold a reference to the window itself, so you would only need to keep a separate reference to the window if you wanted to use different renderers with it at different times, or switch one renderer around between different windows. You might actually want to do the latter. If the Renderer encapsulates an OpenGL context, using just one Renderer would make it easy to share the same set of textures etc. for all of your drawing. So we have two use cases. If you have just one window: r = Renderer(window = Window()) # do some drawing with r If you have multiple windows and want shared rendering state: w1 = Window() w2 = Window() r = Renderer() r.window = w1 # do some drawing with r r.window = w2 # do some drawing with r -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
Leif Theden wrote: While I have not personally tested it, there seems to be more evidence that windows can contain (use? manage?) more than one Renderer: If that's true, then it might make sense for the Renderer to have a 'window' attribute. The Renderer would then be the thing you keep a long-term reference to, and you would obtain the Window from it when needed. -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
Lenard Lindstrom wrote: However, after a bit of experimenting I find a window can have both a renderer and a display surface. In that case, I'd suggest the Window object should have 'renderer' and 'surface' attributes. If the Renderer or Surface keeps a reference back to the window, it should probably be a weak reference, so that they won't keep each other alive. If code that uses the Renderer or Surface obtains it from the Window when needed and doesn't store a reference to it long-term, then dropping the Window will cause the whole lot to disappear. -- Greg
Re: [pygame] Pygame for SDL 2, and how it may look.
Lenard Lindstrom wrote: Extension type WindowSurface would add an SDL window C pointer to its pygame.Surface parent. This window pointer cannot be factored out into a separate WindowBase parent class. And any methods which access that pointer will be specific to WindowSurface's C structure type. And consequently, it would be impossible to write code that generically works with either type of window at the C level without going through Python method or property dispatch. * Cython has an include statement. Unfortunately, include statements are not allowed in class declarations. Even if it worked, the effect would be no different from writing out a copy of the code in each class. You would still have two unrelated sets of fields with different offsets. Splitting it into two objects sounds like the best solution to me. Then you can have a Window object with the same interface whether it has a Renderer or a Surface attached, and a Renderer with the same interface whether it's attached to a Window or something else. -- Greg
Re: [pygame] Dirty rect overlapping optimizations
Ian Mallett wrote: I mean this in a fundamental, mathematical sense. With O(n) rectangles, you can produce O(n^2) regions that cannot be decomposed into fewer than O(n^2) disjoint rectangles. True, but that's a worst case, unlikely to be approached in practice. Also, for this application, there will be some minimum size of rectangle below which the overhead of decomposing it further would be a net loss. If you stop at that point, there will be an upper bound on the number of rectangles you're dealing with. -- Greg
Re: [pygame] Dirty rect overlapping optimizations
Ian Mallett wrote: Unfortunately, computing those rectangles is annoying, and also O(n^2) in the number of rectangles With the right data structures and algorithms, it doesn't have to be. Apple's Quickdraw had some very efficient ways of representing and operating on regions made up of collections of rectangles. There's some info and further pointers about it here: http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2010/8/29_Regions.html -- Greg
Re: [SPAM: 9.600] Re: [pygame] pygame with SDL2 proposal
Leif Theden wrote: For those just reading the thread and haven't voiced your opinion, please do so now. It would be nice if pygame 2 could have a pygame 1 compatible subset, because of the aforementioned tutorial materal etc. out there, and in the interests of users not having to relearn more than necessary. But only if it's reasonably possible to do so without either crippling the API or going to a lot of trouble in the implementation. I don't know enough about the differences between SDL 1 and 2 yet to tell how feasible it would be. -- Greg
Re: [pygame] timer callback into object?
Irv Kalb wrote: So, my specific question is this: Is there any way for an object to create a timer, that results to a callback within the same object? There's nothing built into pygame for doing that as far as I know. You'll have to build something yourself. -- Greg
Re: [pygame] New pygame.org website
Luke Paireepinart wrote: Regarding Angular, it's a bit of a mischaraterization to say there's equivalence between an angular search of content and ctrl+f. For one, with angular only matching content could be shown, and different metadata could be used for searching (search on title, description, library, author, etc.) Keep in mind that one can also use Google with a host name to search for things on a specific site. That often works better than whatever a site's custom search facility provides. -- Greg
Re: [pygame] Registration disabled.
Ian Mallett wrote: As has been explained before, the reason is due to a historical deluge of spam. Perhaps some explanation of the reason could be included in the message? As it is, this looks like a bug, so you can't blame people for reporting it as such, or for getting a bit frustrated when the apparent bug is apparently being ignored. -- Greg
Re: [pygame] Faster blitting
Ian Mallett wrote: I think the point is that in the case where you have a lot of small blits, the proportional overhead of the checks is more significant. If you have a lot of small blits, I'd expect the general overhead of Python code overhead to swamp everything else. -- Greg
Re: [pygame] Faster blitting
Leif Theden wrote: The fast_blit method would with the barest minimum of checking before calling the sdl blitting functions. Have you performed any measurements to find out whether the checking overhead is significant in the cases where the formats do match? Without evidence, I'm skeptical about that. -- Greg
Re: [pygame] pygame Event
Stuart Laatsc wrote: Well I don't really /need/ the __dict__ functionality, but it would be /convenient/ to have /and it is included/ in the official documentation. Are you sure you're not using an older version of pygame? If I remember rightly, Event used not to have '__dict__', only 'dict'. Pygame 1.9.2 seems to have both: >>> pygame.__version__ '1.9.2pre' >> e = event.Event(42) ['__class__', '__delattr__', '__dict__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__nonzero__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'dict', 'type'] >>> e.__dict__ is e.dict True -- Greg
Re: [pygame] Accessing C++ libs with ctypes
jcup...@gmail.com wrote: Have you looked at cffi? It's a modern replacement for ctypes which automates a lot of this stuff. Other possible approaches: * Write a C wrapper around the C++ API and call that using ctypes. * Use Cython to wrap the C++ API. -- Greg
Re: [pygame] display.set_mode opens oversized window.
mspaintmaes...@gmail.com wrote: I'm not an expert, but I think the idea is that you're not supposed to worry about having to scale your game up for people with super high resolution displays, which is why it does this. i.e. picking something that looks comfortable on your display will look equally comfortable on someone else's display whether it's 96 DPI or 192 DPI. That would be all right, but only if it's applied consistently to everything. E.g. a 100x100 pixel image blitted onto a display set to 108 dpi should come out as 150x150. I don't know whether pygame works that way or not -- I've never seen it do any kind of automatic dpi scaling. -- Greg
Re: [SPAM: 8.411] [pygame] GUI for pygame : ThorPy
Yann Thorimbert wrote: As many people did, I have been looking for a GUI for pygame. Naturally, I have found this page : http://www.pygame.org/tags/gui. Did you look at Albow? It doesn't seem to be listed on that page: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Albow/ -- Greg
Re: [pygame] Noob question: playing sounds
Philip Le Riche wrote: Well, this is strange. In /usr/lib/python2.7/dist-packages/pygame/examples there is sound.py. This must have worked for someone once, It still works for me, using pygame 1.9.2 with Python 2.7 on MacOSX 10.6. -- Greg
Re: [pygame] Re: SDL for Pygame Mac 64 - Almost there... Please help!
On 04/08/2015 05:53 PM, JeffreyDanowitz wrote: However, in my PATH I have /usr/local/lib and both libpng.dylib and libjpeg.dylib are there. In that case I would expect things to be able to find it without any help. I'm out of ideas at the moment, sorry, other than my earlier suggestion to try compiling with the framework version of SDL only. If I understand correctly, you haven't followed through with that yet. -- Greg
Re: [SPAM: 10.000] [pygame] Re: SDL for Pygame Mac 64 - Almost there... Please help!
JeffreyDanowitz wrote: When I remove the stuff from Homebrew I get: Using Darwin configuration... sh: sdl-config: command not found sh: sdl-config: command not found sh: sdl-config: command not found WARNING: sdl-config failed! /usr/local/bin/smpeg-config: line 45: /usr/local/opt/sdl/bin/sdl-config: No such file or directory /usr/local/bin/smpeg-config: line 53: /usr/local/opt/sdl/bin/sdl-config: No such file or directory Remove old build directory (force recompile) [Y/n]:n Hunting dependencies... SDL : not found Framework SDL found FONT: not found Framework SDL_ttf found IMAGE : not found Framework SDL_image found MIXER : not found Framework SDL_mixer found SMPEG : found 0.4.5 Framework smpeg not found Framework CoreMIDI found Framework QuickTime found PNG : found JPEG: found PORTMIDI: found FREETYPE: found 2.5.3 AVFORMAT: not found SWSCALE : not found So this is not good What do you think is wrong with that? It seems to be finding the framework versions of the SDL libraries. I don't think you need to worry about sdl-config, it seems to be part of the non-framework stuff and isn't needed to use the framework. Perhaps I have to recompile pygame completely (i.e. using pip and stuff like that) I've never used pip, so I can't help you with it, but I would recommend starting with a freshly unpacked copy of the source to make sure there's nothing hanging around from a previous build. Perhaps I need to make the /Library/Framework versions identical to the Homebrew installed versions and then things will just work? No, I still think it's a bad idea to have two versions of the libraries around. You should only need one or the other. I'm wondering whether it's nothing to do with SDL, but that it can't find libpng and libjpeg at run time. If you installed them using homebrew, they're probably somewhere unusual like /opt. What does your LD_LIBRARY_PATH contain? Does it include the directory where libpng.dylib and libjpeg.dylib are installed? -- Greg
Re: [pygame] SDL for Pygame Mac 64 - Almost there... Please help!
JeffreyDanowitz wrote: When I look at config.py and config_darwin.py and setup and setup.py, there are references to includes and stuff from where the SDL was installed by brew. However, there are references to the Framework in /Library/Framework. Can you show us the output you got from configuring pygame? It should tell you what libraries it found and didn't find. Also, be aware that to be able to load image files other than bmp, you not only need SDL_image, but also the relevant library for handling that format, e.g. libpng, libjpeg. If those libraries are being found, you should get the following lines in the output from ./configure: PNG : found JPEG: found -- Greg
Re: [pygame] Re: SDL for Pygame Mac 64 - Almost there... Please help!
JeffreyDanowitz wrote: IMAGE : found Framework SDL_image found PNG : found JPEG: found It seems to be finding both the framework and non-framework versions of the SDL libraries. Maybe that's confusing it? You could try removing the non-framework SDL libraries and see if that helps. -- Greg
Re: [pygame] Feature discussion, proposals
Mikhail V wrote: 1. It turns out that 32 bit surfaces is an overkill in most cases. Good that there is 8 bit mode. What evidence do you have of that? Have you done any benchmarking? - how does the indexed image is generally rendered? Is it like: it sends index array to video card and the card makes substitution? That would depend entirely on your system, and I would expect huge variations from one system to another. Even if using indexed images is a performance optimisation on *your* system, it's likely to be a pessimisation on someone else's. Personally I would forget about optimisation and only use indexed surfaces if it simplified my program logic. For performance, I trust convert() and convert_alpha() to know more about the system it's running on than I do. -- Greg
Re: [pygame] pyg_mixer.music.load doesn't take non ascii chars
Bo Jangeborg wrote: According to the documentation one should be able to pass an object as a parameter but I am not sure if I am doing it the right way. I think it means a file object, not the file contents: file_path = 07-Boabdil, Bulerías.ogg fi = open(file_path, 'rb') pygame.mixer.music.load(fi) If open() is able to handle the unicode file name, that ought to work. -- Greg
Re: [pygame] pyg_mixer.music.load doesn't take non ascii chars
Bo Jangeborg wrote: file_path = 07-Boabdil, Bulerías.ogg fi = open(file_path, 'rb').read() pygame.mixer.music.load(fi) But that gets me the Error: File path 'OggS' contains null characters music.load() expects to be passed the name of a file, not the contents of the file. Just do this: file_path = 07-Boabdil, Bulerías.ogg pygame.mixer.music.load(file_path) -- Greg
Re: [pygame] Pygame blitting 8-bit surfaces doesn't ignore palettes?
Brian Madden wrote: I'm seeing that that when blitting, Pygame will use the source surface's palette to get the 24-bit entry for each pixel, then look for that 24-bit value in the destination surface's palette, and then write the 8-bit integer value from the destination surface's palette as the pixel value in the destination surface. I'm just curious as to whether this is this a bug, or is my understanding of how Pygame works with 8-bit surfaces not correct? This behaviour is probably more or less what one wants most of the time, so I'd say the bug, if any, is in the docs. (More or less because it would be less surprising to use the nearest colour from the destination palette if there isn't an exact match.) I have multiple surfaces each with their own palettes, and if I blit a pixel value of 1 then I want it to be 1 on my destination surface regardless of what any of the palettes are! :) I haven't tried it, but if the docs are to be believed, you should be able to get this effect by creating a subsurface referencing the original source surface, setting its palette to be the same as the destination palette, and then blitting from that. You might also be able to do something with surfarrays, but I'm not sure. -- Greg
Re: [pygame] immutable vectors in math package
Lorenz Quack wrote: I guess, using PyQt4 lately I followed their convention. Also using methods makes it more explicit that the values are read-only. I think that in a pure Python library it's more important to follow Python conventions than those of some other language or library. If PyQT has that convention, I suspect it gets it from C++, where read-only attributes are impossible. While Python values explicitness, I don't think it's an issue here. Explicitness is about making it clear what the code is intended to do, and I think it's pretty clear that 'v.x' is meant to retrieve the x coordinate of vector v. The fact that you can't assign to it is not something that needs to be made explicit, because the code at that point isn't trying to do that. -- Greg
Re: [pygame] immutable vectors in math package
Lorenz Quack wrote: * you cannot access the components x/y/z directly... use ... new accessor methods x()/y()/z() Is this change really necessary? It will be a big backward step for code readability. There shouldn't be any reason you can't provide read-only access using attribute notation. -- Greg
Re: [pygame] OpenGL stretch of a pygame.Surface
Berlioz Silver wrote: You want pixels2d, which gives you a variable which _references_ the data. Yes, sorry, I got it the wrong way round. You need to start with a normal surface that you can blit into, and then use pixels2d to create a numpy view of it that you can pass directly to OpenGL. While the reference is still there, the surface is locked (otherwise you could change the data mid-blit, which would be bad). Instead, you should use: del (variable with pixels2d in it) right before you pass it off to GL or pygame. I think you mean *after* passing it to GL, don't you? -- Greg
Re: [pygame] OpenGL stretch of a pygame.Surface
sylvain.boussekey wrote: I managed to do it in opengl but perfs are poor. A few things to consider: textureData = pygame.image.tostring(textureSurface, RGBA, 1) * You're creating an extra copy of the texture data here. To avoid that, you could use surfarray to create a surface backed by a numpy array, do your drawing into that, and then pass the numpy array directly to glTexImage2D. texture = glGenTextures(1) glBindTexture(GL_TEXTURE_2D, texture) glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST) glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST) * You're creating a new OpenGL texture for each frame and then discarding it. Try making these calls just once at the beginning and re-using the texture. * You're using a non-power-of-2 texture size. Not all OpenGL implementations support that; yours seemingly does, but it might be less efficient than a power-of-2 size. You could try allocating the next larger power-of-2 size and updating the part that you use with glTexSubImage2D(). -- Greg
Re: [pygame] OpenGL stretch of a pygame.Surface
Jeffrey Kleykamp wrote: On my not so fast computer, I acheive 400FPS, which is useless but a good indicator to know how many sprites I can draw simultaneously. Are you clearing and redrawing the whole screen each frame, or just drawing the areas where sprites have moved? If the latter, then some of the performance decrease could be due to the fact that you're now copying a whole screenful of data per frame. To avoid that with the OpenGL method, you would need to keep track of the changed areas and just copy them to the texture with glTexSubImage2D(). -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
diliup gabadamudalige wrote: for event in pygame.event.get([KEYDOWN, KEYUP, MOUSEMOTION, MOUSEBUTTONUP]): so far works well. I also noted a slight increase in speed. Is that my imagination or could specifying the events looked at speed up the process? It's almost certainly your imagination. The only thing you're saving is a do-nothing trip around the event loop for each event other than the ones you're interested in. Unless you're getting events at an *extremely* high rate, I wouldn't expect that to make a noticeable difference. Also, if you do that, you'll need to somehow clear out all the other event types, otherwise they'll eventually fill up the buffer and you'll start losing events. You *could* do that using event.clear() with a list of all the other event types, but I really doubt whether it's worth the trouble. -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
diliup gabadamudalige wrote: Can someone please explain why if event.type is KEYUP: is bad and if event.type == KEYUP: is correct? The 'is' operator tests whether two expressions refer to the *same* object. It's possible for two different int objects to have the same value, in which case 'is' and '==' will give different results, e.g. 666 == 2 * 333 True 666 is 2 * 333 False You can be misled if you try this experiment with sufficiently small integers, however: 6 is 2 * 3 True This happens because CPython keeps a cache of small integer objects and re-uses them. But that's strictly an implementation detail, and not something you should rely on. The only reliable way to tell whether two ints are equal is to use ==. -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
diliup gabadamudalige wrote: I called event.clear() cause it says in the Pygame documentation that if you leave unused events on the buffer that eventually it may fill up and cause the program to crash. What it says is: If you are only taking specific events from the queue, be aware that the queue could eventually fill up with the events you are not interested. But event.get() without an argument takes *all* events from the queue, so this doesn't apply in that case. Also can you explain why if x is True: is not correct and if x == True is correct? Neither of those is correct. You should just be doing if x: ... There might be some very rare cases where comparing something directly with True or False is justified, but then whether to use 'is' or '==' will depend on why you are doing it. -- Greg On Mon, Jun 23, 2014 at 11:34 AM, Greg Ewing greg.ew...@canterbury.ac.nz mailto:greg.ew...@canterbury.ac.nz wrote: diliup gabadamudalige wrote: pygame.event.clear() before exiting the function somehow when I removed that line the error stopped. That would definitely be it! You were throwing away any events that came in between calling event.get() and reaching the end of your function. Not a good idea when you rely critically on seeing *all* key up events. I don't know why you thought you needed to call event.clear(), but whatever your reason was, it was probably wrong. So may be I had to keep all the unused events for the next time the loop was entered. Is that correct? Exactly correct. -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
Sam Bull wrote: I don't know if SDL/Pygame is supposed to guarantee these events or not, it could also be possible that it's just overflowing the keyboard buffer or something. Also keep in mind that computer keyboards often don't handle multiple keys being pressed at once very well, which could easily happen if you're trying to play notes quickly. I'd still expect to get a key-up for every key-down, but maybe not. -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
Jeffrey Kleykamp wrote: Although it looks like the KEYUP events don't have a unicode That is very true, which means this won't work at all: if event.type is KEYUP: x = event.unicode Also, it's a bad idea to use 'is' to compare ints. It may appear to work in this case, but it's only working by accident. You should do this instead: if event.type == KEYUP: ... -- Greg
Re: [pygame] preview of new pygame website... HiFi part
Al Sweigart wrote: Oh, also, we should keep the Pygame logo. It's familiar branding, and it doesn't look bad at all. I second that. The old site design has an air of playfulness about it that the new one currently lacks. It looks bland and doesn't convey that pygame is about having *fun*. -- Greg
Re: [SPAM: 8.000] [pygame] Pygame 2.0 software blits
Lenard Lindstrom wrote: If the bytecode is exposed at the Python end then any expression can be encoded, a different one for each channel if desired. Conceivably, a Python expression, or function, could be compiled into a blit operation. That would be even more awesome! -- Greg
Re: [SPAM: 8.000] [pygame] Pygame 2.0 software blits
Lenard Lindstrom wrote: A Pygame level production blitter would extend the simple bytecode language to support basic arithmetic operations, different integer sizes, as well as higher level operations such as pixel encoding/decoding and alpha blitting. It would replace code in alphablit.c, pixelcopy.c, and freetype/ft_render_cb.c. Just something to consider. This sounds very interesting, especially if it allows a wider and more useful set of operations to be supported, such as specifying separate combining functions for rgb and alpha channels. -- Greg
Re: [pygame] Quick OS survey - 2013
Jason Marshall wrote: pygamers, which computer operating system(s) have you used this year? 70% MacOSX 10.6, for fun 25% Windows (various flavours), not for fun 5% Fedora Linux, for moderately cool stuff -- Greg
Re: [pygame] Pygame look and feel
I don't think I like the stripes. They make it look to me like the whole thing is flying through the air in an awkward manner. If that's not what you're trying to convey, maybe a solid shadow would be better. -- Greg
Re: [pygame] Pygame container for rectangles
Paul Vincent Craven wrote: If you are not using sprites, you can just iterate through a list If you are using sprites, you can create an update() method Or you can directly move them in a loop Another approach is not to move the rectangles at all, but leave them relative to some origin and transform them at rendering time. This is generally a better way of handling such things, because it minimises opportunities for things to get out of step with each other. -- Greg
[pygame] ANN: Albow 2.2.0
ALBOW - A Little Bit of Widgetry for PyGame Version 2.2 is now available. http://www.cosc.canterbury.ac.nz/greg.ewing/python/Albow/ Highlights of this version: * Multichoice control * Powerful new facilities for hot-linking controls to application data There are also many other improvements and bug fixes. See the Change Log for details. What is Albow? Albow is a library for creating GUIs using PyGame that I have been developing over the course of several PyWeek competitions. I am documenting and releasing it as a separate package so that others may benefit from it, and so that it will be permissible for use in future PyGame entries. The download includes HTML documentation and some example programs demonstrating most of the library's features. You can also see some screenshots and browse the documentation on-line. -- Gregory Ewing greg.ew...@canterbury.ac.nz
Re: [pygame] Professional games made with Pygame?
Lin Parkh wrote: Hi everyone, I'm compiling a list of professional-quality games made using Pygame. The Witch's Yarn -- Greg
Re: [pygame] Alternate to graphics modules
Ian Mallett wrote: 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. Not necessarily -- you can use ctypes to wrap a C library. -- Greg
Re: [pygame] [Pygame] Smooth Animation
yannisv wrote: Yes, I am. The problem is when I set the FPS to ~12, and use clock.tick(FPS) inside the loop, that movement looks terrible (as expected). When I set the FPS to 30 or 60, the movement does look better, but the frames change extremely fast. If you want smooth animation, you will need to create more animation frames. There's no way around that. -- Greg
Re: [pygame] Importing Graphics
Ian Mallett wrote: On Sat, Oct 6, 2012 at 4:13 AM, shane shanevansh...@yahoo.com mailto:shanevansh...@yahoo.com wrote: can graphics from shareware etc be imported Do you mean like pygame.image.load(...)? To be a bit more explicit, if you can get hold of the graphics in any of the common image formats -- gif, jpeg, png, etc -- then pygame can probably load and use them. -- Greg
Re: [pygame] Python comparing float
Ricardo Franco wrote: That's why when you are comparing floating point numbers, you always have to check if they are within some small error value from each other. How large that value is depends on your particular use case. It's even better if you can avoid comparing floats for equality at all. You can do that in this case by using an integer loop counter and computing the float value from it: for i in xrange(11): ...rate = 1.0 + i * 0.1 ...print rate ... 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 -- Greg
Re: [SPAM: 4.500] Re: [pygame] Easy networking module - feedback needed
Ryan Hope wrote: Can someone explain to me why integrating network packets with pygame events is a good idea? It was my understanding that the pygame event buffer can only hold a limited number of events before events get lost. If this turns out to be a problem, it could be addressed by keeping the network packets in a separate queue, and just using the event mechanism to indicate when there is something in the queue. -- Greg
Re: [SPAM: 3.000] Re: [pygame] Monospaced fonts are meant to be mono-spaced, right?
Weeble wrote: To get the very best positioning of a text cursor, I think you want to calculate the width of the string on its left, then *subtract* the overhang of the character immediately to the left, if any. For the *very* best results with italic fonts, you really need a slanted cursor. :-( -- Greg
Re: [pygame] GUI toolkit for Python for Android
Brian Bull wrote: I need to add some GUI elements and I'm not aware of any resources that make it easy for me to do this in pgs4a. I don't want to write my own dialogs, choosers, HTML renderers or scrolling boxes from scratch if I can possibly avoid it. You could try Albow: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Albow/ Not sure how much of pygame pgs4a supports, but as long as the basic drawing and font rendering functionality is there, there's a good chance that most of Albow will work. -- Greg
Re: [pygame] Issue with pygame.mask
Peter Finlayson wrote: I expected the default threshold (0,0,0) of this function to have it match only that the exact color specified (ie within 0 values of the color). However, it seems that it instead matches NO pixels. The third comment about that function here seems to explain what's happening: http://www.pygame.org/docs/ref/mask.html This creates a mask from the surface which has all the pixels set which have color values above or equal to those in color, but below (and not equal to) the values in threshold. So no pixel with a 255 value can possibly be considered. And the default threshold doesn't let the mask have any set pixels for any given surface. However this seems to contradict what is said in the second comment, so it may be a case of the blind leading the blind. -- Greg
Re: [pygame] Monospaced fonts are meant to be mono-spaced, right?
Nicholas Seward wrote: The letters may be different lengths. However, the letters should be spaced equally. For example,i will be shorter than w but hit and hot should be the same length. No, that's not the way it should work. I just tried an experiment: f = Font(VeraMono.ttf, 12) f.size(e) (7, 15) f.size(i) (7, 15) I suspect that the system is not actually giving you a monospaced font. If it doesn't recognise the font name you give it, you'll probably get some default font. Have you tried rendering any text with the font to see what it looks like? I've given up on using SysFont because the results are too unpredictable cross-platform. I always bundle my own fonts with my games and use Font to load them explicitly. I like to use the Bitstream Vera fonts. They're nice, small and very liberally licensed. http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/ -- Greg
Re: [pygame] Extending OpenGL support in Pygame
Sam Bull wrote: If this is something of interest to other people, I'm wondering whether there might be some interest in integrating this code into Pygame (sometime after GSoC). I'm interested! This sounds like it could be very useful. If done properly, it would make it very easy to use libraries designed for 2D pygame in a 3D environment. -- Greg
Re: [pygame] Making Games with Python Pygame free book
Lee Buckingham wrote: I think the iphone 5 can see in ultraviolet. There's some indication that humans might be able to as well if our lenses didn't filter it out. I saw a story a while ago about someone who had the lens and cornea of one eye replaced by a prosthesis. He claimed to be able to see the light from ultraviolet lamps as a deep purple glow. However, it's probably more a matter of the blue receptors having some sensitivity in that region rather than a separate set of receptors. Although you never know -- after all, we've recently discovered another kind or two of taste buds that nobody knew we had... -- Greg
Re: [pygame] Making Games with Python Pygame free book
Christopher Night wrote: The idea is that if we could independently stimulate each of the three colors receptors (cones) in our eyes, then we could reproduce any visual sensation and thereby any color. The problem is ... there's no such thing as a wavelength of light that stimulates the middle (green) cones without also stimulating either of the outer two. But that means we never experience the sensation of having just the green cones stimulated, so there is no need to reproduce it. -- Greg
Re: [pygame] Making Games with Python Pygame free book
Miriam English wrote: The red, blue, yellow that people have been using for centuries are now often called magenta, cyan, yellow. But many people still call them red, blue, yellow. They aren't wrong to do so, but it can make color stuff confusing. Massively confusing, I would say. The difference between red and magenta, and between blue and cyan, isn't just a minor distinction -- it's vitally important to understanding how subtractive colour mixing works! Perhaps this bugs me more than others, because I'm the kind of person that likes to understand the reasons behind things rather than just memorising a bunch of rules. And the red-blue-yellow misinformation that I was fed by my parents and teachers actively interfered with my understanding in this area for a long time. (Astoundingly, one of the teachers at fault was my *physics* teacher -- he of all people should have been able to do a better job of explaining it! In the end it took an art teacher to set me thinking in the right direction.) -- Greg
Re: [pygame] Declaring variables in function as if at code's line-level
Brian Brown wrote: Anyways, I think I should just continue being a solo programmer. lol I'm too wild when it comes to programming that I think I need my own space. Writing well-organised code is not just about communicating with other programmers. It also helps *you* to understand the code when you come back to it a few months or years later. -- Greg
Re: [pygame] Surface.blit() BLEND_ADD vs. BLEND_RGBA_ADD
Florian Berger wrote: Would it be better to have a BLEND_ADD_PREMULT blit mode instead, i.e. put the premultiplication in the blitting code? Not sure that would be the best name for it, since it could be taken as meaning that the image you give it is already premultiplied. Also, it would solve this particular person's problem, but then someone is going to want BLEND_SUB_PREMULT, etc. etc. Rather than attacking the problem piecemeal, the whole business of specifying blending modes really needs to be rethought. There ought to be a set of orthogonal options that can be combined, one of them being whether to multiply by alpha or not. Also there needs to be a way of handling the alpha channel differently from the others. A good place to look for inspiration would be the OpenGL fixed-function blending options. They're very flexible and allow for just about anything you might reasonably want to do. -- Greg
Re: [pygame] Help with pygame
Zack Baker wrote: With fink I'm on OSX, and I find it's generally less hassle in the long run to compile everything from source myself rather than rely on things like fink and macports, so I don't have much experience with them. But you could look into whether there is a fink version of libpng that you can install -- that would probably help. -- Greg
Re: [pygame] Help with pygame
On 15/12/11 10:51, Zack Baker wrote: Ok, I have deleted everything pygame I could find an now I'm going to reinstall it. Along with python 3.2 because I guess now they are compatible on OSX which would be great. Btw in case it doesn't could you point me too a link that shows how to compile from source? Thanks It's a while since I did it, but as far as I remember, compiling pygame itself just requires the standard python setup.py install However, before doing that, you should make sure you have libraries available for handling all the image formats you intend to use. I had to install libpng and libjpeg (they're easy to compile from source as well). You should probably also check that you have the relevant libraries for fonts and sound. Framework versions of these seem to work best on OSX. I didn't compile them myself, I just dropped in binary distributions of SDL_ttf.framework and SDL_mixer.framework (I found these somwehere on the pygame web site, if I remember correctly). When you compile pygame, it will given you a summary of which optional libraries it did and didn't find. If anything is missing, you can compile again after tracking down and installing them. -- Greg
Re: [pygame] Help with pygame
Zack Baker wrote:
Traceback (most recent call last):
File green-car-test.py, line 10, in module
car=pygame.image.load('green-car.png')
pygame.error: File is not a Windows BMP file
It looks to me as though your PyGame installation doesn't have
support for PNG files. It seems to fall back to assuming BMP
if it can't find a handler for the file it's given.
How did you install PyGame? If you're compiling it from source,
the build process should tell you which optional libraries it
found. If PNG support is missing, you might need to install
libpng and recompile PyGame.
--
Greg
Re: [pygame] man oh man Java is painful
Russell Jones wrote: Well, there is jython http://www.jython.org/. It's a version of Python that runs under the JVM with, roughly, Python 2.5 syntax. Unfortunately it appears that Android uses a different Java VM bytecode from everyone else, and Jython would have to be reworked to generate code for it. There was a Google Code project along those lines, but it's now marked as dead: http://code.google.com/p/jythonroid/ -- Greg
Re: [pygame] man oh man Java is painful
Mac Ryan wrote: Absolutely not sure it fits the bill... but have you had a look at go? http://golang.org/ I looked at it. My first impression was this is ugly. I'm pretty sure it's not the language I was talking about. -- Greg
Re: [pygame] man oh man Java is painful
On 03/11/11 03:45, Sean Wolfe wrote: I'm getting into the wonderful world of Android which means Java. Dear lord I remember now why I hate this language. I love the pythonic philosophy that there should be an obvious way to get things done. There's at least one project afoot to enable pygame programming on Android: http://pygame.renpy.org/ And there are some encouraging words concerning Python in general on Android here: http://www.linuxjournal.com/article/10940 -- Greg
Re: [pygame] man oh man Java is painful
On 03/11/11 04:28, Sean Wolfe wrote: I have been thinking that since I want to eventually port my game to iphone, I'll have to learn obj-c, so why not java first... how hard can it be? haha. Can't see how that would help -- ObjC is nothing at all like Java. Learning Smalltalk would actually be better preparation for ObjC (and would be a lot more enjoyable besides!) -- Greg
Re: [pygame] man oh man Java is painful
On 03/11/11 04:31, Ian Mallett wrote: C++ is a pain to learn, but it's definitely worth it. In my opinion it's the best compiled language. I'm afraid I can't share your opinion of C++. I liked it myself at first, but after 10 years or so of experience I came to the conclusion that it goes to extreme lengths to solve a problem you shouldn't be having in the first place. My opinion now is that if what you're doing is too big to do easily in plain C, you should be using a language that provides you with properly isolated high-level abstractions -- such as Python, for example. :-) I've yet to decide whether there's a place for a language that combines Python's flexibility and get-out-of-your-way nature with static type checking and efficient code generation. If there is, I don't think that language exists yet. -- Greg
Re: [pygame] Fast method for pixellated animation
Ian Mallett wrote: Not sampling in a scaling operation doesn't make sense. You need at least one sample to get a reconstruction. Yes, it's a slightly odd way of phrasing it. I take it to mean that only one source pixel is sampled for each destination pixel, rather than interpolating between source pixels. -- Greg
Re: [pygame] Fast method for pixellated animation
John Jameson wrote: Hi, I would like an efficient way to generate an animated grey-scale pixellated image... Another way might be to just generate the image as a 100X100 image but magnified and thus automatically obtaining the same result. Is this possible? You could try using pygame.transform.scale(), which according the docs does not sample the results. -- Greg
