Look Something Shiney ( LuaJIT 2.0.0-beta1 )

[SinbadEV]

http://lua-users.org/lists/lua-l/2009-10/msg01098.html

I don't know anything about our current implementation etc. but this is supposed to be significant faster then previous implementations.

[Master-Athmos]

Any chance of combining that with LuaGL?

Would be cool to give the Lua wizards all the functionalities OpenGL gives so we actually might see things like a new model format with all the fancy stuff like bone animations (while it doesn't seem to be needed as afaik zpock managed to handle stuff just with what Spring's Lua access offers)...

[zwzsg]

What is the difference between LuaGL and http://springrts.com/wiki/Lua_OpenGL_Api, Master-Athmos?

Because to me it looks like you're an idiot requesting something that's already in.

[FLOZi]

What is the difference between LuaGL and http://springrts.com/wiki/Lua_OpenGL_Api, Master-Athmos?

Because to me it looks like you're an idiot requesting something that's already in.

Presumably, the latter is merely a subset of the former.

[Master-Athmos]

As FLOZi said - LuaGL offers access to all of OpenGL's commands. What you have on Spring's Wiki page is only a tiny bit of those...

My point of view is that this would make things like shaders, model rendering and their animation more easy to do. As I see it things like that won't be hardcoded into Spring anytime soon while a realization via Lua (despite not really being the better way) is not only more probable but even (partially) was accomplished...

I for example think of Argh's shaders and particle system or zpock's MD5 models and animations (while I cannot remember the amount of Lua used for that)...

That's why I came up with the question if the integration of LuaGL is "unthinkable" or not...

[Kloot]

My point of view is that this would make things like shaders, model rendering and their animation more easy to do.

And you base this on...? Shaders and model rendering are already "easy", and especially wrt. the MD5 animation topic that keeps being brought up again and again, the difficulty is *not* in the rendering part. Moreover, if the existing API does not offer a command for which a need is demonstrable then it can be added with far less work than integrating LuaGL would be.