Ghost segfault

[GoogleCodeExporter]

Unknown cause, could be one of a number of things.
Going to get some more data from user (OS, dependency versions, etc.)

Original issue reported on code.google.com by RoeB...@gmail.com on 1 Dec 2008 at 2:18

[GoogleCodeExporter]

Ok, some more info.
User is on OSX - which from what I can tell has problems as it is with pyopengl 
stuff.
Only fix I can see now is either someone who has an OSX or experience with them 
to
join the team and test this stuff.
Otherwise, I am going to look into seeing if pyglet will run where pyopengl 
won't, in
which case it may  be an even bigger gain to move over to that than I thought...

Original comment by RoeB...@gmail.com on 1 Dec 2008 at 5:03

• Changed state: Accepted

[GoogleCodeExporter]

I googled around a bit, and think I found the issue:

http://www.freelists.org/post/visionegg/VisionEgg-on-Tiger,3

http://osdir.com/ml/python.opengl.devel/2006-08/msg00000.html

Seems people are using a Pygame built for the wrong version of their OS or 
something
similar...

Original comment by RoeB...@gmail.com on 18 Apr 2009 at 8:33

[GoogleCodeExporter]

This goes beyond pyggel. Ubuntu 9.04 install python2.6 as default.  And other
pygame/opengl things have the same error (pycave0.91). Interestingly this
pygame/opengl example does work when you explicitly run as python2.5: 
http://www.willmcgugan.com/blog/tech/2007/6/4/opengl-sample-code-for-pygame/
Pyggel has the same error when running python2.5 explicitly.

Original comment by duran...@gmail.com on 2 May 2009 at 4:15

[GoogleCodeExporter]

So, is this a PYGGEL issue then?
I know pyggel definitely uses a lot more of OpenGL than wall's stuff...

Also, are you running in pyopengl 2.x or 3.x?

Original comment by RoeB...@gmail.com on 7 May 2009 at 2:56

[GoogleCodeExporter]

I'm using pyopengl 3.0 b6-3.  I've been trying to hunt down the source of this 
--
from what I can tell -- it appears to be stemmed from improper (or not at all) 
OpenGL
initialization.

Original comment by duran...@gmail.com on 9 May 2009 at 4:07

[GoogleCodeExporter]

Submitted revision 427. Needs more work to add back two lines of glScissor in 
the
_Screen constructor and set_size method.

Original comment by duran...@gmail.com on 6 Jun 2009 at 3:30

• Changed state: Started

[GoogleCodeExporter]

Glad someone is working on this, but, not to sound rude, but removing the
create_empty_texture and replacing with a class such as you have is not what 
should
happen.
The reason being is that we don't need every single object creating a new 
texture for
a blank one, that is slower and unnecessary...

Also, I am unsure why the glScissor calls were commented out - surely they 
weren't
causing the segfault?

Original comment by RoeB...@gmail.com on 6 Jun 2009 at 1:58

[GoogleCodeExporter]

Hmm, actually, now that I look closer, I see that you do have caching of the
size/color of blank textures - so it should still work.

Though I'm still wondering about the scissor calls - are they failing?

Original comment by RoeB...@gmail.com on 7 Jun 2009 at 5:10

[GoogleCodeExporter]

glScissor calls are failing and I'm not sure why. I haven't completely polished 
the 
blank texture caching but it should be cached just like textures from images.

Original comment by duran...@gmail.com on 7 Jun 2009 at 4:03

[GoogleCodeExporter]

Although what is the performance (or otherwise) difference of the size of a 
blank 
texture? If there isn't any should all blank textures just be 1 pixel 
(size=1,1)?

Original comment by duran...@gmail.com on 7 Jun 2009 at 5:38

[GoogleCodeExporter]

There is not a performance issue I know of (smaller should probably be faster 
though)
- but a fair bit of code makes use of generating blank textures of a specific 
size,
like the frame buffers and such.

I'll look into it more later when I have my computer back ;)

Original comment by RoeB...@gmail.com on 7 Jun 2009 at 6:57

[GoogleCodeExporter]

Perhaps with the scissor the wrong kind of args are being submitted? Otherwise 
I dunno...

Original comment by RoeB...@gmail.com on 8 Jun 2009 at 5:21

[GoogleCodeExporter]

I just committed some other stuff to work on the caching, so it (hopefully) 
works a
little better...
Also, can you try adding this command to a demo to test the Scissor?
glScissor(0,0,640,480)

Cheers, and good work so far :)

Original comment by RoeB...@gmail.com on 9 Jun 2009 at 9:10

[GoogleCodeExporter]

Revision 429.  Uncommented the important glScissor and moved a call to
_Screen.set_size() to after opengl is initialized.

Original comment by duran...@gmail.com on 10 Jun 2009 at 5:37

• Changed state: Fixed

[GoogleCodeExporter]

Issue 10 has been merged into this issue.

Original comment by duran...@gmail.com on 10 Jun 2009 at 5:42

[GoogleCodeExporter]

Aha, that makes sense...
And no, I don't think that first scissor is necessary, as it defaults to the 
window
size IIRC, I think I was doing that before for some consistency with the later 
set
size thing (thinking I would jus use set_size there as well) but that never 
worked so
I left it :S

Great work mate! XD

Original comment by RoeB...@gmail.com on 10 Jun 2009 at 1:59