Re: SDL2 + POGL2 + PDL confluence

2013-08-19 Thread Mason James

On 2013-08-19, at 4:20 AM, Kartik Thakore wrote:

 There is no need to. I made a PDL to SDL_surface work before. And in SDL2 you 
 can create template from surface.

awesome, thanks Kartik


and slightly off-topic but… 
has anyone managed to build POGL on debian-wheezy lately?  i'm getting a 
segfault :/


--
root@vbox1:~# git clone git://git.code.sf.net/p/pogl/code pogl-code
Cloning into 'pogl-code'...
Resolving deltas: 100% (667/667), done.

root@vbox1:~# cd pogl-code/

root@vbox1:~/pogl-code# perl Makefile.PL interface=FREEGLUT verbose 
$verbose set to 1
found libs:
GL = 'GL'
GLU = 'GLU'
GLUT = 'glut'
Testing for OpenGL Extensions
Testing GLUT version
glversion: cd utils;make -f Makefile GLUT_LIB=glut GLUT_DEF=HAVE_GLUT  
clean;make -f Makefile GLUT_LIB=glut GLUT_DEF=HAVE_GLUT 
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0x85e72c0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
Segmentation fault
make: *** [glversion.txt] Error 139

rm -f glversion.txt
rm -f glversion
rm -f glversion.o
cc -I/usr/include -I/usr/X11R6/include -I/usr/local/include 
-I/usr/openwin/include -DHAVE_GLUT -c glversion.c
cc glversion.o -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -L/usr/openwin/lib 
-L/usr/lib/xorg/modules -L/usr/X11R6/lib/modules 
-L/usr/lib/xorg/modules/extensions -L/usr/X11R6/lib/modules/extensions -lGL 
-lglut -lGLU -lXi -lXmu -lXext -lX11 -lm -o glversion
chmod u+x glversion
./glversion  glversion.txt


get_extensions: no extensions found in utils/glversion.txt

--


 
 hi Chris,
 
 i was looking at elmex's construder code recently, and noticed that the 
 passing of an SDL surface to OpenGL was done by dumping the SDL surface to a 
 BMP temp file (via File::Temp), then loading the BMP with OpenGL.
 
 obviously this solution is a little slower than others, but... it should 
 'just work' without much effort
 
 we could always use this lazy technique for initial testing, until a more 
 'correct' solution is sorted with SDL_Texture :)
 
 
 Mason
 




Re: SDL2 + POGL2 + PDL confluence

2013-08-17 Thread Mason James

On 2013-08-17, at 1:37 AM, Chris Marshall wrote:

 On Thu, Aug 15, 2013 at 6:05 PM, Kartik Thakore
 thakore.kar...@gmail.com wrote:
 
 I am definitely interested in helping with this. Perhaps we should make a
 test module that tests just these integration.
 
 It will get latest branches of the 3 projects and run tests.
 
 What do you think?
 
 I'm glad to see the interest but most of the base work
 is still needing to be done as far as the OpenGL stuff.
 We need modern OpenGL support in POGL before a lot of
 the specific development can occur.
 
 However, one important piece that could be investigated
 is how we could make conversion between SDL2 objects
 and PDL objects work.  Ideally we could have a fast
 conversion to take a piddle and use it for an SDL2 surface
 or texture or whatever and similarly for the other direction.
 
 Currently, the approach used for SDL is to create the PDL
 object with the right sized data segment and then pass that
 to SDL to make a surface from that.  I'm not sure what would
 work for SDL2 stuff.
 
 --Chris


hi Chris, 

i was looking at elmex's construder code recently, and noticed that the passing 
of an SDL surface to OpenGL was done by dumping the SDL surface to a BMP temp 
file (via File::Temp), then loading the BMP with OpenGL. 

obviously this solution is a little slower than others, but... it should 'just 
work' without much effort

we could always use this lazy technique for initial testing, until a more 
'correct' solution is sorted with SDL_Texture :)


Mason

Re: SDL2 + POGL2 + PDL confluence

2013-08-16 Thread Chris Marshall
On Thu, Aug 15, 2013 at 6:05 PM, Kartik Thakore
thakore.kar...@gmail.com wrote:

 I am definitely interested in helping with this. Perhaps we should make a
 test module that tests just these integration.

 It will get latest branches of the 3 projects and run tests.

 What do you think?

I'm glad to see the interest but most of the base work
is still needing to be done as far as the OpenGL stuff.
We need modern OpenGL support in POGL before a lot of
the specific development can occur.

However, one important piece that could be investigated
is how we could make conversion between SDL2 objects
and PDL objects work.  Ideally we could have a fast
conversion to take a piddle and use it for an SDL2 surface
or texture or whatever and similarly for the other direction.

Currently, the approach used for SDL is to create the PDL
object with the right sized data segment and then pass that
to SDL to make a surface from that.  I'm not sure what would
work for SDL2 stuff.

