Uberman

Wow. Crickets. Ok, I guess it's an "advanced" question that few people have contemplated.

I'm not anywhere near this point yet with my little test game, but I'm thinking ahead a bit to the point where I'm going to need to do 2D overlays (e.g., a GUI for the game). I was wondering if anybody had attempted to embed -- or having attempted, had any success embedding -- the LE engine in a "foreign" framework? I'm thinking of something like Qt, that would provide a wrapping application framework where the LE engine's rendered output could be somehow displayed in a context (perhaps by blitting the framebuffer), and then use the framework's input handling, and 2D drawing capabilities to overlay GUI-based elements onto the context. Mouse and keyboard events would be managed, and those that were targeted for the LE engine (i.e., all events taking place directly on the non-GUI elements) would "fall through" to the game code. Anybody taken this road?

I suspected as much, but just wanted a second opinion on the topic. Thanks.

Ah, I see that I could probably use a Pivot instead of having to resort to matrix manipulation. However, it still begs the question whether using the physics engine might be the more (or less) elegant approach.

Some years ago (for the original Sony PSP, to show you how long ago) I wrote some raw 3D code using that platform's SDK. The code allowed the user to "walk" a cube around a grid. The cube could be "walked" by using the arrow keys; pressing left caused the cube to roll over to the left, up caused it to roll away from the user, etc. I never did anything with this code, I just wrote it basically to see if I could, and it involved a lot of management and shifting of the object's pivot point to create the illusion. I'm thinking of doing something similar in the test program I writing with Leadwerks. I cannot see any abstracted management of an Entity's pivot point in the Leadwerks SDK, so I am assuming I'll have to do some direct matrix programming to achieve the same effect. However, Leadwerks provides something new that I've not had access to before: a physics engine. I'm not sure what approach, then, would be better in programming the effect, that of using the physics engine to cause the object to "fall over" as though it were walking, or if I should just animate the motion by hand as I did on the PSP. I would imagine I'd have greater control over the movement of the object by doing manual animation, but I'd have less complicated code if I somehow employed the physics engine to move the object. In the physics approach, I imagine I'd have some kind of hidden collision object that would "knock over" the Entity, like an invisible finger pushing over a brick, while the user holds down a key. I don't know if that would be the most elegant approach, though, and perhaps some combination of manual animation and physics might be better (e.g., manually animate until the object crosses a gravitation threshold and the let the physics engine take over). Would anybody have any opinions or insights about what might be the best approach in this situation?

Created a symlink to it in the project folder, and the skybox now loads. Thanks, Aggror.

I have the following code: [...] // Set graphics mode LEO::Engine engine(AppTitle,ScreenWidth,ScreenHeight); if( !engine.IsValid() ) { ErrOut( "Failed to set graphics mode."); return 1; } engine.AddAbstractPath( MediaDir ); // Create framework object and set it to a global object so other scripts can access it LEO::Framework fw; if(fw == NULL) { ErrOut("Failed to initialize engine."); return 1; } // Set Lua framework object engine.SetObject( "fw", fw ); // Set Lua framework variable LEO::Lua lua; lua.PushObject( fw ); lua.SetGlobal( "fw" ); lua.Pop( 1 ); LEO::Model skybox("abstract::environment_atmosphere.gmf"); [...] Leadwerks is installed to "D:\Leadwerks\SDK", which is what the "MediaDir" value contains. I'm trying to add a skybox to the test, and when it hits the line that loads the one provided with the SDK, I get an error message that says "can't open scripts/class". The console has the following text regarding this problem: So...what am I doing wrong now?

Your function prototype worked, tj. I don't get the runtime error now (because the correct number of arguments are being processed). Thank you for the concrete example. It let me see that there are definitely some disconnects in the SDK (and the documentation) for which I'll have to be prepared.

Huh?! Your collision callback signature is even different from the prototype in the headers! Yours: int _stdcall CoinCollision( TEntity entity0, TEntity entity1, byte* position, byte* normal, byte* force, flt speed ) LEO/leobase.h Header: typedef void (*CollisionCallback)(TEntity ent0, TEntity ent1, const TVec3& pos, const TVec3& normal, flt speed); The LEO version in leobase.h is 2.5.0, but the C headers are 2.5.1. I'm beginning to get the feeling that the LEO headers are out of date with the current version of the library. The LEO header prototype does not define the "force" parameter found in your callback, but then the C headers don't even define a typedef for the callback prototype at all, so I can't compare.

I appreciate the aid. This is really stumping me. Oh, and I verified: My VS2010 is SP1. I wasn't sure.

I have added both __stdcall and __cdecl to the callback function, and no joy. I've also tried the straight C++ code (non-LEO) from the aforementioned tutorial in a fresh VS2008-based project generated by LEBuilder, added the callback function: void __stdcall cubeCollision(TEntity e1, TEntity e2, const TVec3& pos, const TVec3& normal, flt speed) {} or: void __cdecl cubeCollision(TEntity e1, TEntity e2, const TVec3& pos, const TVec3& normal, flt speed) {} set the callback: SetEntityCallback(body, (BP)cubeCollision, ENTITYCALLBACK_COLLISION); And I still get the same runtime error with VS2008 and VS2010. I'm beginning to wonder if there's some compiler setting (like structure alignment) that the LEBuilder program is not adding when it generates the Visual Studio projects.

