Canardia

Quick donkey bridge: red model = your model has bones and animation, but you didn't specify a _skin shader in the .mat file black model = your texture is missing mipmaps

I think it's because the Lua script is doing calculations all the time. It could be fixed by having a global Lua variable like "nocalc=1", which would stop all all Lua scripts from doing anything.

It might be called SetEntityViewrange() or EntityViewRange(). Oh yeah, the Wiki says it's called EntityViewRange: http://www.leadwerks.com/wiki/index.php?title=Entities#EntityViewRange

You can try SetEntityViewRange(scene,3,1).

There is no need for a start point model, because any Ctrl-clicked model in the scene can be the start point. I only need an arrow model and a cube-like (=3D symmetric) model which is always world axis aligned.

I was thinking it could consist of 2 separate models. One which is always world axis aligned and which you can move in editor with the gizmo, and one which is at the same position, but pointing to the begin model. So maybe the pointing model could be like an arrow. It would be even possible to stretch the arrow so that it would look like a line between the begin and end end. Lua should really have OpenGL commands, then this could be done much more professional.

Yes, it's quite easy to do. I can make one and upload it to the Tools downloads. Maybe you could make me a model for the ruler end, something like a cube with some texture. When you Ctrl-click on any model in Editor, it will be set as begin marker, then you can move the end marker around and it will show you the distance in meters, and also height, width and depth distance in meters. And maybe even angle and compass direction

That's because it's still not even a 0.1 version yet, but only 0.0.19.0 Industrial version numbering goes like this: major.minor.plannedchanges.bugfixes The first 0.1 version, so the full version signature will be then 0.1.0.0, will be much less messy, as it's not needed to use C99 anymore, but we can use full C++98 now (MinGW 3, VS 2008 C++), maybe even C++0x (MinGW 5, GNU 4, VS 2010 C++). The reason to use C99 initially was to keep the gamelib API a set of standalone functions instead of classes, while still getting some benefits from OOP. Now people have learned C++ better, and more advanced C++ programmers use LE, so it's time to go with the majority. And hey, we are offering a way to get rid of the main loop now too, which should make every true C++ lover's heart beat higher I've also played around with the idea to use events (thanks to Rick, our event fanboy), since it would allow gamelib to execute things in the correct way, and not be easily broken by the user's wrong order of commands (like putting update+render at the top of the main loop and causing entities to lag behind in motion).

I thought that is what gamelib/gemini is already doing You call high level functions like LoadMap, MovePlayer, DamageEnemy, etc... For the next version I will also add a RunGame() function which doesn't return until the game is exited with the ExitGame() function from inside the loop inside the RunGame() function. That's how FreeGLUT does it also. The user can add then standard callback functions like KeyboardHook, RenderHook, DrawHook, etc... Of course RunGame() is not needed, but you can still write your main loop. RunGame will be a method in the Game class, so for your own game, you can inherit the Game class and add your own additional code to the KeyboardHook, RenderHook(), etc....

If BlitzMax does't have a certain official DLL function, it is found as a undocumented OOP style call. For example the GetCameraRange() function is called in BlitzMax: camera.nearrange and camera.farrange. You should be able to do anything you need with OpenGL commands in BlitzMax, so you don't need any Max2D.

You should do only generic logic and behaviour in Lua, and game specific logic on the Lua entities in C++. From C++ you can access any Lua entity using FindFirstEntityByKey("name","enemy_9") (see gamelib).

It means you have done some mistake.

Yeah, Editor should be the central tool when making games. Even if you don't use Editor scenes much, it provides a nice portal to access all assets and avoid unnecessary coding in the main program. That's why it's important to have a custom menu option, so you can put there all kind of exe files to launch, and even give them some command line parameters like $selectionname for the asset name which is currently selected, $selectionfilename, $sbxfilename, $projectname, etc... I would first put "Save Backup"="git push" and "Sync with Team"="git pull" there as menu commands, so I can make backups and sync my game files with other team members directly from Editor. Next, I would also add "Code Game"="start $projectname.sln", to start Visual Studio, and then also "Manage Teamspace Files"="git gui", and many more things

A light has a camera, since you can say CameraRange(light,0.01,1000), but the DLL is missing a method like GetEntityCamera(light).

Font Studio download can be found in several places in the forum, if you search for Font Studio. Here is one: http://leadwerks.com/werkspace/index.php?/topic/1524-font-studio/page__view__findpost__p__14962 Here is another one: http://leadwerks.com/werkspace/index.php?/topic/1974-yet-another-flaw/page__view__findpost__p__17986

Good question, I think it should say: Material* mat3 = new mat1->Copy(false); because else mat3 is indeed only pointer to something which mat1->Copy(false); gave it.

