Road Kill Kenny

LOL.. I think that should be the LE example game. Interesting to see that the majority of people so far want to make an FPS. In my mind that is the most saturated market requiring a high level of quality to even be considered by consumers. Also with my experience with FPS games on the mobile platform, the genre doesn't seem to suite the touch technology very well. Though thats just my opinion, each to their own I guess. What is everyone elses opinion on the matter?

I'll be doing one of 2 things that you haven't put in the poll: 1. Wait for high end renderer to come out 2. Port my current game to LE3 Haven't decided yet which I will do yet. Will have to wait and see.

Hmmm that must have been just before my time here. Though, I'll stick to my method for now.

Instancing is great! It improves performance drastically and it's almost like getting 100 pizza's for the same price as 1. However, there is one instance (excuse the pun) in which instancing is not ideal and that is when you want to have the same mesh to have different materials applied. Basically the problem occurs when you apply a material to one mesh in a set of instanced meshes all of those instanced meshes change material. In my Level construction set I have multiple pre-fabricated pieces and materials. As you may have seen I can apply materials to those pieces individually in the editor. Say for example I want to have a room floor with material 'A' but then I have a corridor as well using material 'B' but some of the same meshes... How do I solve this? I few thoughts came to mind and they are as follows. 1. Have Multiple GMF Files for Each Piece 2. Use Some LE Commands To Try Make An Un-Instanced Mesh Now I hope you figured it out for yourself that option 2 is the way to go without me having to tell you. Option 1 is a rather outrageous work around which is a bit like the epitome of ugly! So the next question is how do you carry out step two. Well I fished around in the LE wiki for commands that may help that I have never used before and I found just the right code for it. The algorithm is as follows: 1. Load the mesh from the file path - LE::LoadMesh() 2. Create an empty mesh - LE::CreateMesh() 3. Add the mesh from the 1st mesh to the empty mesh - LE::AddMesh() 4. Update the new mesh - LE::UpdateMesh() 5. Delete the first mesh - LE::FreeEntity() Although this takes a lot more than simply loading a mesh it is the quickest and cleanest workaround I could find for this problem. See below the function: LE::TMesh LoadMeshNoInstance(std::string meshPath){ LE::TMesh instMesh = LE::LoadMesh(meshPath.c_str()); LE::TMesh noInstMesh = LE::CreateMesh(); LE::AddMesh(instMesh, noInstMesh); LE::UpdateMesh(noInstMesh); LE::FreeEntity(instMesh); return noInstMesh; } PROBLEM: Now we have solved the problem of not being able to load un-instanced meshes but the global problem isn't solved just yet right....... right? Well no its not solved. You may recall the first line of this blog, "Instancing is great". We don't want to apply this non instancing loading functions to everything in the scene otherwise we will get horrible performance in run time and no body wants that! Basically the ideal outcome would be that every "same" object with the "same" material utilize instancing. For example, if you had 10 2X1m blocks with Material 'A' and 15 2X1m blocks with Material 'B', 9 of the blocks with material 'A' would be instances of the first block with material A and 14 of the 2X1m blocks with Material 'B' would be instances of the first block with material B. To solve this I will organize all of my blocks in a list. Each object has a type ID and a material ID which is inherent from my DDD system prior this problem. When a piece is to be loaded into the game it will look for a piece with a matching type ID and material ID from the list. If there is a match it will load the piece with instancing and if there is no match it will load the piece without instancing using the above function. This will add a fair bit of overhead but fortunately it is overhead in the load time of the game rather than game play time and, therefore, it is less crucial. The below image shows the result in my editor. 4 of the same piece with 4 different materials applied. Thanks for reading. Hope you enjoyed

Thanks guys. Yeh although not ideal you can make a fairly decent GUI with LE commands. A lot of this GUI is just using DrawRect() and DrawLine() with as few DrawImage() functions as possible. I like to stay away from the DrawImage because then it relies on external files. This works for this kind of editor UI but for in game UI you kinda need the textures and DrawImage()

You realize the actual terrain mesh isn't made in LE3?

lol

I've been working on this level editor for my game to go with the level construction set idea I chose to adopt for my level management. The below video is a Vlog showing my progress with the editor. The idea behind the editor is to reduce the rather impossible grunt work known as filling in a database line by line with data to create a data. I make the level in the editor and all that information gets saved and it writes those lines for me. Current Major Features Include: - Loading Levels - Adding level pieces - Adding materials to pieces - moving and rotating pieces around the scene Features I Still Need to Make: - Saving Levels - Adding Lights - Adding Spawn Points - Adding Various Types of Triggers - Adding level props - Adding Enemies & NPC's - Fixing a tonne of bugs. It still has a long way to go but it is starting to show its colors. Enjoy the video: GUI made with pure LE commands.