--Chris

 On Thu, Aug 15, 2013 at 1:11 PM, Chris Marshall devel.chm...@gmail.com
 wrote:

 PDL/SDL/OpenGL users-

 With the recently announced SDL2 release and in-progress work
 to provide perl bindings for the same, I wanted to share my
 thoughts for leveraging joint capabilities of these three
 modules with a couple of specific points.

 1) SDL2 brings integrated hardware acceleration via Direct3D and/or
 OpenGL to both 2D and 3D graphics. This offers the possiblity
 of using modern OpenGL API features like renderbuffers for
 computation and display.

 2) PDL provides a high level array computation language that
 can be used as a back-end engine for SDL applications and
 visualization. The PDL::Graphics::TriD currently uses
 the OpenGL-1.x fixed pipeline interface.

 3) Perl OpenGL currently supports the original fixed-pipeline
 display process of OpenGL-1.x and some 2.x functionality.
 Work is underway to update the support to modern OpenGL
 APIs such as OpenGL-3.x, OpenGLES,...

 The common thread here is OpenGL, and I think that by updating
 the OpenGL use and interfaces to the modern programmable display
 pipeline we can generate significant synergy between the
 projects:

 1) Update Perl OpenGL to modern OpenGL (In progress by slowed
 by the fact that my development time is spread too thin.
 Am I the only one with a whole slew of projects for which
 I know *exactly* what and how to do them but not having
 the time to execute? :-)

 2) Refactor PDL::Graphics::TriD to use modern OpenGL for
 display rather than the fixed-function pipeline of OpenGL
 API 1.x.

 3) Update PDL to support (simply) the use of arbitrary
 sources of data (e.g., I'm thinking framebuffer and
 renderbuffer objects but deliberately being more
 general since I could also imagine some sort of
 generator that could act like a piddle for computation
 with PDL).

 4) Add GPGPU support to PDL computation.

 5) Add support to the perl SDL2 interface to allow easy
 mix and match operation with PDL for computation, IO,
 and visualization. I could see PDL+GPGPU computing
 working well with realtime game or display computations.

 Well, the above ideas have a some hand waving to make them
 happen, but I think the pieces are there.

 Comments?
 Chris


SDL2 + POGL2 + PDL confluence

2013-08-15 Thread Chris Marshall
PDL/SDL/OpenGL users-

With the recently announced SDL2 release and in-progress work
to provide perl bindings for the same, I wanted to share my
thoughts for leveraging joint capabilities of these three
modules with a couple of specific points.

1) SDL2 brings integrated hardware acceleration via Direct3D and/or
   OpenGL to both 2D and 3D graphics.  This offers the possiblity
   of using modern OpenGL API features like renderbuffers for
   computation and display.

2) PDL provides a high level array computation language that
   can be used as a back-end engine for SDL applications and
   visualization.  The PDL::Graphics::TriD currently uses
   the OpenGL-1.x fixed pipeline interface.

3) Perl OpenGL currently supports the original fixed-pipeline
   display process of OpenGL-1.x and some 2.x functionality.
   Work is underway to update the support to modern OpenGL
   APIs such as OpenGL-3.x, OpenGLES,...

The common thread here is OpenGL, and I think that by updating
the OpenGL use and interfaces to the modern programmable display
pipeline we can generate significant synergy between the
projects:

1) Update Perl OpenGL to modern OpenGL (In progress by slowed
   by the fact that my development time is spread too thin.
   Am I the only one with a whole slew of projects for which
   I know *exactly* what and how to do them but not having
   the time to execute?  :-)

2) Refactor PDL::Graphics::TriD to use modern OpenGL for
   display rather than the fixed-function pipeline of OpenGL
   API 1.x.

3) Update PDL to support (simply) the use of arbitrary
   sources of data (e.g., I'm thinking framebuffer and
   renderbuffer objects but deliberately being more
   general since I could also imagine some sort of
   generator that could act like a piddle for computation
   with PDL).

4) Add GPGPU support to PDL computation.

5) Add support to the perl SDL2 interface to allow easy
   mix and match operation with PDL for computation, IO,
   and visualization.  I could see PDL+GPGPU computing
   working well with realtime game or display computations.

Well, the above ideas have a some hand waving to make them
happen, but I think the pieces are there.

Comments?
Chris


Re: SDL2 + POGL2 + PDL confluence

2013-08-15 Thread Kartik Thakore
Hey Chris,


  


I am definitely interested in helping with this. Perhaps we should make a 
test module that tests just these integration.


  


It will get latest branches of the 3 projects and run tests.


  


What do you think?

On Thu, Aug 15, 2013 at 1:11 PM, Chris Marshall devel.chm...@gmail.com
wrote:

 PDL/SDL/OpenGL users-
 With the recently announced SDL2 release and in-progress work
 to provide perl bindings for the same, I wanted to share my
 thoughts for leveraging joint capabilities of these three
 modules with a couple of specific points.
 1) SDL2 brings integrated hardware acceleration via Direct3D and/or
OpenGL to both 2D and 3D graphics.  This offers the possiblity
of using modern OpenGL API features like renderbuffers for
computation and display.
 2) PDL provides a high level array computation language that
can be used as a back-end engine for SDL applications and
visualization.  The PDL::Graphics::TriD currently uses
the OpenGL-1.x fixed pipeline interface.
 3) Perl OpenGL currently supports the original fixed-pipeline
display process of OpenGL-1.x and some 2.x functionality.
Work is underway to update the support to modern OpenGL
APIs such as OpenGL-3.x, OpenGLES,...
 The common thread here is OpenGL, and I think that by updating
 the OpenGL use and interfaces to the modern programmable display
 pipeline we can generate significant synergy between the
 projects:
 1) Update Perl OpenGL to modern OpenGL (In progress by slowed
by the fact that my development time is spread too thin.
Am I the only one with a whole slew of projects for which
I know *exactly* what and how to do them but not having
the time to execute?  :-)
 2) Refactor PDL::Graphics::TriD to use modern OpenGL for
display rather than the fixed-function pipeline of OpenGL
API 1.x.
 3) Update PDL to support (simply) the use of arbitrary
sources of data (e.g., I'm thinking framebuffer and
renderbuffer objects but deliberately being more
general since I could also imagine some sort of
generator that could act like a piddle for computation
with PDL).
 4) Add GPGPU support to PDL computation.
 5) Add support to the perl SDL2 interface to allow easy
mix and match operation with PDL for computation, IO,
and visualization.  I could see PDL+GPGPU computing
working well with realtime game or display computations.
 Well, the above ideas have a some hand waving to make them
 happen, but I think the pieces are there.
 Comments?
 Chris