Mumbles

1. Set the body's angle with the RotateEntity command before adding the "throwing" force. It will keep this orientation until it hits something. 2. Get the Entity's AABB. The mid point of each axis should either be the exact centre, or so close no one will know the difference (C/C++) TVec3 GetMidpoint(const TEntity &Entity) { TVec3 OutputVector; TVec6 AABB = GetEntityAABB(Entity); OutputVector.X = ((AABB.X1 - AABB.X0) / 2) + AABB.X0; OutputVector.Y = ((AABB.Y1 - AABB.Y0) / 2) + AABB.Y0; OutputVector.Z = ((AABB.Z1 - AABB.Z0) / 2) + AABB.Z0; return OutputVector; }

You can simplify your code quite a bit actually by using the mod operator... (Assuming it's C, which it looks like) //Mouse wheel checking m = LE.MouseZ(); int CurrentTowerCount = 5; //Every time you add a tower, increment this - this should actually have a higher scope visibility than just this function, otherwise it will keep resetting this value to 5 towers (0 through 4) every time it checks for mouse movement if (prevM != m) { (selectionID += (prevM - m)) %= CurrentTowerCount; //If it's going the wrong way, swap the += for a -= SetNewCurrentTempTower(); prevM = m;//I'm guessing you had this line as well... }

Graphics(Width,Height,(Fullscreen * 32)); Now that - is pure elegance... Trust me, I'm a pro...

All seems fine now. Res is fine, and stabile is always 1 (not sure if that's good or bad)...

Still flawed I'm afraid. In full screen, it's fine. 1280x720 window failed same as before. GLSL not supported, so call to Graphics still failed 1024x768 window gave me a 1920x1080 window. Yeah it loaded, but most of it was off screen. It's getting there, being able to choose your own resolution is a nice ability to have, but it seems if you choose window mode it completely ignores the other values you give it. I've also forgotten what I was meant to be looking at once again...

I'd probably remove the attachment in the first post. It's served its purpose now and is no longer the current version.

It still seems like Graphics is failing. What parameters are being passed? I ask because my system is fine with 1280x720 window, but not 1280x720 full screen... Also remember, that Graphics returns an int. 1 if successful, 0 if failed, try capturing its return value

It really does sound like Graphics() is failing... Why? Because when you say (C++) const GLubyte * GLBuffer = glGetString(GL_SHADING_LANGUAGE_VERSION); If you haven't created a graphics context first, then any call to glGetString will return null. Now, look at everyone's log files - what's the reported GLSL version? Looks null to me. A call to LE2's Graphics() will create a valid Open GL context, such that glGetString will then work. This is my code to print out a nicer error message for users without capable cards const GLubyte * GLBuffer = glGetString(GL_SHADING_LANGUAGE_VERSION); CurrentPosition = 0; std::string NewGLSLString = ""; do { NewGLSLString += *(GLBuffer + CurrentPosition); CurrentPosition += 1; }while(*(GLBuffer + CurrentPosition) != ' '); //Stop when it finds a space - not interested in anything beyond that float GLSL_Version = atof(NewGLSLString.c_str()); if(GLSL_Version < 1.20f) { std::cout << "Sorry, your graphics card doesn't support GLSL version 1.2 (Your version is " << GLSL_Version << ")nThis game requires a video card capable of GLSL 1.2 or highern"; system("pause"); return false; //Failing this function will then call Terminate followed by main() ending } This code doesn't work if Graphics hasn't been called first, since it's unable to detect which GLSL version is present. You could adapt that to display a message box instead, but since I'm using a console application, that works for my purposes.

Same - didn't even look like it tried to create graphics context... Makes me think it tried to call CreateWorld (or CreateFramework) without calling Graphics first...

Even on faster computers, it will go below 1.0 sometimes if you are v-syncing (although you weren't in this case). With v-sync it will never really go above 1.1, but could drop to 0.9 even on a fast card due to the vertical wait, and the integer millisecond precision. Perfect 60 fps requires 3 frames spaced evenly apart every 50 milliseconds, but 50 into 3 doesn't go, so what you get is: frame 1 at: 17 ms (17 ms between frames, 0.333333 ms too slow). AppTime will be 0.980392 (16.666667/17) frame 2 at: 34 ms (17 ms between frames, now 0.666666 ms too slow). AppTime will be 0.980392 (16.666667/17) frame 3 at: 50 ms (16 ms between frames, drawn at exactly the right time). AppTime will be 1.041667 (16.666667/16) But yes, I do like the images. In bold so it doesn't get lost behind the wall of text. But also, if people are like me, with small monitors, 1280x720 is a better substitute resolution than 1680x1050. It would also lead to slightly faster rendering on hamster powered computers like mine.

No, it's more likely to be the age of the card. It's an 8800, which now, certainly isn't new. For me, it would probably only get over 100 fps if all post processing was disabled. But I'll stick with the card until it finally dies on me (unless someone wants to buy me a new one of course )

Sadly, I don't think it's going to work on my computer. No idea which shader it doesn't like but even after the scene is finished loading, the splash screen is still there, and constantly being redrawn, on top of a very blurred out world. But I don't normally have a problem with DOF in the editor. I've uploaded a screen capture of what I see: You can see when I mouse look, it looks like I can see godrays, but I just really can't make anything out. Maybe my card is about to die, mind you, it is nearly 4 years old now...

I'm afraid it crashed for me... Lua error: [string "zip::x:/fleshgore/game/data.pak//data/models/items/weapons/vweap/weapons_vweap_shotgun.lua"]:10: C:/Program Files/BlitzMax/mod/lugi.mod/core.mod/lgcore.cpp:891@lugi_index_object: Index for object is not a valid field or method. Does it need me to have BlitzMax or something? I thought the exes were supposed to be standalone... Entire engine log is attached Also, it was too big for my screen. Too tall for 1680x1050, looks like it tried to use 1600x1200 windowed Edit: I should add, rather than crashing to the desktop. It got stuck playing a buzzing sound. Once I'd switched to the terminal window and seen the lua error, I then had to press escape to close it. Otherwise it would have sat on the splash screen forever Engine.txt

It's down to the Open GL renderer that Leadwerks Engine uses. I wouldn't want to say it's impossible to make Open GL work on a 360, but Microsoft certainly make it as difficult as possible to do so, and it just isn't worth the effort considering the video card it has built in is so old... I think it's equivalent to a GeForce FX (the one between 4 and 6). Big studios probably have to heavily optimise to get decent performance on it. Whilst we indies should also optimise, we shouldn't be putting in as much effort as they do, because we don't have such large teams at our disposal.

Meshes don't have mass, bodies do.

SetBodyVelocity sets an absolute speed on a body. Use it to make a body move at a certain speed. Be careful though because setting a Y velocity of 0 will "remove" gravity's influence, which can cause an object to be suspended in mid-air SetBodyForce applies to specified force to the body. Speed however is not constant, because an object with a large surface area suffers greater friction than an object with a smaller surface area. AddBodyForce is the same as SetBodyForce, but it takes into account any forces already acting on the body rather than overwriting them with the new one. In the C newton interface, the force commands can only be used during the ApplyForceAndTorque callback. I believe however in Leadwerks that these can be called at any time, because the callback is hidden from you, and these functions instead probably just update a hidden variable called something like BodyForce, which is then read in the hidden callback. SetBodyVelocity can always be used at any time, both in Leadwerks, and in the C newton interface.

If it's appropriate, try not to write to a file in the middle of a game loop. It's about the slowest thing your computer can do (even when using an SSD, but especially when you're not). If you do have to do this, move it off into a new thread, as writing (or reading for that matter) will block the thread that called it until the IO has finished. Also look for unnecessary code. I had a blonde moment only a few days ago, regarding a loopback server for inter-process communication. When I spotted what I'd done, I commented it appropriately... int ConnectToLBS(void) { if(LoopbackServerRunning) { if(!LoopbackServerClosing) { //LoopbackServerRunning = true; //well no stuff, of course it's running, that's how we reached this nest... What this line says is: "If it's running, and it's not closing, then it's running" duhhhhh... //201203011615 Wait, why was I trying to set that from a connect routine anyway? Double duhhhhh. Answers on a postcard...

It's probably the most accurate of the mainstream solvers (Not so sure about bullet since its most recent update). Car suspensions should be possible by joining the cylinders (wheels) to the main box (chassis), and then adjusting the elasticity, softness and friction of the wheels against different "floor" materials. Remembering of course to apply torque to the wheels rather than moving the chassis directly (otherwise the friction won't work correctly for acceleration). The required commands are exposed in LE 2, so there is no need to integrate a separate version of newton just for that.

Don't worry about globals, I used to love them when I was like 15 (when I was still using Dark Basic) because they were so convenient, but now I hate them. They very quickly use up just about every name you can think of, and it becomes almost impossible to track down where it's being modified when you have a large project. For me, any variables that aren't limited in scope to a single function, will either be protected access inside a class, or inside a namespace (often with many more secretly hidden inside a deeper unnamed namespace if they're supposed to be read only), depending entirely on whether I think I'm building an object, or a set of object helper functions, "CreateNewEntity()" as an example.

Do they really mean private, or would protected be OK? I find myself only giving functions private access if they are only called the constructor/destructor. Variables I never make private, as I've never found a reason why a derived class shouldn't have access to them.

Thinking about it, the drawback to my idea is: For models, it only loads a single model. No texture(s), no LODs no physics. You'd either need something like: LoadModel(char * LOD0, char * Texture0, char * PhysicsShape, char * Texture1 = 0, char * Texture2 = 0, char * Texture3 = 0, char * Texture4 = 0, char * Texture5 = 0, char * Texture6 = 0, char * Texture7 = 0, char * LOD1 = 0, char * LOD2 = 0, char * LOD3 = 0, char * LOD4 = 0, char * LOD5 = 0, char * LOD6 = 0, char * LOD7 = 0); which as you can see, looks bloated and scary... Or you'd need to be able to something like (just a bit of an idea): struct LE3DModel { int NumMeshes;//typically a mesh will be used LE3DMesh * MeshNum; LE3DBody CollisionShape;//Working along the lines that all submeshes are designed to occupy the same volume, thus only one copy of the shape is required char HideShowMask; //Assuming the maximum number of meshes is 8 (the main one and seven lower LODs), a char can be used with the bitwise and (&) operator (when reading) to see which meshes should be drawn, and which should be hidden. }; LE3DModel * CreateModelContainer() LE3DMesh * AddMesh(LE3DModel * Model, char * MeshFile, int LODNumber); void SetMeshTexture(LE3DMesh * Mesh, LE3DTexture * Texture);//Previously loaded with a LoadTexture type command void SetModelPhysics(LE3DModel * Model, char * PhysicsShape);//Load a serialised physics file (previously copied in to RAM), and apply that physics shape to the model Could be very easily converted to OO at a later stage. Slightly easier to follow, but probably requires a small re-write of the engine, thus I wouldn't be too optimistic to see either of those suggestions included in the first release. Perhaps a later update if Josh feels like the idea has some merit to it...

You're probably best by simply making your own scripting system for your game - that way, you control exactly what is exposed and what isn't. Then a quick once over from Josh (to make sure it really isn't allowing someone else to create games with his engine for free), and I'd guess you'd be good to go. It's not that he isn't understanding where you're coming from, it's that he wants you to be very definite in what you are proposing when it comes to scripting, because it's his business potentially at stake. He doesn't want an agreement being misinterpreted (or worse, a deliberately vague agreement whereby someone then wraps his engine and then makes it available to users who haven't bought it). Sorry if this comes across as a bit harsh, and sounds a bit like "guilty until proven innocent", but it's really nothing to worry about. Josh just needs to protect all the time and effort he has invested into creating this engine (and the successor that's currently in development), and that's done by making sure people aren't effectively giving the engine away for free in the form of a scriptable game. Whilst I'm not affiliated with the company in any way at all, I don't think you'd have any problems with inventing a macro like system as long as Josh knows just exactly what power the scripting system will grant to people who buy your game (who may, or may not own the Leadwerks SDK)... Remember, you can always run it by him with a private message if you'd rather not post it in public.

I think a better method would be to allow loading any type of asset from a char pointer. How you put the data there is up to you. You can store your assets in any type of encrypted and/or compressed file, but the onus is on you to to get it out of the file and into memory... As an addition to the standard loading from files that is, not instead of.

The first question is easy to answer. Once paid, you can create any number of games, commercial or free, doesn't matter... A related question some people will ask is: "Is there a free, non-commercial version" to which the answer to that is no. The second point is basically trying to say you can't make a program which creates games, using Leadwerks for its underlying graphics subsystem. Only really one person can answer your question here for sure, but I'd go along the lines of: Creating a game which allows additional weapons (for example) to be inserted without recompiling the game, would be fine (how you'd manage something like that is your choice). Creating a scripting system which would allow an additional "game mode" to be inserted, such as adding a capture the flag mode to a game that already has multiplayer capabilities would be dubious (I'd work along the idea of it not being allowed). Building something like FPS Creator (if you're familiar with that) would be unquestionably, not allowed. Scripting however for the process of providing the user with some sort of automation, (as in "macros") is probably allowable, so it really depends what sort of capabilities your scripting would enable, but like I say, only one person can actually answer your question definitively...

your if(view == 1) block hasn't got a a RenderFramework() call in it. and it seems that view is 1 Also, your check for KeyHit(KEY_UP) allows view to be set to 3, in which case nothing will happen.