C/C++, Lua, and Framework all working together

[Josh]

Here, the program creates a skybox just by loading the environment_atmosphere model. Make sure you have the scripts folder copied to your project directory:

//	====================================================================
//	This file was generated by Leadwerks C++/LEO/BlitzMax Project Wizard
//	Written by Rimfrost Software
//	http://www.rimfrost.com 
//	====================================================================

#include "engine.h"

int main( int argn, char* argv[] )
{
Initialize() ;
RegisterAbstractPath("C:/Leadwerks Engine SDK");
SetAppTitle( "luatest" ) ;
Graphics( 800, 600 ) ;
AFilter() ;
TFilter() ;

TWorld	world;
TBuffer gbuffer;
TCamera camera;
TMesh	mesh;
TLight	light;
TMesh	ground;
TMaterial material;

world = CreateWorld() ;
if (!world) {
	MessageBoxA(0,"Error","Failed to create world.",0);
	return Terminate();
}

TFramework framework=CreateFramework();
TLayer layer = GetFrameworkLayer(0);
camera=GetLayerCamera(layer);
PositionEntity(camera,Vec3(0,0,-2));

//Set Lua variable
BP L=GetLuaState();
lua_pushobject(L,framework);
lua_setglobal(L,"fw");
lua_pop(L,1);

LoadModel("abstract::environment_atmosphere.gmf");

material=LoadMaterial("abstract::cobblestones.mat");

mesh=CreateCube();
PaintEntity(mesh,material);

ground=CreateCube();
ScaleEntity(ground,Vec3(10,1,10));
PositionEntity(ground,Vec3(0,-2,0));
PaintEntity(ground,material);

light=CreateDirectionalLight();
RotateEntity(light,Vec3(45,45,45));




// Game loop
while( !KeyHit() && !AppTerminate() )
{
	if( !AppSuspended() ) // We are not in focus!
	{
		// Rotate cube
		TurnEntity( mesh, Vec3( 0.5f*AppSpeed() ) ) ;

		// Update timing and world
		UpdateFramework();

		// Render
		RenderFramework();

		// Send to screen
		Flip(0) ;
	}
}

// Done
return Terminate() ;
}

[Pixel Perfect]

Very nice, this is really coming together now.

[TylerH]

This is wonderful, but there is a MAJOR issue.

 

I initialize the Jeklynn Heights scripting system currently using lua_open(). It returns a native type of lua_State*. I tried replacing lua_open() with:

 

State = reinterpret_cast<lua_State*>(GetLuaState());

 

but it causes a major load of run-time errors and exceptions.

 

Basically, your byte pointer to the Lua State used in Blitzmax will not transfer easily to C/C++, and will be incompatible with any direct usage of Lua, LuaBind, tolua++, etc. libraries that require a lua_State* pointer.

 

 

Maybe there is a way to get this working? Because, honestly, there is much more versatility in using Lua native in C/C++ along with third party libraries instead of the overhead of Lua in C -> BMX -> Re-exposed in engine.h/.cpp.

 

Anyways, this is working great otherwise.

 

Cheers,

Tyler

[Niosop]

What are our current options for communicating/passing data between C++ and Lua scripts?

[Josh]

It is questionable whether another instance of Lua opened in C can use the lua state created by the engine. The best bet is probably to use the Lua API declared in the engine DLL. Right now the exposed Lua commands are minimal, but I'll add more with time.

[TylerH]

We can not make use of LuaBind without a Lua State.

 

By using your Lua State (granted it was indeed usable from C/C++ properly), we wouldn't even be using another instance, we would be using the same instance of Lua, since it is already in memory from when you created yours. The state is just a pointer to the core memory utilized by Lua and some other variables it needed for garbage collection and such.

[Josh]

The lua state byte pointer GetLuaState() returns is the real lua state. The commands I have exposed through the DLL work on it, and they are just the raw lua API.

[Scott Richmond]

How come there is no LEO? Is LEO officially supported?I'm beginning to get confused as to how all these different modules fit in.

[Canardia]

There is LEO, and it's officially supported also.

 

When programming C++, you can choose whether you want to use the procedural C++ headers (engine.h), or the OOP C++ headers (leo.h). When you use LEO (the OOP C++ headers), you can still access the procedural C++ headers directly, since LEO includes also engine.h. Framework is available in both also, with LEO you just have an OOP style framework interface, but you can also mix procedural and OOP engine (and framework) commands if you like.

 

Lua is used in Editor to make logic and actions to models, you don't have to do anything in C++ for them, they just works automatically like in Editor.

[Scott Richmond]

mmm, I think I just get a bit confused on whats best practice. I think that's where I find LeadWerks lacking at the moment - There are all these different modules and most of the tutorials use a mix of them. Doesn't seem to be a set standard. I mean surely LEO is preferred, so why not make them the only headers? More simple and less maintainance.

