Re: [pygame] PyGameDB coming along well
2008/8/20 Hugo Arts [EMAIL PROTECTED]: well, damnit. I loved that name. the problem i see with Flying Circus is that will be pointless searching python flying circus on google -- .__.·º(foolhu!) (oO) / | | \
Re: [pygame] Pygame, cwiid and ode - movement
2008/8/7 Luke Paireepinart [EMAIL PROTECTED]: On Thu, Aug 7, 2008 at 4:53 AM, Hugo Arts [EMAIL PROTECTED] wrote: you might want to post this on a wiimote development oriented mailing list/forum. This is not really a pygame-related question. At least include some additional details. Your question is really vague. Perhaps you will also benefit from reading this: http://www.catb.org/~esr/faqs/smart-questions.html#intro Hugo On Thu, Aug 7, 2008 at 11:39 AM, flx [EMAIL PROTECTED] wrote: Hi all I'm trying to make a foosball [1] game wth pygame, using the wiimote to control the bars. I've managed to control the rotation using the accelerometers, but i can't get the sliding part right. I've been asked to use the ir sensors for the sliding movement, but I just can't get it right. Have someone done this before? is there anywhere i can look for a similar usage of the wiimote or ask for help? Just keep track of the 2 biggest IR points, and use trigonometry to calculate the distance to the edge between the IR based on their spacing. Then use the default IR spacing of the Wii hardware (and a camera field of view of 45 degrees) to calculate how far you are from it. It's pretty simple math. that's more or less what i was doing, but it didnt gave me the expected result, mostly because reflections and sources going out of sight. I'm trying to dealt with reflections tracking only points with, more or less, the same distance between them that they had the last time I registered them, but if you loose sight of one the ir source it acts weird. I'm thinking in a hybrid, acc + ir, way of achieving this. Check wiibrew.net/com/org (whichever it is) and wiili.org, specifically the Wii Remote articles. They have some details about IR. Let me know if you have more specific questions about the Wii Remote (you can ask me off-list if you want.) -Luke Thank you very much, I didn't know wiibrew.org and it looks promising -- .__.·º(foolhu!) (oO) / | | \
Re: [pygame] Pygame, cwiid and ode - movement
2008/8/7 Nathan Whitehead [EMAIL PROTECTED]: On Thu, Aug 7, 2008 at 2:39 AM, flx [EMAIL PROTECTED] wrote: I'm trying to make a foosball [1] game wth pygame, using the wiimote to control the bars. I've managed to control the rotation using the accelerometers, but i can't get the sliding part right. I've been asked to use the ir sensors for the sliding movement, but I just can't get it right. I think you have two separate questions here: * how to get IR working on the wiimote and get IR data * once IR is working, how to interpret the data to make the paddle slide around correctly For the first part: which Wiimote library are you using? Does it support IR? Is it buggy with your particular Wiimote/bluetooth combination? What operating system are you using? I'm using the libcwiid python moudule (so it's under linux) wich works well with my hardware, i've written some documentation covering the basics of interfacing using python-cwiid here [1] For the second part: I recommend making a simple program that just displays squares at the reported IR positions, setting the screen to 1024x768. Then try moving the Wiimote around and take notes about where the squares go. Where do they go when you slide left? What about when you point downwards? Rotate clockwise? Then use those notes to write code to control the paddle directly. You might need some calculations here (argh, math!). Doing exactly this i realized that my problems were the reflections and the points going out of sight, right as you say below Once you've got this down you will have control of the paddle but it will be jerky and flickery. Also when you move too far to the edge of the screen the paddle will stop moving (one IR dot goes off screen). To fix the jerkiness, a first step is averaging several values over time. A better but harder approach is a Kalman filter. Didn't kow about Kalman filter (i'm rushing to wikipedia now :) ) but definetly some kind of estimation will help To fix the flickery problem: if there are 0 dots reported, use the most recent positions. That stops the input from disappearing for a frame. If there are too many dots (3 or more), then you want to pick the 2 dots closest to the last reported IR positions. To fix the edge-of-the-screen problem, a good approach I've used is to guess where the missing IR dot should be. I assume that the dot off the edge of the screen moves just like the one that remains on the screen. This won't be strictly true if the wiimote is rotating or changing distance to the sensor bar, but it will keep the paddle responding to input rather than stopping abruptly at the edge of the screen. I was thinking of working with the accelerometers when not enough ir data is avaliable, it definetly won't be nearly as accurate, but could work FYI: I'm working on a pygame library that supports the wiimote on all platforms, it will be done Real Soon Now. -- Nathan Whitehead Thanks, you've given me some very useful insight [1] - http://flx.proyectoanonimo.com/proyectos/cwiid/ -- .__.·º(foolhu!) (oO) / | | \
[pygame] Pygame, cwiid and ode - movement
Hi all I'm trying to make a foosball [1] game wth pygame, using the wiimote to control the bars. I've managed to control the rotation using the accelerometers, but i can't get the sliding part right. I've been asked to use the ir sensors for the sliding movement, but I just can't get it right. Have someone done this before? is there anywhere i can look for a similar usage of the wiimote or ask for help? [1] - http://en.wikipedia.org/wiki/Table_football -- .__.·º(foolhu!) (oO) / | | \
Re: [pygame] Licensing
2008/6/30 Michael [EMAIL PROTECTED]: [...] No. LGPL is if you change our stuff and redistribute it, you must redistribute the changes to our stuff, oh and feel free to relicense under GPL. GPL is use and alter but only if the derivative is free. No. GPL is if you use our stuff and are dependent on it your stuff must be GPL. This is a common misunderstanding, you don't have to license something under *gpl just because you are _using_ something *gpl on it. You can create privative software using gpl libraries and utilities as long as you distribute them under the same license. What you can't do is modify something under *gpl and distribute it under a privative license AGPL is use but whatever you make must be AGPL. Assuming you mean Affero GPL. AGPL is if you use our stuff in a webservice, your stuff must also be AGPL, and must provide an offer for the source of both your and our stuff Again, not using, but distributing a modified version Artistic is use but alter only with permission. Artistic is pretty much share and enjoy - and try to play nicely please. (ish) BSD is use it for whatever. BSD is credit me and if you redistribute the source, don't remove my headers saying this, but don't feel you have to redistribute any source - yours or mine. BSD and LGPL are very close in that if you don't modify the source that you recieve you can use it as a library and /largely/ ignore licensing issues. If your tendency is to credit anyone who you get code from, that makes it trivial to comply with their conditions. If your natural tendency is to share your code changes, but don't want to impose your license on others, then the BSD LGPL license have the advantage of being widely used and understood meaning your code's license will play nicely and interoperate with other code's licensing. The exception is if your code is in perl, in which case people should generally use the artistic license (if they want that general kind of license), since it's really designed with perl in mind. Michael. -- .__.·º(foolhu!) (oO) / | | \
Re: [pygame] pyopengl sprite/particle performance
2008/6/16 Hugo Arts [EMAIL PROTECTED]: Your bottleneck might not be in your rendering code. I don't know wether PyOpenGL is even supposed to be much faster than pygame, but if rendering is not where your bottleneck is, switching will not help at all. You are right, i'll try something like sprite pooling for particles or something similar. I didn't look at the code, but in the profile it seems _collide_bullet is a frequently used method. Are you using a naive collision detection algorithm? In that case, something like a quadtree or cell-based collision detection approach may heavily improve the performance of your game. The collision detection is a simple bounding spheres method using square distances, I don't think that building a quadtree would be much faster but I'll give it a try too when i have some time Aniway, i believe that particles are what are making the whole thing lag and they aren't counted for collisions, so i'll check the particle updating methods Hugo thanks for your reply [1] - http://code.google.com/p/pyship/ -- .__.·º(foolhu!) (oO) / | | \ -- .__.·º(foolhu!) (oO) / | | \
[pygame] pyopengl sprite/particle performance
Hi all I've been fidling for some time with pygame on a tryout project [1], it's a fast 2d action game. After a while i switched the drawing code to pyopengl looking for a litle performance boost, but i haven't got the expected results, i have had to lower the global fps from 60 to 30 and even then, it lags with 150-200 sprites on screen. I know there must be something wrong with my code because there are more complicated things drawn with pyopengl. This are the first lines of profiling output (switch to monospace font now ;) ) 6202178 function calls in 52.748 CPU seconds ncalls tottime percall cumtime percall filename:lineno(function) 1480666.5070.000 28.7800.000 gl.py:114(draw) 2006205.5320.000 27.8060.000 wrapper.py:650(wrapperCall) 2006163.8280.0003.8280.000 numpymodule.py:114(contiguous) 2006163.5790.0005.6220.000 numpymodule.py:19(dataPointer) 7665402.8030.0003.0000.000 error.py:167(glCheckError) 4406602.3680.0003.8150.000 ship.py:60(_collide_bullet) code referenced is on [1] or running svn checkout http://pyship.googlecode.com/svn/trunk/ pyship recomended since the tarbal is several days old and there are some particle and sprite especific examples on the svn [1] - http://code.google.com/p/pyship/ -- .__.·º(foolhu!) (oO) / | | \