I found this in leobase.h: typedef void (*CollisionCallback)(TEntity ent0, TEntity ent1, const TVec3& pos, const TVec3& normal, flt speed); But setting the callback to this signature still generates the runtime issue with VS2008 and VS2010.

Thanks for the reply, Metatron. Can you point me to where that is documented? The Collision Callback Example doesn't indicate that additional parameters are required.

I have the following simple (LEO-based) LE 2.5 program that compiles and functions properly under both VS2008 and VS2010: // ==================================================================== // This file was generated by LEBuilder // http://leadwerks.com/werkspace // ==================================================================== #include "leo.h" #include <string> #include <iostream> using namespace std; using namespace LEO; const int ScreenWidth = 800; const int ScreenHeight = 600; const char* MediaDir = "D:\\Leadwerks\\SDK"; const char* AppTitle = "TestLEO"; void ErrOut( const string& message ) { cerr << message << endl; } // -------------------------------------------- int main( int argc, char* argv[] ) { // Set graphics mode Engine engine(AppTitle,ScreenWidth,ScreenHeight); if( !engine.IsValid() ) { ErrOut( "Failed to set graphics mode."); return 1; } engine.AddAbstractPath( MediaDir ); // Create framework object and set it to a global object so other scripts can access it Framework fw; if( NULL == fw ) { ErrOut( "Failed to initialize engine." ); return 1; } // Set Lua framework object engine.SetObject( "fw", fw ); // Set Lua framework variable Lua lua; lua.PushObject( fw ); lua.SetGlobal( "fw" ); lua.Pop( 1 ); // Get framework main camera fw.main.GetCamera().SetPosition( Vec3(0,0,-5) ); Material material( "abstract::cobblestones.mat" ); Debug::SetDebugPhysics(); // Create collision cube BodyBox cube1_body(1); cube1_body.SetMass(1.0); cube1_body.SetFriction(1.0, 1.0); cube1_body.SetElasticity(0.2f); Cube cube1; cube1.Paint( material ); cube1.SetParent(cube1_body); cube1_body.SetPosition(Vec3(0, 5, 0)); BodyBox cube2_body(1); cube2_body.SetMass(1.0); cube2_body.SetFriction(1.0, 1.0); cube2_body.SetElasticity(0.2f); Cube cube2; cube2.Paint( material ); cube2.SetParent(cube2_body); cube2_body.SetPosition(Vec3(0.5, 10, 0.5)); // Create collision ground BodyBox ground_body(1); Cube ground; ground.Paint( material ); ground.SetParent(ground_body); ground_body.SetScale(Vec3(10.0f, 0.1f, 10.0f)); ground_body.SetPosition(Vec3(0, -1, 0)); // Turn on physics //TVec3 gravity = Vec3(0,-9.80665f*2,0); TVec3 gravity = Vec3(0,-2.0,0); World& back_world = fw.background.GetWorld(); back_world.SetCollisions(1, 1); back_world.SetGravity(gravity); World& main_world = fw.main.GetWorld(); main_world.SetCollisions(1, 1); main_world.SetGravity(gravity); World& trans_world = fw.transparency.GetWorld(); trans_world.SetCollisions(1, 1); trans_world.SetGravity(gravity); cube1_body.SetType(1); cube2_body.SetType(1); ground_body.SetType(1); // Add some light DirectionalLight light; light.SetRotation( Vec3(45) ); // Spin cube until user hits Escape while( !Keyboard::I****() && !engine.IsTerminated() ) { if( !engine.IsSuspended() ) { fw.Update(); fw.Render(); engine.Flip( 0 ); } } return engine.Free(); } This works as I expect, with both cubes falling and colliding properly. I now would like to detect a collision for each Cube body (to emit a sound, for example). I add the following module-level function to the code: int cubeCollision(TEntity e1, TEntity e2) { return 0; } And then I enable collision callbacks for each Cube toward the bottom of the main() body: cube1_body.SetType(1); cube1_body.SetCallback((BP)cubeCollision, ENTITYCALLBACK_COLLISION); cube2_body.SetType(1); cube2_body.SetCallback((BP)cubeCollision, ENTITYCALLBACK_COLLISION); ground_body.SetType(1); When the first impact occurs, and the callback is triggered, I'm getting a run-time error (the same in both VS2008 and VS2010) that states: Any ideas about what I might be doing wrong here?

Um, sorry? Not sure I'm understanding what you are trying to say here. There's quite a difference between 8^2 and 8,192^2. 8 km * 8 km = 64 sq km 8192 km * 8192 km = 67,108,864 sq km So, are you saying that the engine can do 67,108,864 square kilometers of continuous terrain?