Canardia

LE could mean also "Leadwerks Enterprises"

Make some checks if it finds the windmill mesh and its blades bone/submesh.

You can always use network to communicate across platforms.

You only need to put: explorer.exe there, because the Game Path in the Settings tab is used as parameter for the Project Files button. Ah, but now I noticed, that I haven't uploaded the latest version of Flow, where there was a little bug with this project files folder also. I'll upload version 0.0.3.1 now.

This Unweld only aligns the vertex normals to the same direction as the face normal. The default cube in UU3D has the vertex normals in a 45 degree direction facing outwards from each corner of the cube. For rounded objects this works, but for sharp edged objects it looks bad, because some places get darker than the they should. Maybe the intensity of the gouraud shading could be adjusted with a higher ambient light, but then the whole scene would look ugly again.

The command-prompt window can be enabled/disabled by setting in your IDE windows/console app mode.

UU3D has that bug, as you can see from your screenshot too, that it doesn't create evenly shadowed surfaces. I have to run always 3D Tools -> Unweld Faces, to make them look correct. Here's what I mean: Default UU3D cube, with shadow bugs: Unweld Faces cube, now faces are correctly shadowed: Of course, in-game you need also some glossy cubemap (like in Filax's parfume shop demo), to make it look more real, or at least a specular map.

Apple sells more, because everything related to Apple costs something, so everyone using Apple needs money. Android has the freedom to make free or commercial apps, and most people prefer free apps. When using Android, you don't need much money, because you have enough money left for living after making a game. And stats don't tell much in the end. The guy who made MineCraft got 6 million in a week, although it was for PC only. Crysis got 51 million in the first week, although it's for high-end PCs only. And if you develop a game which you think others like, but you don't like it, then it will be horrible because you don't put enough innovation and love into the game. It's best to make games which you really like (same with music also), because there are always millions of other people who like what you like too, and then you have a better chance to finish the game also.

Selling on Android market is very easy: 1) Goto Android.com and buy Android Dev License: 18€ (25$), and connect it with your Google Merchant account (it's free, and the instructions are included when buying Android Dev license). It's a one-time fee, not annually like Apple Dev license. 2) Make your own company certifier, the instructions are found in Android.com also. No money needed, just do it yourself. 3) Make your game and sign it with your company ID, so that it's not debug apk, but a release apk. Only release apks can be published in Android market.

It's actually wrong to compare Android and iPhone, since there is only one iPhone (a few different versions), and thousands of Androids. It makes more sense to compare a Galaxy S2 with iPhone 4, because they won't change much and don't have random specs. As a Indie, I don't really have to worry where my game works. I can choose to make a low-end game which should work on all phones, or I can choose to make a high-end game which works only on Galaxy S2, and perhaps on HTC Evo 3D and the new Motorola Atrix 5G. Even if I sell only 10 pieces of one game, I make profit, because the costs are shared with all games I make.

Code::Blocks is kinda like a graphical makefile maker, so it should work then too. Possibly also CygWin can be replaced with MinGW, although I don't know yet if it's better or worse. Code::Blocks supports CygWin also, so either will work. I will test that when LE3 beta comes out. I haven't needed an Emulator with my Galaxy S2, because it has USB 3.0, which is insane fast. As soon I have an apk file, I can just do "adb install filename.apk" from the command-prompt, and it's right on my phone's desktop. That command can then be integrated into Code::Blocks as well, so I have a one mouse click action in my C++ editor to install it on my phone. For debugging I would use in-game statistics displays, I've always done that, and find it easier and faster than some debuggers, which usually then don't even work the same way as the release code. I could also write the output to a text file on my phone, because the phone is just like an USB stick, and I have mapped it with a drive letter, so then I have realtime debugging results on my PC. I've realized that also, that it's in the end faster to make the game first work in Windows. Because the same game code should work on Android then too, especially if you use only source code libraries, and no precompiled .o, .lib or .dll files. With modern high-end phones I don't even have to worry much about FPS, as they are sometimes faster than some low-end PCs For example my phone can run a game with terrain, physics, realtime shadows and lights at 60 FPS, while some low-end phones run it at 10 FPS. At 10 FPS I can still have realtime FFT water with reflections, but that's too heavy even for my phone. Then the porting is only one more independant step in your game development pipeline, which needs to be only once also, since then you have already all your libs ported and adjusted for your next game.

Also with other engines you have to install 5 or more different SDKs, but that's just setting your computer up, and it's usually very well documented. Also when you install Windows, you have to install like 30 different SDKs, drivers, tools, programs, etc... Which is actually more difficult, but most people seem to have it working. The actual compiling should be quite easy though?

You will still need C++ with Lua, because at some point in your game development, you need more features than what the standard Lua commands can offer. I actually had an idea today when reading other people's Lua questions, that I could add a GameLib Lua template, which includes a custom engine.exe, which then brings more commands to Lua, and also faster commands, because most of the operational code would be in C++, and you only call the commands from Lua. The FPS template I'm making right now, will also have a TPS feature.

Ogre is only a 3D renderer, while Leadwerks is a 3D game engine. However, there are some unofficial add-ons and libraries for Ogre, which make it more like a game engine, like 3D sound, 3D network, 3D physics, 3D editor, but it's all not very standard and usually some part is out-of-date and doesn't work with the other. That's why you need a game engine where the whole system is working and officially supported.

We will have everything we ask for, because we make them. That's how this community works

It should be the same as the C++ tutorials, just add "LE." in front of all engine commands.

That would be quite inflexible, since scripts might sometimes want to run faster and sometimes slower, so the best is if you write your scripts so that they are reentrant, if they do some loop-like behaviour. And you don't need to run each script in each frame either, in most cases it's fast enough to run a script every 1 or 5 seconds.

I noticed something wierd in LE 2.5 today: If I have an animated model, all the bones are created as seperate entities in the main world and called Joint<number>. What's up with that? Can I remove them?

They run sequentially, and each script should not take more than 0.15ms to run, since 15ms is 60 FPS, so with 0.15ms you can have 100 scripts running at 60 FPS, but since the rendering takes time also, you could still run 50 scripts (30 FPS cost). You can use the Millisecs() command to measure the time a script runs, and make some alert if a script runs longer than you want.

3D Tools -> Polyreduce Model...

UU3D can also make different LOD levels of your model with one mouseclick. There is the polygon reducer tool where you can see in realtime how your models looks with lower polys when you move the slider. This is also very handy when you convert free 3DSMax models to a game friendly polygon count, and you save tons of money because you can use then directly all free models you find on the net.

Now things start to get really easy The most difficult part was to get the first GameLib LEBuilder template working tidy and expandable, so that it can support also bigger game projects. Now I started to make a GameLib FPS template, which I will then simply add to the GameLib Template Pack. So there will be always only one GameLib Template Pack, which you can then download when you see it containing new templates. And with the new Database class, you can configure your games very easily using the SQLite Database Browser, for the parts which are not configurable in Editor. So there's no coding involved for many things in your game, but only GUI actions.

Ultimate Unwrap 3D Pro can convert animated x files to animated gmf files.

I guess I can use then sqlite, sdl_net, and glut also in Android when I code with C++, since they are available as full C++ source code, and as far I know, Android uses GNU C++ too.

How do you port the rotating cube example written in C++ then? I would think you need different Code::Blocks project files or different makefiles for each platform, but the C++ game source code would be identical.