[Canardia]

The procedural C++ headers are the mostly for easier conversion to other languages. It would be a huge task to convert LEO to all other languages (and many languages don't even have full OOP capability), so the procedural headers are kinda like the minimum you need to convert. There is no additional maintenance for LEO, since LEO uses the procedural headers, so you would need to write the new DLL imports anyway.

[Scott Richmond]

Thanks for taking the time to clear this stuff up Lumooja, but a couple more things:

If one uses LEO, does it still use the depreciated 'Framewerk' or the newer integrated 'Framework'?...or both?

[Canardia]

LEO uses only the integrated Framework. LEO never used the C++ Framewerk, since that is a standalone class.

[Flexman]

Here, the program creates a skybox just by loading the environment_atmosphere model. Make sure you have the scripts folder copied to your project directory:

LoadModel("abstract::environment_atmosphere.gmf");

 

I have a question about this.

 

In C++ or bmax, how do you access the properties of the "environment_atmosphere" object? If you wanted to change the fogcolor, or

skymaterial for example?

 

And sorry for re-spawning a fairly old thread but it seemed a relevant question and searching didn't yield any clues.

[ZioRed]

I suppose with GetEntityKey and SetEntityKey

[Guest Red Ocktober]

you guys are starting to confuse me here... i mean, why are you doing all of this work... it just seems as if you're overcomplicating something that really doesn't have to be...

 

or maybe i have it all messed up and wrong...

 

 

anyway... i learned, from Macklebee, that all i needed to do to take advantage of the lua scripts as they play out when loading a scene in the editor, is to (BMAX code, but should be the same or similar in c++)...

 

'To generatue glue functions for Lua, comment this line out:
Include "lua-gluefunctions.bmx"
'And uncomment these two lines, run the program once, Then undo your changes:
'generateGlueCode("lua-gluefunctions.bmx")
'End

 

 

then, farther down create a fw (framework) object...

 

'Create a New Framework Object.
Global fw:TFramework = TFramework.Create()
If Not fw RuntimeError "Failed To initialize engine."

SetScriptObject("fw", fw)	'Setup the Global script objects.

 

then, load the scene... and access the rendering properties like so...

 

'Load the scene. 
     Global scene:TEntity = LoadScene("Abstract::hydro.sbx")
     fw.renderer.ReflectionRenderComponents=ENTITY_RENDERABLE
     fw.renderer.SetWaterAmplitude(64)
     fw.Main.camera.SetZoom 1.2

 

 

so... to answer your question about changing the fog color of the atmosphere... the atmosphere in the editor is a logical grouping for certain properties of the renderer... forget the editor and lua for a second, and open the render.bmx (or corresponding c++) source file, and click on the code button in the upper right...

 

look at the list of functions... there you'll see the methods for the different accessible rendering properties... these are the same things you see in the editor, only in different places (as part of the atmosphere group, or other stuff) ...

 

now click on one and look at the corresponding source code to see how they're changed...

 

 

fog is represented as the renderer.fog property... you can either change it manually like so...

 

fw.renderer.distancefogenabled=True
fw.renderer.fogcolor=Vec4(1,.3,.3,1)
fw.renderer.fogrange.x=1
fw.renderer.fogrange.y=44

 

or, as you'll see by glancing at the functions listing on the right side of the source window there are methods available for setting the fogdistance, color etc... thus making changing it a lil less verbose...

 

fw.renderer.distancefogenabled=True
fw.renderer.setDistancefogcolor(Vec4(1,.3,.3,1))
fw.renderer.setDistanceFogRange(.1,44)

 

to sum it all up... when coding in bmax, i only use the lua scripted base classes to load up a scene as it is in the editor... then i use fw.renderer properties to change the properties i wanna modify in code...

 

this works out great as it eliminates the need for the ole processScene function, and allows scenes to be loaded with lil or no hassle...

 

it also makes the rendering properties easily accessible...

 

my thanks to Mack and Marley for their guidance on this stuff... this lua thing had me going for a spin as well...

 

 

now i know there are those who want to use lua more tan c++ or bmax... i'm just getting into that aspect of coding the engine myself... i'm impressed with how fasst the lua compiler spits out the luac ready 'compiled' code... but for some reason i can't get some scenes that i can load with bmax and c++ to load with straight lua script...

 

 

 

--Mike

[Flexman]

Well to explain a little I'm building an environmental system to control dynamic weather. And I wanted to keep it simple by taking the lua Atmosphere entity and over time pushing different parameters to it. Accessing it through the framework was causing exception errors as the skybox was not available (=null). This turns out not to be so strange, as I'd removed it in the editor

 

You're code snippets I'm familiar with, I used them to learn and setup scripting at the start of the year for which I am grateful.

 

Sorry if I come across as being a numbnuts at times. User at fault :/