Canardia

Yeah, it has to be that way, since you need 3D models to light something, not just a simple picture.

Can you elaborate on that? What other benefits do you get when not using those methods?

I think in good OOP manner it should be like this: Sprite testsprite("testsprite.dds");

I think The Josh will fix it very soon, since it's an easy fix and quite important too. Not sure if I will need to make a bug report also, since it crashes always.

Last time I tried it with LE 2.32, the transparency stopped working correctly after parenting cross-world objects. If objects are below the gravitycenter, they would be in Australia, so it works correctly. Without gravity center, people in Australia would fly into space.

blend=alpha only makes the material transparent when the texture has a transparent alpha channel, while blend=light makes everything transparent, but in a funny way which is affected by light a lot. There is a more technical explanation, but I'm too lazy to think about it now

I seems to be a bug in the engine.dll, only Josh can fix it.

You need also blend=alpha or blend=light in the mat file.

Don't worry, I've learned everything in university, but never understood linear algebra which talked about m*n matrices and their operations. That's why you buy a entity oriented game engine like LE, so you don't have to use maths ever in your life again. All you need is PositionEntity, TurnEntity, PointEntity, and other of those simple, logical and natural commands.

Thanks, I heard the same from Josh also. Gotta try it, it would save a lot of time from our artists and programmers when they didn't have to split every little submesh into a seperate gmf file. Of course then physics won't work on the submeshes as they do with submodels, but in cases where it's not needed, it's a good option.

Because it gives much more benefits, and 2D user interfaces have been obsolete for long time, even if nobody has made a decent 3D user interface yet. Maybe Linux has, but it does not use it for additional benefits, but only as a task/desktop switcher, so it's merely an animation. I feel that it's wrong and unethical to tell people to do it how everyone else does it, since it doesn't push the evolution of computers further. I think you should always suggest something which is better than what we have now.

I don't see any commands in the Wiki which could do this, so if I want to rotate one mesh in a model which includes multiple meshes, it seems I need to breakdown the model into several models?

It should be 3D though, and use OpenGL.

Why don't you see it: http://www.leadwerks.com/wiki/index.php?title=Entities#GetEntityMaterial

No, you don't need invisible.mat. You need a transparent material. You can paint models with PaintEntity(entity,material) in realtime, so you don't have to have multiple models loaded.

You need to keep the models in the normal world, since you explicitely want to see the shadows of transparent objects. Framework should get a finer breakdown of the rendering controls, for example: fw.Update() // your main game code here, also hiding of invisible objects using entity.Hide() fw.RenderWorld() // code here to make the invisible objects visible again using entity.Show() fw.RenderLights() fw.Flip(0)

I had the same problem, so I used a hardcoded GetChild(2) to get it to work.

Paint the building parts with a transparent material. Another way would be to not use Framework, because then you could hide the models before RenderWorld() and show them before RenderLights().

The 16 members of a 4x4 matrix are usually numbered in mathematics like Y and X coordinate (the university teachers speak of columns and rows, which is kinda stupid, since even I think in Excel with x and y coordinates (much easier to make VB scripts that way)). So when they say m11,m12,m13,m14 (or m00,m01,m02,m03, if they start with 0 instead of 1, which is unusual since when talking about columns and rows you start with 1, so basically mathematicians have no clue about consistency, only C++ programmers do), they actually mean: cell at coordinate 1,1; 2,1; 3,1; 4,1. So in LE you have TVec16 which calls them A0,A1,A2,A3. For y==2, it's called B0,B1,B2,B3, etc... I could have called them like in mathematics, but then I would have needed to use y,x=x,y coordinate system, which would cause even more confusion between programmers and mathematicians. So calling them with letter+index can not be interpreted wrong, and it's also shorter to type. And yes, it is a common standard notation also, I checked several sites about it. It also unifies vector and matrix notation which is kinda cool. And since it's a Vec16, and not a Mat4 (which are the same thing though), you don't use x and y coordinates in Vecs. If I would have used Mat4, it would have been inconsistent again since it would be totally different that the Vec2,3,4,6 structs, which I wanted to avoid, since it's basically the same thing: just a container for an n-amount of floats. However, in addition to TVec16, there could be also TMat4 in the C headers, which would be the same as TVec16, but only using different member names. How useful that would be, I don't know.

That's kinda exactly what our game is about. Just don't place weapons in the level Maybe you could do some more cars when we have finished the first demo version?

I'm working on 2 commercial games. One is a battle car racer, one is a airport simulator.

You need to set the global parameter in EntityParent() to 1, else it will offset from the parent.

You can have both.

It was removed, because nobody knew for what it's useful. If you want to do something like this, you can do it with normal hinge joints also, as you want the parts animate using the physics too: However, if the joint part is a piece of a flexible tube, then a universaljoint would be useful.

TTF fonts work on any system, when you use FreeType library.