Laurens

It should. It just calls the LoadScene method from engine.dll using interop. Unless Ubu did something funky in his framework. I do not have a decompiled version of the latest release at hand here.

Yes, which is why this would not make a very useful engine command

I have used Ogre3D before I moved to Leadwerks. You should consider the fact that Ogre is a rendering engine and not a game engine. It has no physics, no sound, and no networking. It has GUI support through CEGUI (eeew) and input through OIS (OIS is OK). Additionally, Ogre is a lot, a LOT harder to get into.

I understand that, but on Windows it would be a no go. In order for the DLL to be in another location, the programmer has to either create a BAT file to add the path to the game's environment before executing the EXE, add it to the system path, or put the DLL in the system32 directory and as the OP has already told that none of those options are any good for him. So what the OP is asking - an engine command to specify the location of the engine DLL - impossible on Windows. Even if it were possible it would be futile. If the engine command would execute it would mean the game executable already found it, so whats the point of telling the engine where it is?

Considering the fact you said your are targeting mostly low-end machines you might need to reconsider. Leadwerks is extremely easy to program and puts out incredibly beautiful graphics but it comes at a price. http://www.leadwerks.com/wiki/index.php?title=System_Requirements Unity has a watermark though, which only 1500 dollars will remove (Unity Pro). I don't know about you but watermarks make me puke blood.

Back in the "early days" of 2.3 this was a bug caused by shaders.pak on ATI cards. Using the shaders.pak from 2.28 solved it but the 2.3 shaders.pak have been working perfectly fine for me for quite some time now.

I may be way off here but calling any sort of engine command from C/C++, C# or LUA requires the DLL to be present in the same directory as the EXE. Thus you could never implement this as an engine command the way I see it.

Hi, You need to convert your models to the GMF file format and your textures to the DDS file format. Additionally you need to create a material file using the DDS files using the material editor. Then you should be able to drop the files in a sub directory of the Editor and be good to go. Cheers!

I have bought the Pro versions so I should not be limited. Thanks a bunch though I'll consider getting UU3D as well.

Hi guys, I have recently created some placeholder art for my game but have a hard time getting the textures showing. I exported the model from Silo to OBJ and used obj2gmf to convert it to GMF. When I open the model with the ModelViewer it says "<none>" when I expand the "Surfaces" tree though. The .MTL file is empty. Since I read this is the material definition file for an OBJ, I suspect this has something to do with it. I remember several people using Silo here as well. Has any of you encountered this issue before? Thanks! EDIT: Included the model. Don't mock my programmer art banana.zip

If you need detailed instructions: http://leadwerks.com/werkspace/index.php?/topic/602-c-headers-main-thread/page__view__findpost__p__7193

Replacing the LEO function with the normal C function does not change it. I even replaced all LEO structures with the standard C structures and yet the problem persists EDIT: Replacing framework.Update() with UpdateWorld() fixes the issue. I suppose this does lead to other problems since I am using Framework to render. Putting it on the tracker.

If I comment out the ball.SetCallback((byte*)Paddle::EntityCollisionCallback, ENTITYCALLBACK_COLLISION); part, than everything runs perfectly fine. The paddle nor the ball gets destroyed at any point. If I set a breakpoint in the callback function, all variables also get properly set. No bad pointers whatsoever.

Well my code compiles now. A new issue has risen though. My code now looks like this: ball.cpp ball.SetCallback((byte*)Paddle::EntityCollisionCallback, ENTITYCALLBACK_COLLISION); paddle.cpp void _stdcall Paddle::EntityCollisionCallback(TEntity source, TEntity destination, byte* position, byte* normal, byte* force, float speed) { int type = GetEntityType(source); } The method is declared static in the header of the Paddle class. When I run it, it detects a collision, calls the callback method between 8 to 16 times (approximately) (10 runs) without updating or rendering in between, and then craps out on framework.Update(), giving me an AccessViolationException. Any idea what's going on here?

No, it's an instance. I had hoped I could pull that off using LEO but since you're asking I guess I should implement the callback "plain old" C-style?

Hi, Could someone please give me an example of how to create a callback using LEO? I currently have the following (non-functional) code: ball.cpp ball.SetCallback((byte*)paddle->EntityCollisionCallback, ENTITYCALLBACK_COLLISION); paddle.h void EntityCollisionCallback(TEntity source, TEntity destination, byte* position, byte* normal, byte* force, float speed); Thanks!

As far as I can see C# and C++/Framewerk/LEO are correct. On a different note: what program did you use to create those diagrams with? I have been looking a for a tools that does UML, preferably free or less than 50 euro's and not Visio. Thanks!

This may perhaps not be the case since you're using a custom exporter but I had to find out the hard way that physics do not affect auto-generated PHY files. You might want to try generating them yourself using phygen.

You can add the target platform without hacking the project file. You'll just need to flip some switches which are disabled by default in all Express editions. Go to: - Tools - Options - Projects and Solutions - Check "Show advanced build configurations" Now right-click on your solution and go to the "Configuration manager". Under "Target platform" chose "<New>" and add the x86 platform. Then you should be good to go.

Thanks for the message Josh. My server blocked your message though Appearantly I had it configured to disallow exe's even when the file was in fact clean. Anyway, Davaris sent me a link so I do have it now. There was no license file in the zip so I can't say whether we're allowed to distribute it.

Hi, I tried to download Font Studio today but the website mentioned on the wiki (http://www.nitrogen.za.org/projectinfo.asp?id=12) is down. If someone has the installer available, it would be great if it could be uploaded to the board. Thanks!

You need to set your target platform to x86 and all will be OK. The DLL does not need to be recompiled. Cheers!

Ah I didn't consider people customizing Framewerk. An attempt to clear up the confusion: Framework - In C# and C++ this is plain old Framewerk compiled into the DLL. No need to include files other than "engine.cpp", or, in the case of C#, "Leadwerks.DLL". BlitzMax does not have this. Not customizable. Framewerk - Plain old Framewerk, separated from "engine.dll". In order to use Framewerk you will need to include the appropriate files in your project ("Framewerk.cpp", "Layer.cpp", "Renderer.cpp", and some other file I possibly forgot). Customizable. Also, again, I do not dare make any assumptions about LUA. Hope that cleared it up a bit

Framewerk is no longer a separate component, it has been integrated with the DLL. If you would include "engine.cpp" in a project you would automatically be able to use Framework. Only BlitzMax has a separate module for Framewerk I believe. Not sure though since I don't use BlitzMax. I also can't judge about the LUA part. Additionally, C# does not use "engine.h" but "Leadwerks.dll" which is a .NET assembly by Ubu (Lazlo on the previous forum). Also note the namechange, it's "Framework" now instead of "Framewerk", except for BlitzMax because appearantly, modules can't be named "Framework". Otherwise looking fine Cheers!

Thats why I worked for me so well then, had skyboxes turned off because of the ATI driver bug and no transparency in my scene Good to find out now. Cheers!