[GEM-dev] Lua again: now with luaglut/luagl

marius schebella marius.schebella at gmail.com
Wed Nov 28 03:05:37 CET 2007


hey frank,
I stopped all of my work after reading your email, because I got really 
excited, and wanted to try that too.
I got lua 5.1.1 from http://www.algonet.se/~afb/lua/ and put it into 
/sw/lib/lua/5.1 (on my os x 10.5.1).
when I open your patch, first, luagl gets created and I get some drawing 
(even with no gemhead turned on, which strange), but I only see 2 or so 
lines at a time and a constant error stream:
lua: error in dispatcher:
[string "pd.lua"]:133: attempt to call field '_error' (a nil value)
lua: warning! pointers untested
lua: warning! pointers untested
you think I need lua 5.1.2? I also ran into building issues before...
I don't know which pdlua version I am using. maybe I have to reinstall 
that also.
marius.


Frank Barknecht wrote:
> Hi,
> 
> as I still haven't managed to build LuaGL, I now tested luaglut (0.5)
> with Gem, downloaded from here:
> http://lua-users.org/files/wiki_insecure/users/VarolKaptan/
> 
> This wins over LuaGL in the makeability contest with a README and a
> working Makefile, but lacks a bit in documentation. Anyway I still
> managed to "port" IOhannes' example posted some time ago from LuaGL to
> luaglut easily, and even extend it. 
> 
> It's attached and the Pd example also compares rendering many lines
> with luagl over rendering them with Gem and double gemheads. Lua wins
> by an amazing margin on my machine: Lua is twice as fast as Pd when
> rendering 1000 lines here. I guess I'll be using luaglut in Pd quite a
> bit from now on, that's too much of a speedup to ignore for the tiny
> effort required. ;) 
> 
> But one thing, which maybe only Claude can answer, makes me wonder,
> probably because I don't yet understand how the combination Lua/Gem/Pd
> works in general.
> 
> In the Lua file (attached), I have a  method "render()" to do the
> rendering. This method is called whenever the object receives a
> "gem_state" in its 1st inlet. This looks a bit like black magic to me:
> How gets the stuff that M:render() renders with GL-commands finally
> get attached to the gem-state and transferred into the Gem-window? 
> 
>     function M:in_1(sel, atoms)
>         if sel == "gem_state" then
>            M:render(self)
>         end
>     end
>     
>     function M:render(myself)
>         -- Why can't I use "self" directly here??????
>         -- "self" seems to be a different table inside M:render(). Why?
>         -- myself is not equal to self here
>         max = math.max(myself.max, 1)
>         glBegin(GL_LINES)
>         for i=1,max do
>             glColor3d(math.random(), math.random(), 0)
>             glVertex2d(0, 0)
>             glVertex2d(math.random(-400,400)/100, math.random(-400,400)/100)
>         end
>         glEnd()
>     end
> 
> And the second black magic bullet that hit me: Normally all methods of
> a Pd class written in Lua get the same "self" passed. But M:render()
> seems to be different here: If I try to access the self.max value
> directly inside M:render(), it is "nil". Printing "self" in various
> places also gives different table-pointers, so the "self" in
> M:render() and the "self" in the other methods are different tables. I
> worked around this by passing the Pd class "self" as "myself", but for
> one this is awkward, and more importantly: I just don't get what makes
> M:render() special? 
> 
> Anyone with good explanations?
> 
> Ciao
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev





More information about the GEM-dev mailing list