Road Kill Kenny

Have you considered using network interpolation. Its tricky to get right but makes things smooth. Have a read here https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Don't know if you can 'expel' children from a parent but you can un-parent children by setting the parent to Null EntityParent(TEntity, Null);

Good to hear that things are happening and good to hear that there is a strategy in place behind it all. I'm looking forward to seeing what will become of all this. My week has been good thanks XD. Had my last day working on the Gold Coast Rapid Transit and starting monday I'll be working jsut 5mins drive from home. That means 2 hours less travel every day = 10 hours per week = A lot more time that i can put into game dev. Looking forward to seeing the functionality of LE3D so I can start designing the technical side of my game. But as that's not available yet I've been deep into designing the gameplay and mechanics of the game as well as researching / documenting a new artwork pipeline with MakeHuman, & facial mocap technology XD. Having a lot of success. Anyway, looking forward to your next blog. ~ Ken

You sure?? http://area.xors3d.com/forums/viewtopic.php?f=5&t=912 Status update as recent as 11 days ago says that the dev is looking for a full time job (elsewhere) and won't have as much time to develop for the engine. Granted he says he will be doing it but if it was me I'd be worried. Anyway good luck. P.S. Not trying to rain on your parade just saying what I see.

Having a quick read of Xors3D forum it looks like the future of Xors3D is questionable. Apparently dev is seldom around. Not sure how file format is a good way to determine which engine is better but anyway. There's a pretty dam good reason not to use jpeg's in games as well.

Cheers couldn't quite remember while at work. So For a leaf you would probably use alphatest because its either a leaf or not... Unless you have translucent leaves

You need to set up alpha blending in the material and you need to choose a shader that considers alpha. So Blend Mode: Alpha Pixel Shader: A shader with alphatest... or is it alphablend.. can't remember off the top of my head.

Or when u use 'MakeDDS' tool that comes with LE there is an option to choose called 'Generate MipMaps'

Fair enough

Nope.... Got removed because people were posting the wrong stuff it it.

You change the texture continuously... that's animated. 2D animation is just a series of 2D images one after the other. So what Pixel said is just that. There is no single animated image file.

That's because it should be an 'int' because CameraPick() returns and integer. In fact you don't even need the gotSurface, just delete it. All it will store is a 1 or a 0. 1 if it hit and 0 if it didn't, nothing else. You only need it if you want to check later in your code if it hit something. The data of the position hit is stored in pickS.x, pickS.y, pickS.z as shown here http://www.leadwerks.com/wiki/index.php?title=Raycasting

Have you defined 'gotSurface' ... if so what did you define it as?

nope

Yes it does but I wouldn't bother using the current networking stuff in it. LE3D should have it a bit better.

Well in some games your FPS character has a body - farcry 2 - BF3 - Crysis If you want to be able to see your feet when you look down (personally its frustrates me when you look down and there is nothing there). Make a model that doesn't have a head and set the camera a little forward from the centre of the model. That way you will only see the front of the model and the model won't clip with the camera.

Head over to the wiki www.leadwerks.com/wiki That's the best place to start.

You'll probably find that LE gives you more freedom to code whatever you want without having to jump through hoops. Thats personally why I like it, I have the freedom to pretty much make my own tools for it.

All post processing effects eat up the FPS like crazy especially when you have higher resolution. This is because the shader has to cycle through each pixel and process an effect ... so with HD you have 1920x1080 = 2 073 600 pixels to process for every single post processing effect. Depending on the complexity of the post fx shader this processing time could be different. It seems to eat a tonne of fps. As for the lights etc. I'll let someone else answer. Can't say I have the same problem with a 35fps drop on my system which is not as good as yours seemingly.

Yeh I agree with you on that Rick. Storing it in SQlite and pretty much making it editable in runtime (or make some sort of editor) helps a heck of a lot. compiling every time you want to move it really sucks. Also I agree with you on the percentage. Your dimensions and positions of each UI Element has to be proportional to the screen resolution. The way I do it is that every time the graphics resolution changes and at start up I make a aspect ratio variable for x and y float rx = GraphicsWidht()/[MaxSupportedWidth]; float ry = GraphicsHeight()/[MaxSupportedHeight]]; Generally All my UI Elements I create their base dimensions as if it were a screen resolution of MaxSupportedWidth x MaxSupportedHeight Now all you have to do is when you set the position of the UI element (i.e. TVec3 startpos, TVec3 dims in my above example) you have to multiply them by the relevant ratio. startPos.X*rx startPos.Y*ry however for dims it must only be rx otherwise you will streth your buttons to be out of proportion. dims.X*rx dims.Y*rx I also add in a float variable called UISize. This is so that the player can change the general size of their UI if they want to. So I just multiply all positions and dims by UISize as well.

Welcome excited to see what you come up with.

