Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Kyan

Member Since 11 Oct 2011
Offline Last Active Apr 25 2013 09:56 PM

Topics I've Started

Luabind inside a Shared Library

30 April 2012 - 09:37 AM

So, I've got Luabind et. al. setup properly and I'm trying to use it to fuel a binary extension module for Lua (i.e. a module for Lua written in C/C++). Unfortunately, it's been a long time since I've done anything C++ related and, frankly, I'm failing miserably. I've managed to get the following basic example running:

// helloworld.cpp
#include <iostream>
#include <luabind>

void greet()
{
	std::cout << "hello world!\n";
}

// int luaopen_[libname] is the entry point
extern "C" int luaopen_libhelloworld(luaState* L)
{
	using namespace luabind;

	open(L);

	module(L)
	[
		def("greet", &greet),
	];

	return 0;
}
The above, when compiled into a .so, works as expected.

require 'libhelloworld'
greet()
-- prints "hello world!"
Unfortunately, chaos sets in when I attempt to bind a simple class, e.g.:
class Test
{
	public:
		Test();
	
		void say() { std::cout << "Inside a class!" << std::endl; }
};

...
		def("greet", &greet),
  
		class_<Test>("TestClass")
	   	 .def(constructor<>())
	   	 .def("say", &Test::say)
...
at which point the undefined symbols start flying as I try to load the library in Lua. Specifically:
  • ./libhelloworld.so: undefined symbol: _ZN4TestC1Ev
The literature on Lua binary modules appears to be archaic and almost every example I've come across is either in pure C or C-like C++ (e.g. the working example above). I realize the error is most likely caused by name mangling but I'm not sure how to resolve it. I investigated exporting symbols with GCC by using __attribute__((__visibility__("default"))), but that doesn't appear to have any effect. Some sparse documentation recommended appending -WI -E to the GCC arg list and that doesn't appear to have done much either (-E is just a preprocessor pass?).

The only other valid example I can find is the Ogre bindings to Lua (using Luabind) which doesn't use an entry point at all as far as I can tell. Unfortunately, I'm not entirely clear how they got away with that since anytime I try Lua - surprise - whines about not having a valid entry point.

I realize this should probably be elsewhere (like on the mailing list) but I was kind of hoping my problem was either obvious or a Luabind guru was somewhere nearby. Any help would be greatly appreciated.

EDIT: SOLVED. I forgot to define the constructor. *hangs head in shame* My apologies folks, this is precisely why sleep is important.

Recommended Method for Rendering a GUI with VBOs

09 December 2011 - 02:02 PM

I'm looking for advice on implementing the [rendering portion] of my GUI using VBOs. I realize this is probably quite easy, technically speaking, but I've never used VBOs for obscenely trivial geometric tasks and I'm wary of doing so incorrectly. I'm aware of most of the simpler "tricks" for GUI rendering (e.g. restrained updating, render to texture, render only the updated widgets, etc.) it's how to use the VBO(s) as replacements for immediate mode rendering that is throwing me. I can't shake the idea that it is complete overkill.

Google searching turned up several options/solutions:
  • Use a monolithic VBO for the entire GUI, based on the reasoning that multitudes of ant-sized VBOs are not performant (followed by a large flamefest over the validity of that statement).
  • Use an army of small VBOs, where each VBO corresponds to a widget, based on the reasoning that dealing with a giant VBO isn't worth it.
  • Use a single VBO per geometry type (e.g. a quad) and transform it via (presumably) a shader.
  • Use QT (not an option, but it was suggested quite frequently).
  • Ignore the problem altogether by relying on OpenGL's compat-mode until absolutely forced to do otherwise. After plowing through a number of straight-OpenGL GUI libraries this appears to be the most popular, albeit unspoken, solution. I'd really prefer to forgo this as I'd like to avoid as much deprecated functionality as possible, but I'm open to an argument to the contrary.
Is there a general guideline for which is preferred or, in lieu of that, is there an alternate preferred method for using VBOs in GUIs?

I'm not using C/C++ currently but advice, examples, or "look at" libraries in any language are fine. Any help is greatly appreciated.

PARTNERS