Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-03 Thread chm

On 7/1/2011 7:22 PM, Adam Kennedy wrote:

All mainstream win32 have snake now, they just don't have any other makes


What is snake?  I don't seem to have it on
my winXP box.

--Chris


On Jul 2, 2011 8:40 AM, chmdevel.chm...@gmail.com  wrote:

On 7/1/2011 10:24 AM, Kartik Thakore wrote:


=head2 OpenGL 3.0
=blame kthakore, chromatic
=for kthakore, Chris, jtpalmer

This comes from the following observations ( feel free to scold/correct
me ).

=over

=item Convergence to OpenGL

SDL 1.3 is moving over to OpenGL. Having the ability to do neat things
with OpenGL this will help to add more performance, speed and
flexibility to the module.

=item POGL still uses FreeGLUT

POGL albeit great is getting ... old. FreeGLUT is slowing down ( SDL
replaces this fine and we have tests to prove it see construder. It is
an extra dep.


FreeGLUT is the default window provider for POGL.
Any GUI toolkit that supports creating OpenGL contexts
and setting them should work fine. I'm looking into
factoring out the GUI dependencies so that POGL works
better with other GUI toolkits to provide the OS and
window system support.


=item OpenGL 3.3 is a fixed target

New OpenGL is all the way up to 4.x now. OpenGL 3.3 has been around for
a while and is not going to be using.

=back

Based on this I think we should attempt to help the POGL dev with
whatever he needs. I will move it to github at some point. Additionally
chip during my talk you mentioned some technology for doing OpenGL
context/display lists better. Can you mention it again chip? I seem to
have forgotten it.


I'm not sure what the issues with context/display
lists might be but would be interested to hear.

As I see it, the top missing feature in Perl OpenGL
is support for OpenGL versions greater than 2.x.
Work is underway to refactor POGL to use GLEW for
the bindings. That should improve portability and
capability (GLEW supports pretty much all current
OpenGL versions).

The next priority for POGL is the build process
which is hamstrung by a static probe for system
capabilities and requires a shell and make to
work. I would like to move detection of needed
libraries to an Alien::Module and to Module::Build
for POGL itself which would avoid some of the
portability problems with win32---no shell, no
make, no package manager. I would like to see
POGL build on win32 platforms *without* requiring
a MSYS or cygwin install to get things to work.

Regards,
Chris Marshall


The hope will be to make a declarative for OpenGL constructs that can be
sent straight to the hardware. Adam Kennedy has some work start in this
area (OpenGL::List).


Regards,






-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1388 / Virus Database: 1516/3738 - Release Date: 07/01/11




PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread Kartik Thakore
Hello folks, 

YAPC::NA 2011 was a blast and I wish more of the PerlGameDev folks were
there. Now I hope to think I am a get things done guy. But really I
couldn't have done any of the stuff without any of you guys (FROGGS,
garu, jtpalmer, kmx and many others!). I have posted my talk and notes
at http://yapgh.blogspot.com/  .

Apologies to Module Authors and Perl6 for invading your mailing lists
but I am hoping some of these projects are interesting to others who
want to help with PerlGameDev and the below projects. 

Before running of to India tomorrow I am just going through my
recollections of 'promises'. Also this way I don't forget the stuff I
discussed, or if I do forget ppl will remember :p. 

=head1 PerlGameDev Monthly Aims and Releases 
=blame chromatic 
=for kthakore, FROGGS, garu, jtpalmer