I think you can get everything you need for the C# headers from the C headers? I agreed earlier with ZioRed to send him always all changes to the C headers, so he gets an impulse to update the C# headers when the C headers are ready.

Often when you develop games, you have many ways to do certain things, and then you find the optimal way, but often forget it again, until you remember it again. So to have somekind of reference of those best found ways to do things, and also a short description why it is indeed the best way, I want to collect in this thread all kinds of ideas what people have found to be the optimal way of doing certain things. Let's start with how models should be done, especially models with submodels and attached models, like wheels, weapons, doors, and such things. Suggestions: 1.) Models 1.1.) All moving, rotating and removable parts of a model, should be separate models (=separate gmf file). It is easier to access each part separately, and to manipulate them via entity or physics commands. When you have multiple same parts, like wheels, then it also consumes less memory, since the part will be instanced. This also allows customization of instanced complete models, since its parts can be different. 1.2.) Components of a model should be always assembled via its Lua script. The Lua script is just as easy to update as a config file, so you don't need a seperate config file for each model. You should use named bones in the main model to mark the positions of the parts, and when you don't have bones available you can still do it from the Lua script using part1:Movef(x,y,z), and finally of course part1:SetParent(mainmodel) or part1:SetMatrix(mainmodel) in the UpdateMatrix() method if it can't be parented (for example transparent objects). Also emitters, lights and other components of a model should be assembled in the Lua script. 2.) Scenes 2.1.) Scenes should have a GravityCenter model. Often in games you need to know where the "Up" direction is, for example to make smoke emitters point to the correct direction even when the model where the smoke is attached to is rotating. For this purpose you should first insert a GravityCenter.gmf model into the scene, which will then create a global pivot which is located somewhere at Vec3(0,-50000,0), so each PointEntity(gravitycenter) would be aligned to the "Up" axis (just facing the opposite direction of course, but you can then turn it around using TurnEntity(Vec3(0,180,0)) if you need to). Since now every scene has this GravityCenter model, you could also store other common settings for all scenes into its Lua script, for example settings which Editor doesn't save in the Scene.sbx file. 3.) Main Game Programming 3.1.) OOP should be used as much as possible. OOP allows to write much cleaner code, reusable code, and less code. So it brings a clear benefit over procedural code. All major languages like BlitzMax, C++, Pascal, Lua, JavaScript, Java, C# support OOP (although in Lua it's a bit "fake", but still for the user and the needs where you use Lua (for models), it's sufficient). 4.) Version Control 4.1.) Always use version control software, even if you don't work with a team. Even if you work alone, you should always use a version control software to make a quick backup of each minor achievement in the game development. You don't even need a server when you work alone, since it just creates a hidden directory in your project folder. Products like Git, Hg, Svn are free and the most popular version control softwares. If you work with a team, it's good for sharing files over the internet, and even collaborating on working on the same files. You can also restore each file from each saved step seperately, so it's not only good for a complete backup of your project, but also to restore some older version which had something you lost in the development process. You can have a project folder on your desktop where you create a icon to push the changes to the repository, so it's only one mouseclick away to create a backup, and it takes (at least with Git) usually less than a second. What other suggestion could we add? Also programming practices would be good to have, although I put this into the "Leadwerks Editor" forum since it's more whole game development related, not only game programming related.

Read the description "code for making instances and unique copies of a material"

The biggest problem when not freeing your classes with delete, is that their destructors will never get called. So if you do some file I/O in the destructor (like deleting temp files), they will never get deleted, so it's not always only a issue about freeing the memory. Why do you think you have thousand of temp files in your temp folder? They are mostly remains from crashed programs, or not responding programs which you had to terminate from the process list in task manager.

Individual of course.

Try adding 10000 cubes and see if your forward renderer is still faster with your sun then. So forward renderer is only good when you make simple scenes, and not real games.

Does the same work for models? Model* mod1 = LoadModel("cube.gmf"); mod1->SetScale(1,2,1); Model* mod2 = mod1->Copy(true); Model* mod3 = mod1->Copy(false); mod1->SetScale(2,1,1); mod1 and mod2 would be double high, mod3 would be double wide? Or can you make instanced models which each can have their own scale?

Yeah, the OS will clean up the memory, even if the game crashes, but it's not a good way to do things. Write your code so that it doesn't crash and delete the memory yourself.

I've tried other engines too (I own around 12 engines), and while they were technically perhaps somehow digestible after a few bottles of vodka, the lack of support was the main cause why I couldn't get anything done with them. Any product is worthless if you are stuck with some problem and nobody can solve it. With LE you will never face that problem. The reason for that is that LE is completely freely programmable, and that itself allows you to replace any part with some 3rd party library. And in most cases the community will give you an amazing solution, before you need to do anything.