Tease tactics. I assume its coming soon but who knows how soon that is. I'm guessing anywhere between 2 weeks and 2 months. Though that is just my speculation. Only Josh knows when summer ends.

If the performance hit is smaller than the current decal system then why not

The only problem with my texture with alpha is when I put slopes into my game it will look wrong so I'll have to find some work around for that I guess lol

Yeh Windows 8 is actually pretty good imo. Works for me and despite popular belief and speculation it is not the end of gaming for windows.

To project a texture you paint a light with a TTexture. i.e LE::PaintEntity(light, texture) In my game I simply have a texture with alpha. I parent that to the characters mesh and it seems to work pretty well. There are decals but they have some performance issues atm and I think a light projection would also be an unnecessary performance hit as well.

Supporting XP now is like supporting Win97 when windows 7 came out.

I would suggest preparing Leadwerks for the future, thus making a high end renderer for it. If the Android and IOS tablets and phones are getting so powerful as to open up a new market we are going to need it to be a part of that market.

Same... the camera kept getting pushed down whenever i tried to look up + the controller was moving in 1 foot jumps rather than smoothly even tho i had decent fps

wtf seriously? This is what you consider the best thing ever?? I mean don't get me wrong it's cool but I can think of many more important features in LE3... automatic path-finding for one.

I never use it. Defeats the whole point of having namespaces in the first place. But Its just a matter of preference really.

Thanks guys. Currently working on the editor. Very fun, very excited cuz I'll be able to throw my bro(artist), or anyone really on the editor and, without having any programming experience, he'll be able to make full levels for my game with full interaction between objects and AI etc. etc.

As long as the forces you are applying are in metric and at the correct scale then yes. So for example a car of 900 mass would need a decent force to make it go... Just like in the real world.

just lol

I would also like to point out that a lot of people scream bugs when they don't realize that the bug is in their own code and not the engine. More often than not things don't work right because of a lack of understanding about how it works. There are only a few people on here that I actually believe when they say there is a bug. Buy it or don't. We don't really care.

Hi All, Currently I am working on making my level building in my game much more diverse and easy. Formerly I was having to create custom models for each room in the game. This worked but was hardly efficient, very time consuming and did not leave much hope for the end user to create and share levels either. So I set off to kill two birds with one stone: Make a level building system & editor to streamline level creation in my game Make the editor easy to use to open up the possibility of the end user gamer being able to make custom levels using the pre-made building blocks. So the idea around this whole system is to make lego blocks, The lego blocks get constructed together in any different way specified by the user to make a level and the user can simply slap on any texture they want. This will make level building very fast. There are a number of things that were musts for this system in my eyes: Data Driven (of course... did you think I would do a blog without talking about that...) Utilize unit lengths and snapping (no decimal point dimensions & positions) Optimize UV's so that the pieces can utilize different materials easily (sort of like creating a standard for Level part UV's that all pieces and materials must comply with to work) So with out further ramble, please enjoy the below video that goes through the process of me exploring this. This is part one of 3 which I will show in separate blogs. Problems Encountered: 1. Origin of Level Pieces At first I thought that putting the origin at the center of the pieces would be a good idea. However, this turned out to be the worst idea ever as it totally screwed up the unit length idea. For example you have a 1X2m floor piece, if you put the origin in the center the origin is at 0.5X1 <-not unit scale... At first you may think this does matter but it does. consider placing a 1X2 piece next to a 2X2 piece. if 1X2 floor piece was at position (0,0,0) then the 2X2 piece would have to be at position (1.5, 0 0) otherwise it would overlap. see image below: So to solve this I put the origin at the very corner of each piece with each piece extruding out into the positive X Y and Z directions as shown below. Sure it was a stupid mistake but an easy one to make. 2. There is no problem number 2 Whats Next: The next thing I will be doing is creating the editor. This entails a bit of windows programming. I don't want it to be like the HAARP editor I made. I want it to be nice and easy to use for just about anyone who would play my game. It will be using proper save and open dialog boxes and other such Windows utilities to make it familiar. I will blog about this next time.

In my game I take pretend every unit is 1m.

Well I've consulted the Command Reference Documentation in Leadwerks for meshes and found AddMesh(TMesh src, TMesh dst). Not a function I've ever used but may work if it works how I think it does. http://www.leadwerks...es/addmesh-r308 So from what I gather it adds the data of one mesh to the data of another. I'm not sure if that includes UVs (but I hope it does). So perhaps I can just make it so that when I have the same mesh with a different texture I can just Add the mesh from one to an empty mesh (which is created with CreateMesh() and then paint it different. I have no idea if this will work though because I don't know the nature of the function but we'll see. Here's a question for Josh. Am I likely to have this same problem in LE3 or does it work differently in LE3?