Re: [pygame] Website move
John, Thanks - got it fixed now :) Phil John Eriksson [EMAIL PROTECTED] wrote: Hi Phil, One more thing! I tried to edit a relase and when I submitted the changes the same SQL-error was displayed. Best Regards /John sön 2007-05-27 klockan 16:04 -0700 skrev Phil Hassey: John, Thanks for pointing that out :) I've got it fixed (I think) please tell me if you have any trouble. Thanks! Phil John Eriksson wrote: Hi, Still getting SQL-error when trying to add a new releas for one of my projects. Best Regerdas /John lör 2007-05-26 klockan 15:29 -0700 skrev Phil Hassey: The pygame.org website was recently moved to a new server and had some troubles ... Sorry it took me a few days to get to fixing it - I was in the middle of a moving myself! Anyway - I think everything is fixed now, if you notice any more SQL errors showing up, please tell me. Thanks! Phil __ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. __ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. - Got a little couch potato? Check out fun summer activities for kids.
[pygame] Fixed aspect ratio scaling
Hi, Does anyone know about a good solution on the stretching problem when running in fullscreen mode on a widescreen monitor? For windows users having an nvidia driver it's possible to set Fixed aspect ratio scaling as an option for the display causing the widescreen to have black borders at the sides. But are there any platform independent solutions to this? I guess it might be possible to solve this using code, creating a correct sized display and then blitt the game screen to it's centered. But this (I guess) can cause some performance loss. And I don't know if it's even possible to detect the best screen resolution to use. As far as I know there are no way to determine the current screen resolution (to calculate the monitors aspect ratio) of the system? Any inputs? Thanks /John
Re: [pygame] Fixed aspect ratio scaling
On May 31, 2007, at 1:03 AM, John Eriksson wrote:
Hi,
Does anyone know about a good solution on the stretching problem when
running in fullscreen mode on a widescreen monitor?
For windows users having an nvidia driver it's possible to set Fixed
aspect ratio scaling as an option for the display causing the
widescreen to have black borders at the sides.
But are there any platform independent solutions to this?
I guess it might be possible to solve this using code, creating a
correct sized display and then blitt the game screen to it's centered.
But this (I guess) can cause some performance loss. And I don't
know if
it's even possible to detect the best screen resolution to use.
As far as I know there are no way to determine the current screen
resolution (to calculate the monitors aspect ratio) of the system?
Is the problem that your game expects a fixed-resolution and
therefore a fixed aspect ratio? Regardless if your game demands a
fixed aspect ratio then on some monitors you must either letter-box
the screen or stretch everything to fit. You seem to be hinting at
doing the latter, but that causes undesireable distortion (i.e.,
circles become ovals, etc).
Here is my suggested solution to this problem:
- Make your game resolution independent. That is, distances in the
game are independent of pixel size.
- Make either the horizontal or vertical screen distance fixed,
perhaps matching it to the ideal screen size (e.g., 1280 or 1600)
- At game startup let pygame pick the resolution by default or allow
it to be overridden by user preference. Figure out the scale by
dividing the fixed screen distance by the actual screen resolution.
Then scale all of your graphics accordingly. If you are using sprite
images, rotozoom works excellent (just zoom everything at load-time)
and is very fast.
You get several benefits from this:
- You can pretty easily implement a zoom in/out feature by varying
the fixed screen distance.
- Users can select lower resolutions to trade quality for performance
or vice versa. Some resolutions may be letterboxed, but the user can
decide if this is objectionable, many times it isn't.
To get at the screen resolution use the surface object returned from
pygame.display.set_mode(), call get_rect() on it to figure out the
screen res.
Here is some code I wrote to select the screen res from four user
resolution settings: max, high, med and low. It is intended to pick
sizes that fit the aspect ratio of the screen in fullscreen mode,
where possible. It also favors portrait orientation (for those of us
with pivoting monitors).
screen_sizes = {
'max': ((0, 10), (1280, 1024)),
'high': ((650, 800), (1024, 768)),
'med': ((500, 649), (800, 600)),
'low': ((400, 499), (640, 480))
}
(min_height, max_height), window_size = screen_sizes[resolution]
if fullscreen:
modes = pygame.display.list_modes()
# Choose the first mode with a height in the desired range
for mode in modes:
if min_height = mode[1] = max_height and mode[0] mode[1]:
break
else:
mode = modes[0]
print Could not find ideal display mode, using, mode
screen = pygame.display.set_mode(mode, FULLSCREEN)
else:
screen = pygame.display.set_mode(window_size)
screen_rect = screen.get_rect()
hth,
-Casey
[pygame] MIDI files in Games?
Hi, I know PyGame can play midi-files but how about performance and portability? Will playing a midi-file be slower than playing an ogg or a wav? Will midi-music work on Linux, Windows and Mac? I guess a midi-file will sound different on different platforms. But will it be a huge difference or just a small difference? What are your experiences of using midi-files in games? Best Regards /John
[pygame] Slow performance in fullscreen mode
Hi, My Pygame app runs fine in windowed mode, using pygame.display.set_mode((1024,768)) But when I switch to fullscreen mode with pygame.display.set_mode((1024,768),pygame.FULLSCREEN) the display looks fine but the app speed slows down dramatically. Perhaps the problem is that Pygame is emulating an absent video mode in some form? 1024 x 768 is supposed to be one of the video modes of this monitor... Does anyone have any suggestions please? I would like to be able to use fullscreen 1024x768 without the performance hit... Thanks A. The information contained in this transmission is confidential. It is intended for the named address only. If you are not the named address you may not copy, distribute or take any action in reliance upon this transmission winmail.dat
Re: [pygame] 'Shining Sea' source code
On Wed, May 30, 2007 at 10:02:34PM -, [EMAIL PROTECTED] wrote: The game starts, but I cannot control anything. I believe you mentioned W, A, S, D keys? Nothing happens. When I kill the game, I get this traceback: if pygame.mixer.music.get_busy(): KeyboardInterrupt (BTW there's no sound or music.) ... I made the ZIP file directly from a working set of code and just zipped up the whole directory, with all the music etc.. Is there some reason the code wouldn't be portable? Hmm... the music is in MIDI; does Ubuntu's Pygame support that? That could be it. I'm pretty sure this dinky laptop soundcard doesn't have any MIDI capability of its own, and today's Linux systems don't provide a software synthesizer out of the box (you can get one, but only if you run it manually). *tests* Yes, that was it. I renamed the 'music' directory so the game wouldn't find it, and I had no problems after that. Marius Gedminas -- The death rate on Earth is: (computing) One per person. signature.asc Description: Digital signature
Re: [pygame] Shining Sea source code
I tried this source code, and at first it spat out a pygame.error with the traceback: Traceback (most recent call last): File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 668, in ? game = Game(screen=screen) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 182, in __init__ self.GoToZone((0,0)) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 379, in GoToZone self.screen.blit(self.bigpen.render(Now Loading,0,(255,255,255)),(500,560)) pygame.error Then when I commented that line out, it started up, but then just sat there with a blue screen for about a minute and then crashed with another error (Unfortunately I didn't save that traceback). Marius Gedminas wrote: On Wed, May 30, 2007 at 07:01:07PM -, [EMAIL PROTECTED] wrote: A version with source code: http://kschnee.xepher.net/code/070530ShiningSeaSource.zip Thanks! I had to change all font.render() calls to enable anti-aliasing, to sidestep a bug in Ubuntu's pygame (segmentation faults when rendering non-anti-aliased spaces). The game starts, but I cannot control anything. I believe you mentioned W, A, S, D keys? Nothing happens. When I kill the game, I get this traceback: Traceback (most recent call last): File Shining Sea.py, line 687, in module game.Go() File Shining Sea.py, line 634, in Go function_to_call() File Shining Sea.py, line 608, in WanderingScreen Conch.j.PlaySong(island) File /tmp/shining-sea/Conch/conch.py, line 128, in PlaySong if pygame.mixer.music.get_busy(): KeyboardInterrupt (BTW there's no sound or music.) Marius Gedminas
Re: [pygame] Shining Sea source code
On Thursday 31 May 2007 09:21:11 am Samuel Mankins wrote: I tried this source code, and at first it spat out a pygame.error with the traceback: Traceback (most recent call last): File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 668, in ? game = Game(screen=screen) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 182, in __init__ self.GoToZone((0,0)) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 379, in GoToZone self.screen.blit(self.bigpen.render(Now Loading,0,(255,255,255)),(500,560)) pygame.error Then when I commented that line out, it started up, but then just sat there with a blue screen for about a minute and then crashed with another error (Unfortunately I didn't save that traceback). You probably need to turn antialiasing on, because your computer doesn't like drawing without antialiasing.
Re: [pygame] Shining Sea source code
On Thursday 31 May 2007 09:27:53 am Samuel Mankins wrote: How do I do that? Charles Joseph Christie II wrote: On Thursday 31 May 2007 09:21:11 am Samuel Mankins wrote: I tried this source code, and at first it spat out a pygame.error with the traceback: Traceback (most recent call last): File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 668, in ? game = Game(screen=screen) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 182, in __init__ self.GoToZone((0,0)) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 379, in GoToZone self.screen.blit(self.bigpen.render(Now Loading,0,(255,255,255)),(500,560)) pygame.error Then when I commented that line out, it started up, but then just sat there with a blue screen for about a minute and then crashed with another error (Unfortunately I didn't save that traceback). You probably need to turn antialiasing on, because your computer doesn't like drawing without antialiasing. Change the 0 after Now Loading to a 1, and do this for all of the other renders.
Re: [pygame] Shining Sea source code
How do I do that? Charles Joseph Christie II wrote: On Thursday 31 May 2007 09:21:11 am Samuel Mankins wrote: I tried this source code, and at first it spat out a pygame.error with the traceback: Traceback (most recent call last): File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 668, in ? game = Game(screen=screen) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 182, in __init__ self.GoToZone((0,0)) File /Users/samuelmankins/Desktop/070530ShiningSeaSource Folder/Shining Sea.py, line 379, in GoToZone self.screen.blit(self.bigpen.render(Now Loading,0,(255,255,255)),(500,560)) pygame.error Then when I commented that line out, it started up, but then just sat there with a blue screen for about a minute and then crashed with another error (Unfortunately I didn't save that traceback). You probably need to turn antialiasing on, because your computer doesn't like drawing without antialiasing.
Re: [pygame] Fixed aspect ratio scaling
John Eriksson [EMAIL PROTECTED] asked: Does anyone know about a good solution on the stretching problem when running in fullscreen mode on a widescreen monitor? One thing I would do would be to inspect the available resolutions. On my widescreen laptop, I get the familiar 800x600 and friends (4:3 aspect ratio), and some unfamiliar widescreen resolutions (16:9, I think). If all the resolutions supported by the card are 4:3, you can bail out and stop doing anything special. If you have some 16:9 (or crazier) resolutions, I would filter out all the 4:3 options, assuming that they're undesirable relics. I guess it might be possible to solve this using code, creating a correct sized display and then blitt the game screen to it's centered. By correct sized display, you mean having an off-screen buffer of a fixed 4:3 resolution (e.g. 800x600), and then blit that? It could work, assuming you're OK with the inverse letterbox black bars on the side, and if you can guarantee that there's going to be a resolution of the right height on the player's device (1067x600, in this case). But this (I guess) can cause some performance loss. And I don't know if it's even possible to detect the best screen resolution to use. Yeah, that ought to be a decision by the player, rather than some guess by code, I imagine. One other thing to consider - what if the monitor is in portrait mode? If you look through the available resolutions and see 3:4 or 9:16 aspect ratios, it seems like a good solution is even more important - a little stretching between 4:3 and 16:9 looks bad, but I imagine it'd look terrible between 4:3 and 3:4. -Dave LeCompte
Re: [pygame] MIDI files in Games?
John Eriksson [EMAIL PROTECTED] wondered: I guess a midi-file will sound different on different platforms. But will it be a huge difference or just a small difference? I'm planning to use BASSMidi (http://www.un4seen.com/) for one of my current projects. The benefit to this is that the MIDI synthesis happens on the CPU, instead of the sound card, so the music guy can give me a sound font with the instruments he likes. This should give consistent sounding music across a variety of machines. However, some of the downsides: * 100 Euro license for Mac or PC, 60 Euro license for the second platform * No Linux support * No existing Python support (I'm comfortable with using CTypes, but I'd be happier if the Python work was already done.) * Doing the synthesis on the CPU means a CPU hit that a PyGame-only approach might not have. I think it's a reasonable tradeoff for my project. -Dave LeCompte
Re: [pygame] Slow performance in fullscreen mode
Brian Bull wrote: Hi, My Pygame app runs fine in windowed mode, using pygame.display.set_mode((1024,768)) But when I switch to fullscreen mode with pygame.display.set_mode((1024,768),pygame.FULLSCREEN) the display looks fine but the app speed slows down dramatically. Perhaps the problem is that Pygame is emulating an absent video mode in some form? 1024 x 768 is supposed to be one of the video modes of this monitor... Does anyone have any suggestions please? I would like to be able to use fullscreen 1024x768 without the performance hit... Thanks A. The information contained in this transmission is confidential. It is intended for the named address only. If you are not the named address you may not copy, distribute or take any action in reliance upon this transmission Try throwing away all but the first mouse movement, each time through the loop. That sped up my app significantly... as it turned out, full screen mode was sending every xy change to the app, whereas windowed mode was throwing away samples between mouse movements (the preferred behavior.) Example: Windowed mode during a fast mousemove might send: 1-1, 5-5 Fullscreen mode was sending something like this: 1-1, 1-2, 2-2, 3-2, 3-3, 4-3, 4-4, 5-4, 5-5
[pygame] Pygame Platform compatability and Numeric/Numpy support Question
Hello, I'm working on a project for the University of Toronto that is utilizing both pygame and Numeric libraries. I have a few questions: 1. When will pygame support OSX? (Python 2.5) 2. Is pygame fully Python 2.5 compatible under both Linux (ie. Debian) and Windows? 3. Does pygame depend on the Numeric library, if so can this be substituted by Numpy? The reason for my confusion as per question 3 is that the Numerical library does not support Python 2.5. However, there is a windows link to Numerical for Python 2.5from the pygame website, but only for windows. What about Linux? Sorry for so many questions. Thank you. Best Regards, Leo Kaliazine.
Re: [pygame] Slingshot 1.0
John Eriksson wrote: Hi, Finally the first real version is done! If you could help me test it I would be very happy! I've also included a Windows-installer version that could need some extra testing. The Windows installer worked for me. If you have sound-problems, try modify the mixer settings in the /data/config/game.ini file. If you have installed the windows version the select Configuration from the Start-Programs-Slingshot menu. Windows users got to start icons. One for window mode and one for fullscreen. Others can modify the /data/config/game.ini file or start the game with python run_game.py -f Thanks for all your help! I keep getting the following warning message: *PendingDeprecationWarning*: Space Shuttle outdated technology. Please consider upgrading. I wonder if a from __future__ import project_constellation will fix that? :-) -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Pygame Platform compatability and Numeric/Numpy support Question
On 5/31/07, Leo Kaliazine [EMAIL PROTECTED] wrote: 3. Does pygame depend on the Numeric library, if so can this be substituted by Numpy? I use pygame without Numeric all the time. Numeric is only for the *array class of functions (so you can do quick modification of sound and surface data) I think people are still working on making numpy interchangable...
Re: [pygame] Slingshot 1.0
*lol* I'm sorry, but your warning system must be malfunction! ;-) If you look close enough you'll see that the shuttle is capable of launching photon-torpedoes. And surly that can't be rated as outdated technology. Well...you might answer that Star Trek invented that sort of thing back in the 60's...and...you would be right. But they didn't have the highly advanced Aiming Assistance Technology that you get when hitting an A-bonus!!! Ha, got you there! ;-) Best Regards /John Eriksson tor 2007-05-31 klockan 10:14 -0700 skrev Lenard Lindstrom: John Eriksson wrote: Hi, Finally the first real version is done! If you could help me test it I would be very happy! I've also included a Windows-installer version that could need some extra testing. The Windows installer worked for me. If you have sound-problems, try modify the mixer settings in the /data/config/game.ini file. If you have installed the windows version the select Configuration from the Start-Programs-Slingshot menu. Windows users got to start icons. One for window mode and one for fullscreen. Others can modify the /data/config/game.ini file or start the game with python run_game.py -f Thanks for all your help! I keep getting the following warning message: *PendingDeprecationWarning*: Space Shuttle outdated technology. Please consider upgrading. I wonder if a from __future__ import project_constellation will fix that? :-)
[pygame] Slow performance in fullscreen mode
Hi list, My Pygame app runs fine in windowed mode, using pygame.display.set_mode((1024,768)) But when I switch to fullscreen mode with pygame.display.set_mode((1024,768),pygame.FULLSCREEN) the display looks fine but the app speed slows down dramatically. Perhaps the problem is that Pygame is emulating an absent video mode in some form? 1024 x 768 is supposed to be one of the video modes of this monitor... Does anyone have any suggestions please? I would like to be able to use fullscreen 1024x768 without the performance hit... Thanks A. The information contained in this transmission is confidential. It is intended for the named address only. If you are not the named address you may not copy, distribute or take any action in reliance upon this transmission
Re: [pygame] Slow performance in fullscreen mode
On 31/05/07, Brian Bull [EMAIL PROTECTED] wrote: Hi list, My Pygame app runs fine in windowed mode, using pygame.display.set_mode((1024,768)) But when I switch to fullscreen mode with pygame.display.set_mode((1024,768),pygame.FULLSCREEN) the display looks fine but the app speed slows down dramatically. Perhaps the problem is that Pygame is emulating an absent video mode in some form? 1024 x 768 is supposed to be one of the video modes of this monitor... Does anyone have any suggestions please? I would like to be able to use fullscreen 1024x768 without the performance hit... I found that fullscreen worked best when using the same resolution as the screen is currently operating at but this was using opengl so I don't know if it works the same normally. HTH
Re: [pygame] Slow performance in fullscreen mode
Oh yeah. Sometimes that makes a difference. There's s many variables with all the different video cards out there. Generally full screen is faster though. Have you tried that event culling idea mentioned in the other email Brian? On 6/1/07, Adam Bark [EMAIL PROTECTED] wrote: On 31/05/07, Brian Bull [EMAIL PROTECTED] wrote: Hi list, My Pygame app runs fine in windowed mode, using pygame.display.set_mode((1024,768)) But when I switch to fullscreen mode with pygame.display.set_mode((1024,768),pygame.FULLSCREEN ) the display looks fine but the app speed slows down dramatically. Perhaps the problem is that Pygame is emulating an absent video mode in some form? 1024 x 768 is supposed to be one of the video modes of this monitor... Does anyone have any suggestions please? I would like to be able to use fullscreen 1024x768 without the performance hit... I found that fullscreen worked best when using the same resolution as the screen is currently operating at but this was using opengl so I don't know if it works the same normally. HTH
Re: [pygame] Buried In Game Ideas
On 5/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quick question before this battery runs out: what would you want to be able to do in a village in this primitive island world, if the village is abstracted as a menu but the individual random tribesmen have names and hopefully some kind of individual personality? What mechanics? This puts my mind back to Sid Meier's Pirates!, where you would get a menu in each town you enter. I haven't follow your game idea to its fullest extent, but possible actions for the above would be trade, recruit people, bribe the tribe (no pun intended), etc. Another possibility would be quests (in case your game is experience based) as in some random tribesmen asking you for help, like finding their missing cat or whatever. -- - Rikard - http://bos.hack.org/cv/
