Re: [pygame] Timing question (newbie)
Hi again, I've been checking the suggestions and they are all very informative, but I am still somewhat stuck. I was a bit unclear formulating my question - but thanks anyway for your previous answers. Ok, so what I want to do is: make pygame play a song, and while it is playing, record my keystrokes (so instead of having a program deciding what to press when, I will do it). Then I want to be able to playback my keypresses so the player has to be repeat them when playing. So I guess I am aiming at some kind of level editor for rhythm games, maybe? But looking at your examples, I have another doubt: what if I want to tie specific input to a specific event in the game, and measure how precise that input was, to give points? For example, I trigger an animation based on random numbers - that animation has a number of stages: depending on which stage the player provides the required input, they are rewarded with points. Does this make any sense? (I am thinking typing-rhythm games here, of course :) Sorry for being a pest, and thanks for the help! M On 3/12/08, Miguel Sicart [EMAIL PROTECTED] wrote: That's great people, thanks a lot!! M On 3/12/08, Luke Paireepinart [EMAIL PROTECTED] wrote: Wayne Koorts wrote: I have a question about timing - I want to make a little game based on rhythm input, a bit like dance dance revolution, patapon, or similar. The idea is that the player has to press a key within a specific time, getting more points the better the timing. And I have little idea how to do it. I am thinking creating uservents, and the matching them to key input, but I am a bit clueless about the timing thing. Any help is welcome! Have a look at PyDance: http://icculus.org/pyddr/ It's GPL so you can look under the hood. Frets on Fire and StepMania are both open-source too. I believe at least parts of frets on fire are Python, but I'm pretty sure StepMania isn't. FoF is a guitar hero simulator, by the way.
Re: [pygame] get_wm_info on linux
hi i create subwindow for mplayer like this: first you need some imports: from ctypes import * Xlib = CDLL(libX11.so.6) Xtst = CDLL(libXtst.so.6) def create_subwindow(x,y,width,height): pygame_win = pygame.display.get_wm_info()[window] dpy = Xtst.XOpenDisplay(None) win = Xlib.XCreateSimpleWindow (dpy, pygame_win, x,y,width,height,0,0,1) Xlib.XCirculateSubwindows(dpy,win,1) Xlib.XFlush(dpy) return win you can then force mplayer into that subwindow: yourfavoriteexeccommand(mplayer -wid %s % (win)) you can resize it like this: def move_subwin(win,x,y,width,height): dpy = Xtst.XOpenDisplay(None) Xlib.XMoveResizeWindow(dpy,win,x,y,width,height) Xlib.XFlush(dpy) and you can destroy it like this: def destroy_subwin(win): dpy = Xtst.XOpenDisplay(None) Xlib.XDestroyWindow(dpy,win) Xlib.XFlush(dpy) hope it helps :) Lenard Lindstrom wrote: Greg Ewing wrote: It seems like it should be possible to get the long from the PyCObject (info['display']) just as well as it was done from the c code PyCObjects are opaque from Python code -- there's no way to extract an address from one without using C code. ctypes can.
Re: [pygame] mapping logical coordinate ????
Sibtey Mehdi: How to map the logical coordinates in to window coordinates using pygame. I did a mock-up of this at http://zork.net/~nick/tkhasi/ The tactical.py has the classes that do the transformations, and testcamera.py does a quick demo. -- A: No. Nick Moffitt Q: Should I put my reply above quoted text? [EMAIL PROTECTED]
Re: [pygame] mapping logical coordinate ????
Nick Moffitt: The tactical.py has the classes that do the transformations My bad. http://zork.net/~nick/tkhasi/space.py is the file that actually does the coordinate transformations (but remember that positive Y is down on the screen) -- Ill-informed qmail-bashing is better than no Nick Moffitt qmail-bashing at all. [EMAIL PROTECTED] --Don Marti
RE: [pygame] mapping logical coordinate ????
Thanks,for your kind help But, I am getting the coordinate (3000, 2000, 3400, 2400) from some others tools and want to create the pygame.draw.rect (3000, 2000, 3400, 2400) to show some information. I have create a Surface pygame.Surface ((4000, 3000)) and then tried to scale down it but the rectangle has not displayed in the pygame window. Can anyone help me out? I have tried something like this screen = pygame.display.set_mode ((800,700)) worksurf = pygame.Surface((4000,3000)) pygame.draw.rect (worksurf, (255, 0, 0), (3000, 2000, 3400, 2400), 1) screen.blit (worksurf, (0, 0))) newSurf = pygame.transform.scale (worksurf, (800,700)) #scale down screen.blit (newSurf, (0, 0))) Nick Moffitt: The tactical.py has the classes that do the transformations My bad. http://zork.net/~nick/tkhasi/space.py is the file that actually does the coordinate transformations (but remember that positive Y is down on the screen) -- Ill-informed qmail-bashing is better than no Nick Moffitt qmail-bashing at all. [EMAIL PROTECTED] --Don Marti
Re: [pygame] Sticky Variables: Terrain Loading
On Wed, 12 Mar 2008 06:59:52 +0200, Toni Alatalo [EMAIL PROTECTED] wrote: note that you are changing y inside the inner loop with x, so when iterating the x values the y is not reset by the y iteration but i guess stays what you define it to be. does this fully explain the peculiar behavior that you got .. and it had nothing to do with the 'terrain' reference being reused? Although it surprises me that the loop wouldn't reset y to be the next number in the sequence at the start of each iteration, that behavior does seem to explain what happened. therefore, when you get down to self.land.append(terrain), after such a if-elif-else structure where a new string object is always created, 'terrain' is *in principle* never the same object. *but*, like we already saw with smallish integers, there's a similar re-use optimization for strings apparently: long1 = water is wet long2 = water is wet long1 is long2 False short1 = water short2 = water short1 is short2 True This really surprises me! I hadn't known about these automatic optimizations. Yes, I know that == != is, but the rest of it is news to me. Kris
Re: [pygame] Sticky Variables: Terrain Loading
Ian Mallett wrote: Weird. I get: 2 is 1+1 True 22 is 21+1 True 222 is 221+1 True is 2221+1 False Obviously the integer cache in Python 2.5 is bigger than in earlier releases. -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Sticky Variables: Terrain Loading
Kris Schnee wrote: Dave LeCompte wrote: I did notice that you were using y as both a coordinate and as a flag for whether the current pixel is yellow. Do you still have trouble if you don't reuse y in this way? Oops. I tried calling it yellow instead, and it suddenly works. I don't understand _why_ it works though, and this bothers me. Re-using variable names like that is bad, of course, but in this case the first version of y is being used to get the color of the test image at a certain pixel, and then y is used to represent whether that pixel is yellow. Since the color is already gotten by the time y is changed, using y for yellow should have no effect -- and I don't see why it would lead to the sticky variable. The loop says for y in range(something). I thought that loops used each value in the list produced by the range statement, so that Python would be unaffected if I changed y during the loop. for y in range(self.size) is the outer loop. So y is an index for the first pass of the inner x loop. Then its value is clobbered, replaced with some color test. So the next pass through the x loop it is no longer an index. -- Lenard Lindstrom [EMAIL PROTECTED]
Re: [pygame] Sticky Variables: Terrain Loading
Kris Schnee [EMAIL PROTECTED] wrote: for y in range(self.size): for x in range(self.size): rgb = the_map.get_at((x,y)) r = rgb[0] 100 g = rgb[1] 100 b = rgb[2] 150 y = r and g I suspect if you were to add a debug line to print out (x,y) before doing the get_at, you'd see something like the following: (0, 0) (1, False) (2, False) (3, False) (4, False) ... That ought to look suspicious. I wouldn't be surprised that it continued to run, because False can be converted to 0 (and will be), so really, you're just looking at the edge of your map. Similarly, True converts to 1, so depending on the specific patterns in the 0 and 1 rows of your map, you might get bands of color, checkerboard patterns, or one solid color, the last of which sounds like what you happened to hit this time. This doesn't have to do with the details of immutable object identity, it's strictly a result of stomping the outer loop index inside your inner loop, which would be a problem in other languages, too. -Dave LeCompte
Re: [pygame] shadow demo
On Tue, Mar 11, 2008 at 10:32 PM, René Dudfield [EMAIL PROTECTED] wrote: Hello, I noticed with this cool shadow demo: http://www.pygame.org/project/556/ On this ATI card I have, I had to change the glAlphaFunc to use GL_LESS... which I think is because of float inaccuracies. #Set alpha test to discard false comparisons #glAlphaFunc(GL_EQUAL, 1.0) glAlphaFunc(GL_LESS, 1.0) Any ideas on how to make the shadows softer? Either by making the shadow map a higher resolution or some other algorithm? I tried changing shadowMapSize = 2048, but it looks like the shadow map is wrong some how. Like it isn't the correct scale, or something. I tried increasing the shadow map resolution, but although the resulting shadow was very nice and smooth, the area it covered on the landscape was tiny. The resolution appeared to be inversely proportional to the area that could be shadowed. I think a well-commented simple demo that shadowed a single quad with another quad might actually be more useful than a full-blown demo such as this. cheers, Ian
Re: [pygame] Sticky Variables: Terrain Loading
On Mar 12, 2008, at 7:54 AM, kschnee wrote:
long1 = water is wet
long2 = water is wet
long1 is long2
False
short1 = water
short2 = water
short1 is short2
True
This really surprises me! I hadn't known about these automatic
optimizations. Yes, I know that == != is, but the rest of it is
news to
me.
Python caches short string values (which must not contain a space) as
an optimization under the assumption that they will be referenced
repeated (such as for dict keys, which are used often internally by
the python interpreter). Since short strings without spaces are often
python identifiers, and referenced very often.
This is an implementation detail of the CPython interpreter (as is the
reuse of integer objects) which should be of little or no consequence
to python programs. You should not rely on identity values (e.g.,
id('foo') or 'foo' is 'foo') for strings, integers and other
primitive types since the interpreter my arbitrarily use singletons
to represent some values. IOW using the is keyword for strings,
integers, floats, etc. is not useful and potentially confusing. To
compare these values for equality, only use ==.
is is typically useful only for class instances and certain special
objects like None. Note that:
a is b
is equivalent to (though much faster than):
id(a) == id(b)
-Casey
Re: [pygame] mapping logical coordinate ????
pygame.display.flip()?
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
Hmm. This might be associated with another problem I've been having. NOT really tried--not near a python interpreter... If I have something like: x = [1,2,3,4,5,6] y = x then changes to y change x. So I've had to: y = [x[0],x[1],x[2],x[3],x[4],x[5]] ...which doesn't change x when y is changed.
Re: [pygame] py2exe problems
On 3/7/08, Brian Fisher [EMAIL PROTECTED] wrote: Getting py2exe to work with PyOpenGL is something I am very interested in, cause I haven't gotten it to work for me yet :( So what still doesn't work with PyOpenGL? What have you tried so far? had you tried this? No, but I will. How exactly do things not work for you? I assume you get an exe but it fails to run? If so, what's the exact error you get in the log file when trying to run it? Yes. I get an .exe. The program says something like: the following modules are not available (and among these is OpenGL.GL, etc.). Then the .exe crashes instantly when run.
Re: [pygame] pystreamer in pygame? NEW USER: CORRECTION GSTREAMER
On 3/7/08, Darren Enns [EMAIL PROTECTED] wrote: My hope/assumption is that some of you in the PyGame community would have used 'gstreamer' in your apps, to display videos/movie clips, etc. Not I, but perhaps someone else... What sort of movies? You mention doing this in 10 lines of code not with PyGame.
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
On Wed, Mar 12, 2008 at 01:06:07PM -0700, Ian Mallett wrote: Hmm. This might be associated with another problem I've been having. NOT really tried--not near a python interpreter... If I have something like: x = [1,2,3,4,5,6] y = x then changes to y change x. So I've had to: y = [x[0],x[1],x[2],x[3],x[4],x[5]] ...which doesn't change x when y is changed. There is an easier way to do this. from copy import deepcopy x = [1,2,3,4,5,6] y = deepcopy(x) Of course, in this example, the deep copy is pointless and wasteful no matter how you implement it, since integer constants are cached internally (as you know already from reading this thread) But as for the subject of copies vs references, be absolutely certain that a copy is really what you want. Many newcomers to python don't understand how rarely a copy is really necessary. Personally, almost every time I have ever used the copy module, I have later removed it after understanding my own code better and realizing it was unneeded. --- James Paige
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
On Mar 12, 2008, at 1:06 PM, Ian Mallett wrote: Hmm. This might be associated with another problem I've been having. NOT really tried--not near a python interpreter... If I have something like: x = [1,2,3,4,5,6] y = x then changes to y change x. That statement is a big misleading, it implies that the changes happen in two places, but both y and x point to the same object, they are in fact the same thing with two different names. You can think of y as an alias for x. So I've had to: y = [x[0],x[1],x[2],x[3],x[4],x[5]] ...which doesn't change x when y is changed. Yipes! You might have an easier time with: y = list(x) which makes a new list object with the same elements as x. Note this is a shallow copy though and although x and y are separate list objects, they have the same objects as elements. This is not important if the elements are immutable (such as strings, ints, etc). But if they are mutable objects like lists or dicts then things might not behave as you expect. Consider this: x = [[1,2], [3,4]] y = list(x) x is y False x == y True x[0].append(3) y [[1, 2, 3], [3, 4]] x == y True Note the same thing would happen copying your way (y = [x[0], x[1]]). Luckily this is not a very common problem, the solution is to only use immutable elements (e.g., tuples) or use deepcopy: http://docs.python.org/lib/module-copy.html -Casey
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
Well it came up in one of my games--you're a player with a position. You can fire projectiles. When the projectiles were fired, changing the projectiles' position caused the player's position to move as well.
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
On Wed, Mar 12, 2008 at 2:38 PM, Ian Mallett [EMAIL PROTECTED] wrote: Well it came up in one of my games--you're a player with a position. You can fire projectiles. When the projectiles were fired, changing the projectiles' position caused the player's position to move as well. I had that same problem -- - pymike (pymike.blogspot.com)
Re: [pygame] pystreamer in pygame? NEW USER: CORRECTION GSTREAMER
Ian Mallett wrote:
On 3/7/08, Darren Enns [EMAIL PROTECTED] wrote:
My hope/assumption is that some of you in the PyGame community would
have used 'gstreamer' in your apps, to display videos/movie clips, etc.
Not I, but perhaps someone else...
What sort of movies?
You mention doing this in 10 lines of code not with PyGame.
Here is a very small example that (I think) is running 'gstreamer' in
Python to easily play a video:
import pygst
pygst.require('0.10')
import gst
import gobject, sys
def play_uri(uri):
player = gst.element_factory_make(playbin, player)
print 'Playing:', uri
player.set_property('uri', uri)
player.set_state(gst.STATE_PLAYING)
play_uri(file:mnt/sda3/dl/python/dare/test.mpg)
import gtk; gtk.main()
In this case, the 'movie' is a simple 'mpeg' file.
Thanks
Dare
Re: [pygame] pystreamer in pygame? NEW USER: CORRECTION GSTREAMER
This may be helpful: http://www.gamedev.net/community/forums/topic.asp?topic_id=470238
Re: [pygame] pystreamer in pygame? NEW USER: CORRECTION GSTREAMER
Perhaps these, too: http://dev.laptop.org/attachment/ticket/1697/camera-add-snap_async.diff https://coherence.beebits.net/changeset/534?format=diffnew=534
Re: [pygame] pystreamer in pygame? NEW USER: CORRECTION GSTREAMER
Ian Mallett wrote: This may be helpful: http://www.gamedev.net/community/forums/topic.asp?topic_id=470238 Cool! Thanks for those links Ian! Dare
Re: [pygame] Angle To Target Function
A nice effect!
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
Ian Mallett wrote: If I have something like: x = [1,2,3,4,5,6] y = x then changes to y change x. That's a rather loose way of talking about it. What's happening is that x and y refer to the same object, so any changes made to that object will be seen through both x and y. The important things to understand are: (1) Python variables always contain references to objects, not the objects themselves. (2) The '=' operation is always reference assignment. It never copies any objects. y = [x[0],x[1],x[2],x[3],x[4],x[5]] ...which doesn't change x when y is changed. Also (3) The [...] notation always constructs a new list object. -- Greg
Re: [pygame] Angle To Target Function
Kris Schnee wrote: Just thought I'd offer this function, which might be useful for characters with following behavior. It finds the angle from one point to another, in degrees, with 0 being up and 90 being right. The math.atan2() function already does most of this. You just need to convert the result from radians to degrees. -- Greg
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
I remember having issues at one point with references as I was confused at why changes to one array changed the other. My work-around has simply been: x = [1, 2, 3] y = x[:] Nice to see there are other methods though. On Wed, Mar 12, 2008 at 9:04 PM, Greg Ewing [EMAIL PROTECTED] wrote: Ian Mallett wrote: If I have something like: x = [1,2,3,4,5,6] y = x then changes to y change x. That's a rather loose way of talking about it. What's happening is that x and y refer to the same object, so any changes made to that object will be seen through both x and y. The important things to understand are: (1) Python variables always contain references to objects, not the objects themselves. (2) The '=' operation is always reference assignment. It never copies any objects. y = [x[0],x[1],x[2],x[3],x[4],x[5]] ...which doesn't change x when y is changed. Also (3) The [...] notation always constructs a new list object. -- Greg -- This, from Jach. How many programmers does it take to change a light bulb? None. It's a hardware problem. How many Microsoft programmers does it take to change a light bulb? None. Microsoft just declared darkness as the newest innovation in cutting-edge technology.
Re: [pygame] pystreamer in pygame? NEW USER: CORRECTION GSTREAMER
Sorry I can't be more help. I'm interested too. Tell me if you get it working.
