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?

The "features" list of LE2 says it can do 67 square kilometers of continuous terrain. That's a grid that comes out to be slightly larger than about 8 kilometers by 8 kilometers (8 * 8 = 64), right?

Thanks for the info, Josh.

Is there a link to the planned feature set for LE3? Specifically, I'm interested to see if 64-bit support is anticipated. Also, I'd like to see if any kind of terrain paging will be possible. Thanks!

Thanks. Makes perfect sense.

Thank you for reminding me, Mumbles. That raises another question I could not seem to find the answer to: Does my purchase of a copy Leadwerks today provide me only with licensing for that copy (version)? In other words, when it's "successor" arrives, will I need to purchase a new license to use that version? Be aware that I'm not asking for free lifetime updates (at $200, I think requiring licensing renewals for ordinal updates to be an acceptable business model). I'm just wanting to understand my obligations regarding future releases of the engine.

Ok. Your inability to understand precisely what I mean (even though I think I was quite precise about it) worries me. I will try another, more concrete example... Let's say I want to write an MMO using Leadwerks. In this MMO, the player has the ability to write various "macros" to aid in their game play. For example, the player can write a macro (the specific language of which is irrelevant; it may be Python, it may be Lua, it may be something proprietary that only exists within the game itself) that lets them automate an attack sequence, or lets them automate some crafting action, or simply lets them automate a greeting with another player. Is this application of "scripting" within a game based on the Leadwerks engine prohibited by the EULA? It's not entirely clear from the wording of the EULA, but the interpretation of others within this thread suggest that it is not.

Hi, Josh. It was basically as I described to Mumbles. It was unclear to me from the description if providing "macro" capabilities within my game violated the EULA the way it was worded. However, I think the replies within this post have made the spirit of the license clearer: I cannot use the game engine to create a game engine. From that standpoint, adding a scripting system to a game for the sake of the game itself would not violate the licensing. Is that substantially correct?

Absolutely understand. If you can't afford $200 for unlimited commercial game production, then you clearly aren't serious in the first place. Yes, this is the very thing that concerned me. I think a game should have 'macro' capabilities, but the licensing seemed rather gray area about that. It probably just isn't worded well enough to distinguish these elements. Thanks for the reply, Mumbles.

Hi, everybody. I'm currently researching game engines (open source and commercial) for a personal project I'm contemplating. A friend of mine recommended I give Leadwerks a look as well, and I have a couple of questions about its licensing. I'd like to know if the $199.99 single-user license purchase covers any commercial use of the engine (allowed by the EULA, of course), or are there additional fees/royalties should I decide to sell my game? This portion of the EULA has me a bit confused/worried: "...You may not create a 3D game or other application that is modifiable by script, programming, GUI interface or other means, unless the system requires the end user to also own a valid license for the SOFTWARE PRODUCT." Would this be interpreted as prohibiting me from providing scripting features to my game's users as part of the game's mechanics? Thanks for your feedback!