Thread: [PyOpenGL-Users] 2D (Re: Bitmaps and Circles?)
Brought to you by:
mcfletch
From: <sn...@so...> - 2004-04-27 05:00:17
|
> If this is really the limit of your interest, OpenGL is probably way too > big a hammer to pull out. Something like PyGame would likely be far > easier to work with, as it has all the device-context-style drawing > facilities most bitmap-oriented development would need. > > BTW, pyopengl-users-admin is the administrative account, you likely > wanted to send the query to pyopengl-users (copied on this message). > > Have fun, > Mike Oops, sorry, must have replied to the wrong message. Ok, so I'm not really writing a small game, but rather an engine - a protable 2d engine written in python that is fast and easy to use - or that was the plan :). I've got the keyboard and mouse interfaces down, all nice and oopy, and I've (with the help of my friend and co-coder) swigged an interface to FMOD (couldn't find any for Python 2.3), and that works perfectly too (it's not all tested, only mostly, but so far it works perfectly). Now the last portion of the engine - for the initial release, at least - is the whole graphic shpiel. PyGame is very nice, I hope I'm not offending anyone - but it is, in my experience, a bit slow. OpenGL is fast (the demos seemed promising, I wrote a few quick programs and liked the resulting fps), and I figured I wouldn't mind going through some hoops to get OpenGL's speed into an oo-2d oriented interface. We've thought of using directX, but it doesn't have any real glu/glut equivalents and we would lose portability, which was part of the whole point in the first place. So anyone have any suggestions? We're really stumped, I figured writing the graphic routines would be the easy part, and instead it's threatning to kill the project :( Amos |
From: Mike C. F. <mcf...@ro...> - 2004-04-27 05:43:57
|
sn...@so... wrote: ... > perfectly). Now the last portion of the engine - for the initial > release, at > least - is the whole graphic shpiel. > PyGame is very nice, I hope I'm not offending anyone - but it is, in my > experience, a bit slow. OpenGL is fast (the demos seemed promising, I > wrote > a few quick programs and liked the resulting fps), and I figured I > wouldn't > mind going through some hoops to get OpenGL's speed into an oo-2d > oriented > interface. Oh, then, go for it, but keep in mind that you're dealing with a system that thinks in terms of points, lines and triangles, so you're going to have to do your own tessellating (though there are some tools that will help with that, such as GLU). gluDisk gives you a simple filled circle if you set the inner radius to 0 setting gluQuadricDrawStyle to GLU_SILHOUETTE will give you empty circles (no fill) with gluDisk. You could also just use the sin and cos ufuncs from Numeric to generate coordinates and draw them using either an array-drawing call or a display list: a = arange(0.0,2*math.pi,.02) xes = sin(a) yes = cos(a) coords = zeros( (len(xes),3),'d') coords[:,0] = xes coords[:,1] = yes (the .02 there says to use .02 radians as the sampling rate, or around 1.1 degrees). As for drawing bitmaps, there's an ARB extension ARB.window_pos which gives simple positioning for bitmaps. There's also simple glDrawPixels (normally pretty slow) and loading a bitmap into a texture and displaying it on a properly-proportioned rectangle aligned with the screen (fast, and basically the "right" way to do it (IMO)). You might want to take a look at PyUI for sample code showing how to do this kind of stuff. IIRC it is using lots of simple orthogonal display of bitmaps, complex shapes (windows, text, etceteras) and is game-targeted. HTH, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Andrew S. <str...@as...> - 2004-04-27 20:16:38
Attachments:
PGP.sig
|
On Apr 26, 2004, at 10:43 PM, Mike C. Fletcher wrote: > sn...@so... wrote: > ... > >> perfectly). Now the last portion of the engine - for the initial >> release, at >> least - is the whole graphic shpiel. >> PyGame is very nice, I hope I'm not offending anyone - but it is, in >> my >> experience, a bit slow. OpenGL is fast (the demos seemed promising, I >> wrote >> a few quick programs and liked the resulting fps), and I figured I >> wouldn't >> mind going through some hoops to get OpenGL's speed into an oo-2d >> oriented >> interface. > > Oh, then, go for it, but keep in mind that you're dealing with a > system that thinks in terms of points, lines and triangles, so you're > going to have to do your own tessellating (though there are some tools > that will help with that, such as GLU). Also don't forget the glSDL backend, which could presumably be ported to pygame (if it hasn't already) a lot more easily than writing yet another graphics engine. |
From: enrike <en...@al...> - 2004-08-24 17:43:06
|
hi i have been installling and uninstalling python and all the modules on my XP machine and now i am getting an error when i try to import GLUT. It says it cannot find it. i have downloaded it and placed it on windows/system32 but then i get another error suggesting this maight not be the right glut32.dll i should be using. This had never happened to me before despite of having installed and uninstalled python several times. Reinstalling pyopengl didnt solve anything. any suggestions? thanks once again -- enrike |
From: Mike C. F. <mcf...@ro...> - 2004-09-11 22:09:18
|
enrike wrote: > hi > > i have been installling and uninstalling python and all the modules on > my XP machine and now i am getting an error when i try to import GLUT. > It says it cannot find it. i have downloaded it and placed it on > windows/system32 but then i get another error suggesting this maight > not be the right glut32.dll i should be using. You'll want to be using GLUT 3.7(.6), probably the Win32 binary release pointed to by the installation page. If you can post the actual error messages it would be far more likely that we I can help diagnose and solve the problem. I'm assuming you're using the binary release on Python 2.3 with PyOpenGL 2.0.1.08, if not, let me know (generally speaking, when asking these kinds of questions it's very useful to give as much information as possible about your software setup). Good luck, Mike ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: enrike <en...@al...> - 2004-09-14 09:55:20
|
hi >> >> i have been installling and uninstalling python and all the modules on >> my XP machine and now i am getting an error when i try to import GLUT. >> It says it cannot find it. i have downloaded it and placed it on >> windows/system32 but then i get another error suggesting this maight >> not be the right glut32.dll i should be using. > > > You'll want to be using GLUT 3.7(.6), probably the Win32 binary release > pointed to by the installation page. If you can post the actual error > messages it would be far more likely that we I can help diagnose and > solve the problem. > > I'm assuming you're using the binary release on Python 2.3 with PyOpenGL > 2.0.1.08, if not, let me know (generally speaking, when asking these > kinds of questions it's very useful to give as much information as > possible about your software setup). I dont understand what went wrong but i finally solve it by copying glut32.dll version 3.7.6 into my windows/system32 folder I just had installed python 2.3.4 then PyOpenGL-2.0.1.07.py2.3-numpy23.exe and then wxPythonWIN32-2.5.1.5-Py23.exe I had also intalled PIL, Numeric-23.0.win32-py2.3.exe and numarray-0.9.win32-py2.3.exe thanks -- enrike |
From: altern <en...@al...> - 2004-10-20 10:16:45
|
hi i am working on the OS X port of a program and I get a "bus error" caused by this opengl code (it didnt happen on Windows) q = gluNewQuadric() anyone knows if this is a bug on pyOpengl under mac? i am opening the opengl canvas on a wx window. i am not sure if this could be part of the problem thanks -- enrike |
From: Patrick H. <pa...@in...> - 2004-10-20 13:52:42
Attachments:
signature.asc
|
altern wrote: > hi > > i am working on the OS X port of a program and I get a "bus error" > caused by this opengl code (it didnt happen on Windows) > q = gluNewQuadric() > > anyone knows if this is a bug on pyOpengl under mac? i am opening the > opengl canvas on a wx window. i am not sure if this could be part of the > problem I have run into this same problem without PyOpenGL involved at all. A Google search turned up this post: http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html By swapping the order of -lGL and -lGLU when linking, I was able to fix the problem I had. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ |
From: altern <en...@al...> - 2004-10-21 09:44:06
|
Patrick Hartling wrote: > altern wrote: > >> hi >> >> i am working on the OS X port of a program and I get a "bus error" >> caused by this opengl code (it didnt happen on Windows) >> q = gluNewQuadric() >> >> anyone knows if this is a bug on pyOpengl under mac? i am opening the >> opengl canvas on a wx window. i am not sure if this could be part of >> the problem > > > I have run into this same problem without PyOpenGL involved at all. A > Google search turned up this post: > > http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html > > By swapping the order of -lGL and -lGLU when linking, I was able to fix > the problem I had. do you mean that on the imports i should swap the order of these instructions? from OpenGL.GL import * from OpenGL.GLU import * I tried this and i get the same error. maybe i dont understand what you mean? -- enrike |
From: Tom D. <td...@yo...> - 2004-10-21 10:08:16
|
>>> i am working on the OS X port of a program and I get a "bus error" >>> caused by this opengl code (it didnt happen on Windows) >>> q = gluNewQuadric() >>> >> I have run into this same problem without PyOpenGL involved at all. A >> Google search turned up this post: >> >> http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html >> >> By swapping the order of -lGL and -lGLU when linking, I was able to >> fix the problem I had. > > do you mean that on the imports i should swap the order of these > instructions? > > from OpenGL.GL import * > from OpenGL.GLU import * > > I tried this and i get the same error. maybe i dont understand what you > mean? Changing the python code won't make any difference. The link instruction above relates to building the pyopengl package. It may be worthwhile to try the pyopengl Demo/NeHe/lesson18.py referenced at the end of the page: http://pyopengl.sourceforge.net/documentation/manual/gluNewQuadric.3G.xml At least this will remove wxpython from the equation. Good luck. |
From: altern <en...@al...> - 2004-10-21 13:47:12
|
Tom Dossis wrote: >>>> i am working on the OS X port of a program and I get a "bus error" >>>> caused by this opengl code (it didnt happen on Windows) >>>> q = gluNewQuadric() >>>> >>> I have run into this same problem without PyOpenGL involved at all. >>> A Google search turned up this post: >>> >>> http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html >>> >>> >>> By swapping the order of -lGL and -lGLU when linking, I was able to >>> fix the problem I had. >> >> >> do you mean that on the imports i should swap the order of these >> instructions? >> >> from OpenGL.GL import * >> from OpenGL.GLU import * >> >> I tried this and i get the same error. maybe i dont understand what >> you mean? > > > Changing the python code won't make any difference. > The link instruction above relates to building the pyopengl package. > > It may be worthwhile to try the pyopengl Demo/NeHe/lesson18.py > referenced at the end of the page: > http://pyopengl.sourceforge.net/documentation/manual/gluNewQuadric.3G.xml > > At least this will remove wxpython from the equation. So you mean that i have to compile myself pyopengl with the changes you mention? There is no other workaround this? -- enrike |
From: altern <en...@al...> - 2004-10-22 18:20:12
|
hi well ... now its working. the only thing i changed is that i was actually creating the q = gluNewQuadric() as a to reuse it so that i dont do it everytime i create a circle. Now i put it into the drawing function and there is no problem. I guess osx didnt like to reuse the object and needs to create one new every time. so before i was doing something like this quad = gluNewQuadric() def drawCircle(inner, radius): global quad gluDisk(quad, inner, radius, 80, 1) and now i am doing something like this def drawCircle(inner, radius): quad = gluNewQuadric() gluDisk(quad, inner, radius, 80, 1) thanks! Tom Dossis wrote: >>>> i am working on the OS X port of a program and I get a "bus error" >>>> caused by this opengl code (it didnt happen on Windows) >>>> q = gluNewQuadric() >>>> >>> I have run into this same problem without PyOpenGL involved at all. >>> A Google search turned up this post: >>> >>> http://lists.apple.com/archives/darwin-development/2003/May/msg00158.html >>> >>> >>> By swapping the order of -lGL and -lGLU when linking, I was able to >>> fix the problem I had. >> >> >> do you mean that on the imports i should swap the order of these >> instructions? >> >> from OpenGL.GL import * >> from OpenGL.GLU import * >> >> I tried this and i get the same error. maybe i dont understand what >> you mean? > > > Changing the python code won't make any difference. > The link instruction above relates to building the pyopengl package. > > It may be worthwhile to try the pyopengl Demo/NeHe/lesson18.py > referenced at the end of the page: > http://pyopengl.sourceforge.net/documentation/manual/gluNewQuadric.3G.xml > > At least this will remove wxpython from the equation. > > Good luck. > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -- enrike |
From: Dave P. <de...@bu...> - 2004-10-24 21:51:14
|
On Fri, 22 Oct 2004, altern wrote: > the only thing i changed is that i was actually creating the q = > gluNewQuadric() as a to reuse it so that i dont do it everytime i create a > circle. Now i put it into the drawing function and there is no problem. I > guess osx didnt like to reuse the object and needs to create one new every > time. OSX's OpenGL implementation requires a GL context to exist before you can create a quadric; this also applies to Linux & probably other Unixes, Windows happens to be different and lets you create a quadric any time. So, if you move your gluNewQuadric() call to happen _after_ you've opened a window (for instance, after calling glutCreateWindow), then it should be fine, and you'll only need to create it once. -- Dave Pape Assistant Professor dav...@ac... Department of Media Study http://resumbrae.com/ University at Buffalo |
From: altern <en...@al...> - 2004-10-25 08:29:31
|
hi dave >>the only thing i changed is that i was actually creating the q = >>gluNewQuadric() as a to reuse it so that i dont do it everytime i create a >>circle. Now i put it into the drawing function and there is no problem. I >>guess osx didnt like to reuse the object and needs to create one new every >>time. > > > OSX's OpenGL implementation requires a GL context to exist before you can > create a quadric; this also applies to Linux & probably other Unixes, > Windows happens to be different and lets you create a quadric any time. > > So, if you move your gluNewQuadric() call to happen _after_ you've opened > a window (for instance, after calling glutCreateWindow), then it should be > fine, and you'll only need to create it once. great. now it does makes sense. thanks > -- > Dave Pape Assistant Professor > dav...@ac... Department of Media Study > http://resumbrae.com/ University at Buffalo > -- enrike |