Re: [pygame] PyOpenGL
On Aug 8, 2006, at 8:10 PM, Simon Wittber wrote: On 8/9/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Eh? What does scipy or numarray have to do with it? Totally different packages. Especially scipy. They all provide facilities for array manipulation. import Numeric import numarray import scipy n = 1500 a_numeric = Numeric.arange(1., n) a_numarray = numarray.arange(1., n) a_scipy = scipy.arange(1., n) The arrays you get (from scipy trunk anyway) are provided by numpy, but were provided by other packages in the past. SciPy doesn't actually implement any of that stuff, it's simply provided in the namespace as a convenience for users. On a different node, I've attached CSV file with results from this benchmark program, with a third test for scipy. http://arbutus.mcmaster.ca/dmc/numpy/numcomp.py Interestingly numarray consistently beats numeric and scipy with arrays of length greater than 1500. With arrays smaller than 1500, SciPy and Numeric are often on par with each other. Beating Numeric's performance on large arrays was the whole point of numarray. I'd imagine that beating both Numeric and numarray in performance is an eventual goal of numpy, but I wouldn't expect a whole lot given its age. However, it seems that the community is gravitating towards numpy and away from both numarray and Numeric, so it may not take all that long. -bob
Re: [pygame] PyOpenGL
On 8/9/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Eh? What does scipy or numarray have to do with it? Totally different packages. Especially scipy. They all provide facilities for array manipulation. import Numeric import numarray import scipy n = 1500 a_numeric = Numeric.arange(1., n) a_numarray = numarray.arange(1., n) a_scipy = scipy.arange(1., n) I think the confusion results from people using the word 'numpy' to refer to the Numeric package, and he numarray package. I actually cannot find a package which lets me 'import numpy'... [...5 minutes later with google...] It seems array stuff has been moved out of scipy core, and into a numpy package. From http://numeric.scipy.org/ : For about 6 months, the new package was called SciPy Core (not to be confused with the full SciPy package which remains a separate package), and so you will occasionally see references to SciPy Core floating around.It was decided in January 2006 to go with the historical name of NumPy for the new package. Realize that NumPy (module name numpy) is the new name. Do not be confused by references to scipy_core. These should all be replaced by numpy. Also, because of the name-change, there were a lot of dicussions that took place on [EMAIL PROTECTED] and [EMAIL PROTECTED] On a different node, I've attached CSV file with results from this benchmark program, with a third test for scipy. http://arbutus.mcmaster.ca/dmc/numpy/numcomp.py Interestingly numarray consistently beats numeric and scipy with arrays of length greater than 1500. With arrays smaller than 1500, SciPy and Numeric are often on par with each other. -Sw. "Array Size",Numeric,Numarray,Scipy,Fastest 1,1.62123919964e-06,4.67061282635e-06,1.61885501385e-06,Scipy 2,1.64984942913e-06,6.57080890179e-06,1.61170245647e-06,Scipy 3,1.66892291546e-06,5.64097644329e-06,1.65938617229e-06,Scipy 4,1.65938617229e-06,5.55037738323e-06,1.63792850018e-06,Scipy 5,1.67130710125e-06,5.5599141264e-06,3.29970599651e-06,Numeric 6,1.68084384441e-06,5.63143970013e-06,1.68084384441e-06,Numeric 7,1.70945407391e-06,5.59090854168e-06,1.68084384441e-06,Scipy 8,1.69038058758e-06,5.63143970013e-06,1.68084384441e-06,Scipy 9,1.72137500286e-06,6.04867221355e-06,1.69991733074e-06,Scipy 10,1.90972568035e-06,5.72919131756e-06,1.90972568035e-06,Numeric 20,1.85012103558e-06,5.81979037762e-06,1.85965777874e-06,Numeric 30,2.04085589886e-06,5.86032153606e-06,6.92843677044e-06,Numeric 40,2.12907077312e-06,6.11066104412e-06,2.12907077312e-06,Numeric 50,2.17913867474e-06,6.02006198406e-06,2.15052844524e-06,Scipy 60,2.29119540691e-06,6.089203372e-06,2.31026889324e-06,Numeric 70,2.39133121014e-06,6.17980243206e-06,2.37941028118e-06,Scipy 80,2.64167071819e-06,6.21079684734e-06,2.61067630291e-06,Scipy 90,2.52007724285e-06,6.18933917522e-06,3.05175067425e-06,Numeric 100,2.6917386198e-06,6.33954288006e-06,2.69889117718e-06,Numeric 110,2.73942233562e-06,6.33954288006e-06,2.73942233562e-06,Numeric 120,2.83002139568e-06,6.48020984173e-06,2.83002139568e-06,Numeric 130,2.87055255413e-06,6.38961078167e-06,2.87055255413e-06,Numeric 140,2.93015719891e-06,6.45159961224e-06,2.87055255413e-06,Scipy 150,2.97068835735e-06,8.46146823406e-06,3.02075625896e-06,Numeric 160,3.08036090374e-06,6.65187121868e-06,3.03982974529e-06,Scipy 170,3.0898976469e-06,6.49928332806e-06,3.08036090374e-06,Scipy 180,3.3020901823e-06,6.83068515301e-06,3.28063251019e-06,Scipy 190,3.3307004118e-06,6.6995549345e-06,3.3307004118e-06,Numeric 200,3.32831622601e-06,7.67945529461e-06,3.30924273968e-06,Scipy 210,3.43083621502e-06,6.82114840984e-06,3.58103991985e-06,Numeric 220,3.46898318768e-06,6.8592953825e-06,3.44990970135e-06,Scipy 230,4.68968631268e-06,6.89028979778e-06,3.57865573406e-06,Scipy 240,3.65971805096e-06,6.84975863934e-06,3.71932269573e-06,Numeric 250,3.74078036785e-06,7.56978274822e-06,3.73839618206e-06,Scipy 260,3.82899524212e-06,6.95943118572e-06,3.82184268475e-06,Scipy 270,3.85045291424e-06,6.97135211468e-06,4.06979800701e-06,Numeric 280,3.96012546062e-06,7.18831302166e-06,3.9410519743e-06,Scipy 290,4.0197301054e-06,7.12155581951e-06,4.0197301054e-06,Numeric 300,4.95909930706e-06,7.25983859539e-06,4.10079242229e-06,Scipy 310,4.15801288128e-06,7.16923953533e-06,4.19139148235e-06,Numeric 320,4.24861194134e-06,7.94886828899e-06,4.27006961346e-06,Numeric 330,4.27006961346e-06,7.41957904339e-06,4.32967425823e-06,Numeric 340,4.42027331829e-06,8.25165988445e-06,4.32967425823e-06,Scipy 350,4.49179889202e-06,7.3909688139e-06,4.47987796307e-06,Scipy 360,4.60862399578e-06,7.64846087933e-06,4.58955050945e-06,Scipy 370,4.62054492474e-06,7.51017810345e-06,4.59908725262e-06,Scipy 380,4.65869189739e-06,7.47918368816e-06,5.1617550993e-06,Numeric 390,4.88995791912e-06,7.59124042034e-06,4.7898221159e-06,Scipy 400,4.87088443279e-06,7.59124042034e-06,5.74826480389e-06,Numeric 410,4.91141559124e-06,7.61031390667e-06,4.91141559124e-06,Numeric 420,4.99009372234e-06,7.74144412518e-06,5.53845645428e-06,Numeric 430,5.03062488079e-06,7.74859668255e-06,5
Re: [pygame] PyOpenGL
On Aug 8, 2006, at 6:54 PM, Simon Wittber wrote: On 8/9/06, Brian Fisher <[EMAIL PROTECTED]> wrote: The PyOpenGL Sourceforge home page is the one that lists the dependencies: http://pyopengl.sourceforge.net/documentation/installation.html in particular, that page lists: # Tcl/Tk appropriate for your Python version # GLUT 3.7+ # Python Imaging Library (PIL) any recent version # Numeric Python (Numpy) v. 23 (for PyOpenGL 2.0.1.08) all as dependencies, but each of those is optional Ah. Numeric Python v. 23 is actually referring to the Numeric module, not the newer numpy module, despite the (Numpy) reference. This is not such a bad thing, as Numeric is apparently faster for small arrays. http://arbutus.mcmaster.ca/dmc/numpy/ The whole Numeric / numarray / numpy / scipy thing is getting a bit confusing. Eh? What does scipy or numarray have to do with it? Totally different packages. Especially scipy. numpy is basically just "Numeric 2.0"; it is officially the successor to Numeric. They happened to (eventually) change the package name from Numeric to numpy in the process, which is actually a good thing because that means they can coexist. The project's name has always been Numerical Python and numpy when shortened. That can be confusing, sure, but a this point extremely few projects depend on numpy, since it's effectively bleeding-edge. -bob
Re: [pygame] PyOpenGL
> The whole Numeric / numarray / numpy / scipy thing is getting a bit confusing. I agree. Bloody nightmare. Alan
Re: [pygame] PyOpenGL
On 8/9/06, Brian Fisher <[EMAIL PROTECTED]> wrote: The PyOpenGL Sourceforge home page is the one that lists the dependencies: http://pyopengl.sourceforge.net/documentation/installation.html in particular, that page lists: # Tcl/Tk appropriate for your Python version # GLUT 3.7+ # Python Imaging Library (PIL) any recent version # Numeric Python (Numpy) v. 23 (for PyOpenGL 2.0.1.08) all as dependencies, but each of those is optional Ah. Numeric Python v. 23 is actually referring to the Numeric module, not the newer numpy module, despite the (Numpy) reference. This is not such a bad thing, as Numeric is apparently faster for small arrays. http://arbutus.mcmaster.ca/dmc/numpy/ The whole Numeric / numarray / numpy / scipy thing is getting a bit confusing.
Re: [pygame] PyOpenGL
On 8/8/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: Since when does PyOpenGL require NumPy? The version I see is from Jan 2005, about a year before NumPy even existed (under that name as its own project). The confusion is how the PyOpenGL site defines a "dependency"... PyOpenGL "requires" NumPy in a lot of the same ways that PyGame requires numeric... looks like most of the optional dependencies have to do with "OpenGLContext" (I don't know what that is exactly, but you don't need it with pygame + PyOpenGL) see here: http://pyopengl.sourceforge.net/context/numeric_arrays.html The answer to your question is most definitely "No." because normal use involves just built-in types... but did PyOpenGL move away from sourceforge, or is your question simply not based on reality? The PyOpenGL Sourceforge home page is the one that lists the dependencies: http://pyopengl.sourceforge.net/documentation/installation.html in particular, that page lists: # Tcl/Tk appropriate for your Python version # GLUT 3.7+ # Python Imaging Library (PIL) any recent version # Numeric Python (Numpy) v. 23 (for PyOpenGL 2.0.1.08) all as dependencies, but each of those is optional
Re: [pygame] "DarkSide" Demo
> It's playable, but has bad "production values." I'd like to know how to > improve, so any advice and criticism would be helpful. You might try a more exciting font. Nothing crazy like a handwriting font (hard to read) but something a touch more thematic. Also the text needs some margin space instead of being right up against the border of each window. (Actually the windows themselves maybe shouldn't run right up to the window border either) There could be different font sizes or colors as well to separate separator text like "Day 2" from the rest of the text. Word wrapping was still a little off, but I figure that's already a known issue. Mainly I had trouble trying to keep track of context. In other words, how far am I currently drilled down in the interface's hierarchy right now? Maybe different colors for different areas of the navigation? When I'm viewing a location, the photo of that location switches from right aligned to left aligned. This is more of a bug report that a suggestion for production improvements, but the music seemed to run the "SW Synth" channel of my sound mixer up to full volume when starting, and when switching songs (this is on Windows XP). Alan
Re: [pygame] PyOpenGL
On Aug 8, 2006, at 2:28 PM, Kris Schnee wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Since when does PyOpenGL require NumPy? The version I see is from Jan 2005, about a year before NumPy even existed (under that name as its own project). The answer to your question is most definitely "No." because normal use involves just built-in types... but did PyOpenGL move away from sourceforge, or is your question simply not based on reality? -bob
[pygame] the cookbook
The cookbook is coming along nicely, 11 entries, including some nice OpenGL stuff! Some of this stuff could be quite useful for the upcoming pyweek compo. Brainstorming further possible entries: Simple physics More 3D model file format loaders HTTP high score system Particle Systems More procedural effects A music synthesizer (like Phil Hassey's 64k challenge entry) Anyone want to have a crack at these? :-) -Sw.
Re: [pygame] PyOpenGL
On 8/9/06, Kris Schnee <[EMAIL PROTECTED]> wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Last time I checked... I was using Numeric for PyOpenGL arrays, and it worked. As for documentation, you can always use internal docstrings if you need to. I've personally only had to look up documentation for Numeric 3 times over the last 12 months. Everything else I get from docstrings, tutorials, the source and other people's code. Having said that, you will only need to use arrays in PyOpenGL when you are doing things like bulk sending of vertices, texture coords, normals and color data to the video card for use with glDrawArrays and other, similar functions. You can go a long way in OpenGL without needing to use any of these facilities. -Sw.
Re: [pygame] PyOpenGL
On 8/8/06, Kris Schnee <[EMAIL PROTECTED]> wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Isn't that begging the question? Honestly though, I use PyOpenGL, and I can't see how NumPy is used by PyOpenGL at all... in particular I haven't found any features of PyOpenGL which require me to write any code using NumPy, so I haven't had any need for documentation at all.
[pygame] PyOpenGL
I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Kris
[pygame] "DarkSide" Demo
kschnee.xepher.net/darkside_demo.zip Here is a playable demo of a game, "DarkSide," about 4 MB. Months ago I released a text-based game showing off the mechanics of a game where you try to take over the city with a squad of homemade robots. This is the graphical version. It's playable, but has bad "production values." I'd like to know how to improve, so any advice and criticism would be helpful. Kris
Re: [pygame] Gradient Algorithm
Nelson, Scott wrote: How 'bout throwing this in the Cookbook? http://www.pygame.org/wiki/CookBook Done. Kris
Re: [pygame] My solid tile detection doesn't work
Thanks to Scott and his question on rects, and Brian's tip on internal documentation - thanks guys - my little dude can run around and bump into bushes and things quite well. Yet there remains one problem... When he's positioned in between tiles, he can walk up or down onto part of a solid tile, because I used his rect.centerx, i.e. directly between his feet, as the point to check for collisions. I want to check everywhere under his little feet. Do I have to check twice, on his left and his right, or is there a simpler way to do the collision checking. Oh, and I don't have this problem going left and right because I set his feet (rect.bottom) as the point for collision checking, so it just looks like he has height, which he should. On 7/23/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: Yes, playerpos and tilepos are supposed to be the same domain. I realised that the camera coordinates were not taken into consideration. When I did take them into consideration, it only reported the right tile when I moved horizontally. Vertical motion is still all wonky. I relabelled the player coordinates so I could walkthrough my algorithm more clearly. I'm still at a loss as to what I'm doing wrong... On 7/22/06, Brian Fisher <[EMAIL PROTECTED]> wrote: > I assume that the problem you have is that the player draws over > different tiles than the attached code is saying the player is moving > over? > > If that's the case the code you sent could be perfectly correct, or it > could be wrong, it really depends on how the coordinates in these > routines are interpreted by other parts of the system, like when you > blit... what I'm thinking of is that it's impossible to tell from this > code alone whether the player_x and player_y values you pull from > player_pos are supposed to be in the same domain as the computed > "truex" and "truey" for a tile - meaning are they both supposed to be > used in the exact same way & are they supposed to be comparable (i.e. > do you blit tiles at truex,truey and players at playerx,playery?) > > My general tip for doing stuff with coordinates is to always think of > different coordinates as being parts of different named coordinate > systems or domains, and always name variables with a suffix that makes > the coordinate system explicit. Like if coordinates can be blit to the > screen, they could be "player_screen_x", if they are supposed to be > map grid locations it might be "player_map_grid_x" if it's supposed to > be a pixel offset in the map it might be "player_map_pixel_x". It may > seem like a lot of typing at first, but it really makes you think > about coordinates more, and in the end you are typing lines that read > like English sentences, so it's easier for you to know if the line is > doing the right thing at a glance, and it's really easy for other > people to look at your code. > > So one thing I notice is that your mapping from a "tilepos" to a > "true" position for all your tiles depends on the values of starty and > startx and xoff and yoff, while the mapping from "playerpos" to a > "tilepos" doesn't use startx and starty or xoff and yoff at all - so > if both "true" coordinates and "player" coordinates are in the same > domain (like if you pass them directly to pygame to blit) then your > mappings aren't symmetric when any of startx, starty, xoff and yoff > are non-zero. > > And if playerpos and tilepos are not supposed to be the same domain > (i.e. there is some other mapping of playerpos and "truex, truey" > before they get blit), then there may be problems with that other > coordinate mapping code in addition to any problems that might exist > in this code. > > On 7/22/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: > > In my little RPG engine-like thing that no one tested, *wink wink*, I > > tried implementing solid tiles. My algorithm doesn't work, and I don't > > know why. > > > > This is the code I use to place tiles onscreen, only the important > > half of the function: > > ---code--- > > for y in range(starty, endy): > > for x in range(startx, endx): > > tilepos = y*(self.mapw) + x; #The position in our array of tiles > > showx = x - startx; showy = y - starty #Adjust the position of map > > by blitting it to the top > > truex = (showx*tilesize-xoff); truey = (showy*tilesize-yoff) > > #print endy > > tilenum = self.tiles[tilepos] > > self.put_tile(tilenum,(truex,truey), screen) > > ---code--- > > > > and this is the code I used to look for a solid tile: > > > > ---code--- > > player_x, player_y = player_pos > > p_tilex = player_x//tilesize; p_tiley = player_y//tilesize > > n_tilex = n_tiley = 0 > > > > if direction == 'left': > > n_tilex = (player_x - speed)// tilesize > > if direction == 'right': > > n_tilex = (player_x + speed)//tilesize > >
Re: [pygame] Rects and they handle right and bottom borders
You know, this made me realise that the 'overlapping' of rects was part of the problem with my collision detection... I have a few - 1's to put in now... On 8/1/06, Nelson, Scott <[EMAIL PROTECTED]> wrote: Thanks all for the responses. They really solidified my understanding of Rects. Very helpful... -Scott
