I think it will with SDL_Texture.
http://wiki.libsdl.org/moin.fcg/SDL_Texture
On Fri, Aug 16, 2013 at 9:37 AM, Chris Marshall <devel.chm...@gmail.com>
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
>> 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