Hint: LE::MouseHit(1) LE::MouseX() LE::MouseY() LE::DrawImage() Edit: Ok Ok you need a function something like this //startPos is the top left starting point of a UI Element //dims are the dimensions of a UI Element int IsMouseInBoundingBox(LE::TVec2 startPos, LE::TVec2 dims){ if(MouseX() >= startPos.X && MouseY() >=startPos.Y && MouseX()<startPos.X+dims.X && MouseY() <startPos.Y+dims.Y) { //Check if the mouse is within the Button Bounding Box return 1; //return 1 if mouse is within the box } else { return 0; // return 0 if mouse not in the box } } Ok so you might be wondering why that function is just about mouse position and doesn't check if it is clicked.. Well thats becasue I have a hover skin to all my buttons. This is probably the core function that is used for pretty much every UI element I create. Its pretty simple but it works. So thats all I'm giving ya. You'll have to be creative with the rest

Yah its pretty simple. No point using bloated external Gui's. The buety of it is once you've coded the classes its done. You won't have to do it again.

Best Gui is to make your own system using the existing in built leadwerks commans and also OpenGL if ur feeling adventurous. I seem to do ok just with the LE commands tho. Its not too difficult and you will never have more control than that.

Hmm I would say 8 classes is too few for proper OO. It would be pretty difficult locating the problems getting lost in the large classes. You generally want to keep your games in modules (classes) which are easy to manage and have very few public functions such as Initialize Module Function Update Module Function Terminate Module Function That way the main function code can be kept simple and things within the class can be really easily optimised in manageable chunks. I find it really important to plan out your class structures as it can get really complex if not managed correctly. I often find my classes getting too big and end up re-designing it to have more sub classes. <- at this point I wish I had planned it better. I'll use my GUI System to explain how I do things. I haven't been coding nearly as long as a lot of people here but This is what I have come up with in the short time I've been coding. 3 Layers: - Navigation Layer (Class that manages navigation between Screens and/or games) - Screen Management Layer (A group of Classes, one for each screen) - GUI Elements Layer (A group of classes to manage individual GUI Elements such as buttons, sliders. One for each type) So to give you an idea, my current GUI / Navigation system has 14 classes, 10 of which are just for things like buttons. Also all of the Elements are derived classes from a base UIElement class because all elements have some variables and functions that would be the same so It's better to only write it once and use inheritance. (Oh also I haven't even finished writing all the elements or screens) The beauty of it is that once you have written the classes it becomes so easy to use in any number of projects. Each element is an object that you can simply initialize and updates. So for example each UI Element class has the following functions 1. Constructor <- Well I use the constructor as the initialize function, taking in all data on position, click box position, scale, images used... etc. 2. int UpateUIElement() This function will update the element. So in the case of a button it will first check if the mouse is hovering and then it will draw the button as either untouched or with a hover glow. Then it checks if the mouse was clicked. If so it returns 1. This update function also calls other private functions within the class but these never get seen once you have written the class. 3. Destructor <- I usually just terminate a UI Element with the class destructor Of course for some elements you need more functions such as choice bars. You need to have a function to add options to the choice bar and such. Just only make public functions when necessary and try keeping it to the minimum Initialize, Update & Terminate function as much as possible. Therefore in your main loop all you call is Update(); Main Loop.....s: Well I don't know how other people do this or if this is even good practice but I never have a single main loop. I have multiple main loops that are responsible for different modules. Going off my example above the Navigation Layer has a While loop with a state machine which checks which screen to activate based on the current state.. Then The code within that screen is called from the navigation layer just once and that screen has its own main loop which only gets terminated when that screen is exited or progressed to another screen. Therefore that while loop can manage everything involved with that particular screen. Now once a particular screen's loop is terminated we go back to the navigation layer which loops around and checks what is the current state based on what was done in the last screen and then it does the same thing as before. Unless the state is 'Exit Game' the navigation layer will call a ManageScreen() function which again will have its own loop. This way I can avoid having a tonne of state checks every single frame which is what you would have if you don't have many classes. Some more examples off the top of my head: Networking System: Connections Layer -> Send & Receive Layer -> Lag Compensation Layer -> Player Interface Layer (1 class each) Player System: Base Character Class (This one is to get inherited from) Player Inputs & Movement Layer (Inherits from Base Character Class) Generic Animations Layer Unique Animations Layer Targetting / Player Recognition Layer -> Camera Layer (This one is almost like a sub system Database System Database Interface / Reader Layer Content Factory (Holds all data on 3D & 2D content Assets) Animation Data Room (Holds all data on animations) Save Game Layer Game Settings Layer Key Bindings Layer Well... That is a rough as guts way I do it. Its hard to explain in so few words and without pictures. But I find drawing flow graphs of the structure is very important. Also with this method you have to pass class pointers or references through functions. Especially for the database layer because so many other classes need access to it and you only want to make one. Anyway hope this helps. Hope it makes sense. I struggle to explain it without pictures PS: You did pretty darn well considering you only had 8 classes. Its a lot better than many people on this forum will achieve. Keep it up. I highly recommend reading the Game Programming Gem's books. They are very very good at explaining these things.