Thread: RE: [PyOpenGL-Users] Building on Solaris

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

It should work.  What exactly is failing?

Tarn

> It should work.  What exactly is failing?

Using PyOpenGL-2.0.0.44.tar.gz on Solaris 5.8, and running 

python setup.py install >& log

yields an error on src/interface/GL.EXT.vertex_array.c

I believe the error is :

src/interface/GL.EXT.vertex_array.0110.inc: In function
`_glTexCoordPointerEXT':
src/interface/GL.EXT.vertex_array.0110.inc:806:
`GL_TEXTURE_COORD_ARRAY_EXT' undeclared (first use in this function)

I can send the log file if that will help (I did not think it appropriate
to send it to the entire list).

Note: I was able to build PyOpenGL on Debian Linux without hitting this
problem.

Doug Heisterkamp

Hi all,

I week or so ago I had huge problems with getting PyOpenGL to work with my
surfaces from pygame, and I get a lot of help from this list, especially
from Richard Jones.

The surfaces work ok now, I got pyopengl installed ok and even hw
acceleration working on my ancient Matrox G450. I must say that the speed
is pretty impressive too, so pyopengl seems like a very good thing. 

See a screenshot at: 

	http://www.infa.abo.fi/~chakie/cm/snapshot14.jpg 

It's just a brutally simple terrain "engine" that does nothing useful, but
after all started working it sure was fun to develop. :)

	Chakie

-- 
  "You can't trample infidels when you're a tortoise. I mean, all you could
                  do is give them a meaningful look."
                                              -- Terry Pratchett, Small Gods

On Thu, 15 Nov 2001 18:17, Jan Ekholm wrote:
> The surfaces work ok now, I got pyopengl installed ok and even hw
> acceleration working on my ancient Matrox G450.

Hey, I'm running a G400, which I hardly consider ancient :)

> I must say that the speed
> is pretty impressive too, so pyopengl seems like a very good thing.

Yes - I'm hitting slowdowns, and I'd like to figure out if it's because I'm 
either:
  1. doing too much Python
  2. overloading the G400 with draw commands.

Anyone have any suggestions about how to time things? Preferrably not 
profiler-based.

> See a screenshot at:
>
> 	http://www.infa.abo.fi/~chakie/cm/snapshot14.jpg

How are you taking the screenshots?

> It's just a brutally simple terrain "engine" that does nothing useful, but
> after all started working it sure was fun to develop. :)

I'm also working on a terrain engine, though mine is for an arcade-style 
game, so I'm not sure we could usefully share code. It works from two bitmaps 
- a height map and double-resolution colour map. It needs a lot of work :)

   Richard

On Sat, 17 Nov 2001, Richard Jones wrote:

>On Thu, 15 Nov 2001 18:17, Jan Ekholm wrote:
>> The surfaces work ok now, I got pyopengl installed ok and even hw
>> acceleration working on my ancient Matrox G450.
>
>Hey, I'm running a G400, which I hardly consider ancient :)

I have a G200 at home, and that one sure is ancient. It would be fun to
ttest with some really new card, such as some top notch GForce3

>> I must say that the speed
>> is pretty impressive too, so pyopengl seems like a very good thing.
>
>Yes - I'm hitting slowdowns, and I'd like to figure out if it's because I'm 
>either:
>  1. doing too much Python
>  2. overloading the G400 with draw commands.

It also seems to matter a great deal what you do. I experimented with
various ways to apply textures, and when using GL_DECAL things slowed down
to a crawl. It was one single texture used as a background for the scene.
GL_MODULATE and GL_REPLACE was at least 10x faster. Either that mode is
terribly slow to do, or it just isn't accelerated at all in the Matrox
drivers.

I'd say that less Python is always better, but tweaking and OpenGL app for
performnce is a nvere-ending task. There's always something more that can
be done.

>> 	http://www.infa.abo.fi/~chakie/cm/snapshot14.jpg
>
>How are you taking the screenshots?

ksnapshot. I suppose any app would do (xv, display etc), but I just like
that one.

>> It's just a brutally simple terrain "engine" that does nothing useful, but
>> after all started working it sure was fun to develop. :)
>
>I'm also working on a terrain engine, though mine is for an arcade-style 
>game, so I'm not sure we could usefully share code. It works from two bitmaps 
>- a height map and double-resolution colour map. It needs a lot of work :)

Is there any chance I could have a peek anyway? Or at least a shot or two?
I'm always interested in learning from others. The heightmap approach is
probably a very common one, I use it myself. Is your terrain textured,
colored or both?

-- 

              Many an ancient lord's last words had been:
         "You can't kill me because I've got magic aaargh...."
                                      -- Terry Pratchett, Interesting Times

On Sat, 17 Nov 2001 17:54, Jan Ekholm wrote:
> On Sat, 17 Nov 2001, Richard Jones wrote:
> >On Thu, 15 Nov 2001 18:17, Jan Ekholm wrote:
> >> The surfaces work ok now, I got pyopengl installed ok and even hw
> >> acceleration working on my ancient Matrox G450.
> >
> >Hey, I'm running a G400, which I hardly consider ancient :)
>
> I have a G200 at home, and that one sure is ancient. It would be fun to
> ttest with some really new card, such as some top notch GForce3

I remember when quake3 came out, and all I had was a G200. Ran just fine :)

> >> I must say that the speed
> >> is pretty impressive too, so pyopengl seems like a very good thing.
> >
> >Yes - I'm hitting slowdowns, and I'd like to figure out if it's because
> > I'm either:
> >  1. doing too much Python
> >  2. overloading the G400 with draw commands.
>
> It also seems to matter a great deal what you do. I experimented with
> various ways to apply textures, and when using GL_DECAL things slowed down
> to a crawl. It was one single texture used as a background for the scene.
> GL_MODULATE and GL_REPLACE was at least 10x faster. Either that mode is
> terribly slow to do, or it just isn't accelerated at all in the Matrox
> drivers.

Yeah - I'm still learning about the various texture modes. I have the Red 
Book, but haven't read the section on texturing yet. Just played with display 
lists to get little trees on the landscape :)

> I'd say that less Python is always better, but tweaking and OpenGL app for
> performnce is a nvere-ending task. There's always something more that can
> be done.

Yeah, I have a couple of loops in my code - the Exhaust is one of them. Once 
things settle down a little, I'll experiment with moving some of them out 
into C. I've done a fair bit of C extension writing, so it shouldn't be too 
painful.

> >> 	http://www.infa.abo.fi/~chakie/cm/snapshot14.jpg
> >
> >How are you taking the screenshots?
>
> ksnapshot. I suppose any app would do (xv, display etc), but I just like
> that one.

*smacks forehead* sorry, dumb question ;)

> Is there any chance I could have a peek anyway? Or at least a shot or two?
> I'm always interested in learning from others. The heightmap approach is
> probably a very common one, I use it myself. Is your terrain textured,
> colored or both?

It's textured from the colour map ;)

Screenshots, code and ramblings about it all:
  http://goanna.adroit.net/~richard/ufo/

    Richard

Thread: RE: [PyOpenGL-Users] Building on Solaris

pyopengl-users