[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