chromatic has opened my eyes on having a monthly goal that we aim for.
In SDL perl5 we have had a progressive chaos. But I think having a
progressive chaos that aims to get something done each month (even a few
docs) might be a great idea cause we are all busy, and I would hate to
lose what we have a year. These will go up on this mailing-list and
maybe the wiki (we haven't used both as regularly as we should). Because
I consider all of PerlGameDev a single project, I will just be adding
them together in an announce end of each month. And you are reading
it :D. You might have notice I have actually gotten off my lazy ass and
did a good job with this announce. I will be using POD format but
subsequent need not be. I have also add 'blame and for' tags so people
can understand where ideas are coming from (=blame) and who should maybe
perhaps (please oh please) glance at it (=for). So this way ppl can
search for their tags/names and ignore the other stuff should they
want. 


=head1 Progressions for July

I am gone for most of July so I can't expect anyone to listen to me, and
start this so I have already done the first release for July :P. 

=head2 Announcing Perl6/SDL stuff [RELEASED!] 
=blame Util 
=for kthakore

RELEASE: http://modules.perl6.org/ (ctrl-f SDL) 

Util convinced me on the value of having a simple drawing module for
Perl6 a lot. So I have decided to add SDL6 'officially' to PerlGameDev.
Hopefully in a year or show we can have something interesting. Perl6 is
a lot easier to bind C libraries at this point, so that is refreshing. 

Additionally a discussion with chromatic reminded me that SDL 1.3 is
probably the best hope we have for Perl6/SDL (it is a lot cleaner ).

Any way I started up the a Perl6 module that does NCI via the
NativeCall.pm 

https://github.com/PerlGameDev/SDL6 (It uses SDL 1.2 for now) 

It has a test, and NativeCall is finding SDL that is installed. It is in
the panda ( the perl6 CPAN I guess ). dukeleto mentioned he took a
glance at parrotSDL. I am hoping to focus on SDL6 with SDL 1.3 once I
have an Alien::SDL ( getter and installer ) for it. This will prolly
take kick up storm in August I think. 

=head1 Continuing Projects 
=blame kthakore, chromatic
=for kthakore, chromatic, garu 

=head2 SDL_Manual Book Indexing and Chapter Intentions and Exercises 

I am hoping to read over Modern Perl source today, and do some of the
indexing I talked about. The chapter intentions should be done end of
July. That leaves the exercises which I can't really promise cause I am
bad at making those (garu would you be interested in this ?). 


=head1 Progressions for August 2011 


=head2 Distribution Network/Server/Client for Perl Games
=blame hercynium, Jesse 
=for kthakore, KMX, FROGGS, Alias 

I have had an idea of preparing an 'official' way for Perl Game
Developers to publish games, while allowing end game users to download
and running games. Discussions with hercynium and Jesse Vincent, have
opened my eyes towards technologies such as MetaCPAN, Shipwright/Carton,
and a wxWidgets front end. This idea needs some feedback so feel free to
hammer me. But code will start in Mid/End August. I am hoping to have
'test' this idea on Frozen Bubble, Zumbis, Zombie_Puzzle (a Box2d/SDL
game) and Construder. Which brings me to OpenGL.


=head2 OpenGL 3.0 
=blame kthakore, chromatic
=for kthakore, Chris, jtpalmer 

This comes from the following observations ( feel free to scold/correct
me ).

=over

=item Convergence to OpenGL

SDL 1.3 is moving over to OpenGL. Having the ability to do neat things
with OpenGL this will help to add more performance, speed and
flexibility to the module. 

=item POGL still uses FreeGLUT

POGL albeit great is getting ... old. FreeGLUT is slowing down ( SDL
replaces this fine and we have tests to prove it see construder. It is
an extra dep. 

=item OpenGL 3.3 is a fixed target

New OpenGL is all the way up to 4.x now. OpenGL 3.3 has been around for
a while and is not going to be using. 

=back

Based on this I think we should attempt to help the POGL dev with
whatever he needs. I will move it to github at some point. Additionally
chip during my talk you mentioned some 

Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread breno
Hi Kartik,

great that you got the time to spawn this list of goals, and I'm glad
you got the chance to brainstorm so much stuff during the YAPC! Makes
me even sadder I wasn't able to make it this year :(


 =head1 PerlGameDev Monthly Aims and Releases
 =blame chromatic
 =for kthakore, FROGGS, garu, jtpalmer

 chromatic has opened my eyes on having a monthly goal that we aim for.
 In SDL perl5 we have had a progressive chaos. But I think having a
 progressive chaos that aims to get something done each month (even a few
 docs) might be a great idea cause we are all busy, and I would hate to
 lose what we have a year. These will go up on this mailing-list and
 maybe the wiki (we haven't used both as regularly as we should). Because
 I consider all of PerlGameDev a single project, I will just be adding
 them together in an announce end of each month. And you are reading
 it :D. You might have notice I have actually gotten off my lazy ass and
 did a good job with this announce. I will be using POD format but
 subsequent need not be. I have also add 'blame and for' tags so people
 can understand where ideas are coming from (=blame) and who should maybe
 perhaps (please oh please) glance at it (=for). So this way ppl can
 search for their tags/names and ignore the other stuff should they
 want.


I like the idea, specially since it isn't focused on SDL and
Alien::SDL per-se, but on all related projects as well. Having public
announcements will definitely increase people's awareness to the
project!

As for the POD format, my email client doesn't know how to format it
(or maybe I'm just too lazy to set it up). We can all parse POD in our
heads but a simple list should be enough - even Markdown if you feel
like it :)


 =head1 Continuing Projects
 =blame kthakore, chromatic
 =for kthakore, chromatic, garu

 =head2 SDL_Manual Book Indexing and Chapter Intentions and Exercises

 I am hoping to read over Modern Perl source today, and do some of the
 indexing I talked about. The chapter intentions should be done end of
 July. That leaves the exercises which I can't really promise cause I am
 bad at making those (garu would you be interested in this ?).


Sure, why not. Let's talk this over in irc so I can get a better
notion of what you need and what the deadlines are.

Now, for my own goals, I'm gonna keep working on Box2D::Simple and the
Avenger layer, which hopefully will make it even easier for newcomers
to create nice games in Perl. Porting the games we made during the
Game Contest onto CPAN was also requested, and next on the list for
me.

Have a nice trip!

breno


Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread chromatic
On Friday, July 01, 2011 at 10:58 am, Chip Salzenberg wrote:

 On 7/1/2011 7:24 AM, Kartik Thakore wrote:

  chip during my talk you mentioned some technology for doing OpenGL
  context/display lists better. Can you mention it again chip? I seem to
  have forgotten it. 

 Hi!  I was talking about tcc, the
 http://en.wikipedia.org/wiki/Tiny_C_Compiler .   It's x86-specific but
 otherwise it seems like a convenient and really fast way to create
 structures defined by C.

Are you suggesting an approach like Python's Weave or Cinpy?

 http://scipy.org/Weave
http://www.cs.tut.fi/~ask/cinpy/

The approach I had in mind was to build an XS file full of Perl - C thunks 
and then use the closure-over-dlfunc-pointer trick of P5NCI to avoid writing 
(and paying the cost of) hundreds of otherwise-identical XS wrappers. This is 
even one spot where a little AUTOLOAD magic would help memory usage even more.

-- c


Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread Reverend Chip
On 7/1/2011 2:26 PM, chromatic wrote:
 On Friday, July 01, 2011 at 10:58 am, Chip Salzenberg wrote:

 On 7/1/2011 7:24 AM, Kartik Thakore wrote:
 chip during my talk you mentioned some technology for doing OpenGL
 context/display lists better. Can you mention it again chip? I seem to
 have forgotten it. 
 Hi!  I was talking about tcc, the
 http://en.wikipedia.org/wiki/Tiny_C_Compiler .   It's x86-specific but
 otherwise it seems like a convenient and really fast way to create
 structures defined by C.
 Are you suggesting an approach like Python's Weave or Cinpy?

http://scipy.org/Weave
   http://www.cs.tut.fi/~ask/cinpy/

Yes, quite.

 The approach I had in mind was to build an XS file full of Perl - C thunks 
 and then use the closure-over-dlfunc-pointer trick of P5NCI to avoid writing 
 (and paying the cost of) hundreds of otherwise-identical XS wrappers.

Ah, well, I had perhaps an incomplete understanding of the problem.  I
thought we needed to create complex data structures for some newer
OpenGL calls, so I wanted to ease the difficulty of making complex C
data structures from Perl.  If, OTOH, the primary problem is exposing a
very broad API from C to Perl, then yes, reusing XS wrappers is very
good (reduced memory use, better cache coherency, blah blah).


  This is 
 even one spot where a little AUTOLOAD magic would help memory usage even more.

 -- c


Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread Kartik Thakore
Oh this is some great stuff too! This will help me with another problem
I have (CUDA and OpenCL), Thanks.

On Fri, 2011-07-01 at 16:40 -0700, Reverend Chip wrote:
 On 7/1/2011 2:26 PM, chromatic wrote:
  On Friday, July 01, 2011 at 10:58 am, Chip Salzenberg wrote:
 
  On 7/1/2011 7:24 AM, Kartik Thakore wrote:
  chip during my talk you mentioned some technology for doing OpenGL
  context/display lists better. Can you mention it again chip? I seem to
  have forgotten it. 
  Hi!  I was talking about tcc, the
  http://en.wikipedia.org/wiki/Tiny_C_Compiler .   It's x86-specific but
  otherwise it seems like a convenient and really fast way to create
  structures defined by C.
  Are you suggesting an approach like Python's Weave or Cinpy?
 
   http://scipy.org/Weave
  http://www.cs.tut.fi/~ask/cinpy/
 
 Yes, quite.
 
  The approach I had in mind was to build an XS file full of Perl - C 
  thunks 
  and then use the closure-over-dlfunc-pointer trick of P5NCI to avoid 
  writing 
  (and paying the cost of) hundreds of otherwise-identical XS wrappers.
 
 Ah, well, I had perhaps an incomplete understanding of the problem.  I
 thought we needed to create complex data structures for some newer
 OpenGL calls, so I wanted to ease the difficulty of making complex C
 data structures from Perl.  If, OTOH, the primary problem is exposing a
 very broad API from C to Perl, then yes, reusing XS wrappers is very
 good (reduced memory use, better cache coherency, blah blah).
 
 
   This is 
  even one spot where a little AUTOLOAD magic would help memory usage even 
  more.
 
  -- c

-- 
Kartik Thakore thakore.kar...@gmail.com



Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread chromatic
On Friday, July 01, 2011 at 07:26 pm, Kartik Thakore wrote:

 What is the closure-over-dlfunc-pointer trick? Can I see an example of
 this someplace?

See load_func() and build_thunk() in:

http://cpansearch.perl.org/src/CHROMATIC/P5NCI-0.31/lib/P5NCI.pm

... and generate_function() in:

http://cpansearch.perl.org/src/CHROMATIC/P5NCI-0.31/build_lib/P5NCI/GenerateXS.pm

In short, P5NCI takes the name of a function in a shared library and its 
signature. It uses dlfunc to get that function's pointer *and* the pointer to 
an XS function which can handle that signature. Then it builds a closure which 
calls the XS function, passing the shared library's function pointer as well 
as @_. The XS function handles the conversion of the contents of @_, then 
calls the shared library function, converts any return value, and returns.

For an API like most of SDL or especially OpenGL, you pay a much, much smaller 
cost.

-- c


Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread chm

On 7/1/2011 10:24 AM, Kartik Thakore wrote:


=head2 OpenGL 3.0
=blame kthakore, chromatic
=for kthakore, Chris, jtpalmer

This comes from the following observations ( feel free to scold/correct
me ).

=over

=item Convergence to OpenGL

SDL 1.3 is moving over to OpenGL. Having the ability to do neat things
with OpenGL this will help to add more performance, speed and
flexibility to the module.

=item POGL still uses FreeGLUT

POGL albeit great is getting ... old. FreeGLUT is slowing down ( SDL
replaces this fine and we have tests to prove it see construder. It is
an extra dep.


FreeGLUT is the default window provider for POGL.
Any GUI toolkit that supports creating OpenGL contexts
and setting them should work fine.  I'm looking into
factoring out the GUI dependencies so that POGL works
better with other GUI toolkits to provide the OS and
window system support.


=item OpenGL 3.3 is a fixed target

New OpenGL is all the way up to 4.x now. OpenGL 3.3 has been around for
a while and is not going to be using.

=back

Based on this I think we should attempt to help the POGL dev with
whatever he needs. I will move it to github at some point. Additionally
chip during my talk you mentioned some technology for doing OpenGL
context/display lists better. Can you mention it again chip? I seem to
have forgotten it.


I'm not sure what the issues with context/display
lists might be but would be interested to hear.

As I see it, the top missing feature in Perl OpenGL
is support for OpenGL versions greater than 2.x.
Work is underway to refactor POGL to use GLEW for
the bindings.  That should improve portability and
capability (GLEW supports pretty much all current
OpenGL versions).

The next priority for POGL is the build process
which is hamstrung by a static probe for system
capabilities and requires a shell and make to
work.  I would like to move detection of needed
libraries to an Alien::Module and to Module::Build
for POGL itself which would avoid some of the
portability problems with win32---no shell, no
make, no package manager.  I would like to see
POGL build on win32 platforms *without* requiring
a MSYS or cygwin install to get things to work.

Regards,
Chris Marshall


The hope will be to make a declarative for OpenGL constructs that can be
sent straight to the hardware. Adam Kennedy has some work start in this
area (OpenGL::List).


Regards,




Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread Chip Salzenberg
On 7/1/2011 7:24 AM, Kartik Thakore wrote:
 chip during my talk you mentioned some technology for doing OpenGL
 context/display lists better. Can you mention it again chip? I seem to
 have forgotten it. 

 The hope will be to make a declarative for OpenGL constructs that can be
 sent straight to the hardware. Adam Kennedy has some work start in this
 area (OpenGL::List).  

Hi!  I was talking about tcc, the
http://en.wikipedia.org/wiki/Tiny_C_Compiler .   It's x86-specific but
otherwise it seems like a convenient and really fast way to create
structures defined by C.



Re: PerlGameDev Annonces, Aftermath YAPC::NA

2011-07-01 Thread Adam Kennedy
All mainstream win32 have snake now, they just don't have any other makes
On Jul 2, 2011 8:40 AM, chm devel.chm...@gmail.com wrote:
 On 7/1/2011 10:24 AM, Kartik Thakore wrote:

 =head2 OpenGL 3.0
 =blame kthakore, chromatic
 =for kthakore, Chris, jtpalmer

 This comes from the following observations ( feel free to scold/correct
 me ).

 =over

 =item Convergence to OpenGL

 SDL 1.3 is moving over to OpenGL. Having the ability to do neat things
 with OpenGL this will help to add more performance, speed and
 flexibility to the module.

 =item POGL still uses FreeGLUT

 POGL albeit great is getting ... old. FreeGLUT is slowing down ( SDL
 replaces this fine and we have tests to prove it see construder. It is
 an extra dep.

 FreeGLUT is the default window provider for POGL.
 Any GUI toolkit that supports creating OpenGL contexts
 and setting them should work fine. I'm looking into
 factoring out the GUI dependencies so that POGL works
 better with other GUI toolkits to provide the OS and
 window system support.

 =item OpenGL 3.3 is a fixed target

 New OpenGL is all the way up to 4.x now. OpenGL 3.3 has been around for
 a while and is not going to be using.

 =back

 Based on this I think we should attempt to help the POGL dev with
 whatever he needs. I will move it to github at some point. Additionally
 chip during my talk you mentioned some technology for doing OpenGL
 context/display lists better. Can you mention it again chip? I seem to
 have forgotten it.

 I'm not sure what the issues with context/display
 lists might be but would be interested to hear.

 As I see it, the top missing feature in Perl OpenGL
 is support for OpenGL versions greater than 2.x.
 Work is underway to refactor POGL to use GLEW for
 the bindings. That should improve portability and
 capability (GLEW supports pretty much all current
 OpenGL versions).

 The next priority for POGL is the build process
 which is hamstrung by a static probe for system
 capabilities and requires a shell and make to
 work. I would like to move detection of needed
 libraries to an Alien::Module and to Module::Build
 for POGL itself which would avoid some of the
 portability problems with win32---no shell, no
 make, no package manager. I would like to see
 POGL build on win32 platforms *without* requiring
 a MSYS or cygwin install to get things to work.

 Regards,
 Chris Marshall

 The hope will be to make a declarative for OpenGL constructs that can be
 sent straight to the hardware. Adam Kennedy has some work start in this
 area (OpenGL::List).


 Regards,