Canardia

Just do it like in the driver.lua example, but replace LoadMesh() for the wheels with LoadModel() in vehicle_viperscout.lua, and add physics bodies to your wheel models. Nothing else needed.

You don't need necessarily any LE functions on the server, but you can have a seperate Game Master client using LE which connects to the server and handles all other clients. Alternatively you can also integrate the server logic in the clients, then you don't need a seperate GM client. This would be actually more useful, since then the game works also in offline mode.

You can use wheels with a physics model and still do it like in the driver.lua example. The wheels will collide with things just fine, but of course they won't get any force impact back since you use SetEntityMatrix() on them which eliminates reverse physics force. But collisions still work fine.

The FPS display in the screenshot says that you are using Framework also. So you are rendering the scene twice, and your own rendering fails because Framework has already rendered it.

LE has the same commands as MiniB3D, so you don't really need MiniB3D when you use LE.

When you use SDL_net for networking, you can write a simple server program for Linux without using LE on the server.

You can use DrawLine() and SetBlend(BLEND_ALPHA).

Instead of hardcoding the player position in your code, you should find a player entity from the map and position your player there. Basically FindChild(scene,"playerstart"); is enough.

I do usuallly SetWorldSize(Vec3(50000)); hasn't shown any negative aspects yet. For camera range I set usually Vec2(0.001,5000), it's not too far, not too near and handles the retarted 32-bit float range nicely. Additionally I need to set the camerarange for lights also (wtf? but this is how the engine "works"), if you want to have lights inside a light cage which "project" the cage outside.

Every **** which is installed into a browser is full of viruses and adware, you should only trust real exe files (since then your anti-virus program can also check them). Besides, why would you run a game in a browser? What has a game to do with a browser? It's about the same as if you would want to run a game in Microsoft Word, or Excel, or any other app. A browser is just an app. I rather run the game from DOS without screwing up any other apps.

I don't know how 3DSMax does the hair, is it a shader or a physics mesh? Does it work with 200 characters at the same time with decent FPS? I've done hair in games so far with a simple mesh, which can be also animated with a shader (like the trees). The hair needs to be moved to the transparency world so that it alphablends correctly and smoothly.

CEGUI has really nothing to do with a GUI. It's mostly a renderer as it loads also fonts and renders them, that's something a GUI should NOT do, but a GUI should only tell an existing renderer to draw something with OpenGL commands. It's pretty easy to make a GUI like in Crysis from scratch with LE. You want to keep things simple for the user, so the easier the GUI is, the better. I've used my own GUI in 2 games so far, so I think it's soon ready to be universal enough to go open source.

Your link doesn't work, it wants to install some virus/java application which my computer told me not to install under any circumstances. Do you have a working screenshot as .png, youtube video, or some easy to run .rar/.exe file instead of those horrible web plugins which are full of adware and viruses?

As long you keep saying developing in C++ is slower than in BlitzMax, then you are not sufficiently skilled in C++ yet, or you haven't written enough own standard functions which BlitzMax has (BlitzMax would be a horror without all the standard functions also). The main reason why I got pissed with BlitzMax was that it took over 5 minutes to start a real game in debug mode. So I figured BlitzMax is nice for small projects, but when things get real, it's not made for the power which is needed. Besides, I always liked the C++ syntax, even when I was professionally programming in Pascal at work. I always looked at C++ and thought that someday I will convert all my Pascal code to C++.

I've only ever had success with .fbx (and .png for textures) format across different engines and different artists I worked with. Any 3DSMax and Maya artist can export to .fbx.

@Azazel226: There's an easy solution: buy a LE license for all members of the game project. It's the only right choice to do anyway, and Josh gives often decent discounts when you explain the situation to him. If your game makes any profit, you will get easily your money back, plus maybe even more since you can finish your project faster and easier. Each day of game sales means money, so the faster your game is on the steamshelves, the more money you will get.

@Rick: But Lua scripts are an essential part of models, which the artists need to make too. Many artists still can't code though, since they have been spoiled by the GUIs and graphical tools of expensive/pirated modelling programs. But that opens a new job opportunity for programming artists too. Instead of doing hardcoded animations, artists should make their models from submodels and rotate/animate them with Lua. So you can't take out the scripts folder for a decent model viewer. But you can lock down the game code not to allow to do anything which is not part of the game in C++. So my approach is safer

I don't think it's allowed to do what Rick said, to write an asset viewer for non-registered people. You can only distribute games, so the artists can't even use Editor and place models in the testmap, but you have to make the testmap for them. This only works when people are working with a git repository. The essential difference between your game and a general purpose asset viewer is that the game serves only the purpose to make people play the game, and it can't be used for any other purpose (that's what the EULA says also). A testmap can be seen as a map to test the game, since it has also game specific assets only. If you make a general purpose asset viewer, you can easily violate the EULA sentence which says it's not allowed to make universal programs which allows people who don't own LE to make games. And with an univeral viewer which can run Lua scripts, that danger is close. That's why making games is a safer choice, since you will need to hardcode game specific things anyway, and you can even add deliberately some anti-piracy/anti-misuse code which locks your game to be your specific game only, and not somekind of moddable game engine. Besides, a game has lots of specific environmental effects also, so a pure asset viewer would not show the models as they appear in the game, and it would not show how the FPS in the game behaves with higher/lower poly models.

Make a git repository where the artists can put their assets in and you can share your game. Then the artists can run the game to see their assets in-game. You can make a testmap which has all the assets used in your game.

It doesn't register anything, but you give the function to be called as parameter when you call the ForEachEntity...() function. It's not really a callback in that sense, but only a function pointer.

That's your dll source code, not your dll header. The dll header should be similar to engine.h and engine.cpp, but of course only declaring and loading and your own functions. You don't need to make any changes to engine.h and engine.cpp, that's what the LoadFuncs() function is for, that you don't need to change them.

1) Yes 2) No, you don't have to care about the LE functions in your dll, but only in your dll header. You only write your own additional functions in your dll, and let your dll header use LoadFuncs() in your OwnInitialize() function, so the game can see both your own dll functions and LE functions. There is no overlapping, wrapping or duplicate functions needed.

Yes, it's possible using the LoadFuncs() function of the C headers in your dll header (not in your dll, your dll uses the normal Initialize()/Terminate() and also a function to return le_hlib to your program). Make a similar function like Initialize() in your dll header, but instead of loading the engine.dll, only pass the le_hlib handle from your dll to it. You can make your own dll, which loads the engine.dll and then both your dll and a game has access to the LE functions. The game only needs to load your dll, not the engine.dll, but of course both your dll and the engine.dll is needed to run the game. Your dll should look like this: // gemini.cpp : Defines the exported functions for the DLL application. // #include "engine.h" #include <string> using namespace std; #pragma warning(disable:4996) #define DLLEXPORT(s) __declspec(dllexport) ##s _stdcall extern "C" { DLLEXPORT(int) GeminiLEInitialize(void) { return Initialize(); }; DLLEXPORT(HMODULE) GetLEHandle(void) { return le_hlib; }; DLLEXPORT(int) GeminiLETerminate(void) { return Terminate(); }; // Your own other functions here, which can also use LE commands. // You don't need to wrap any other LE functions as they can be loaded // using the LoadFuncs() macro in your dll header, so that they become accessible // to the game source. };

Just use lots of if() statements and state flags to make the logic easier.

I don't have any problems with 2.40.