Crazycarpet

I was just finding ways to optimize my project on a blank one while I'm waiting for the Context fixes.. and I noticed something, by disabling some settings on bones you can get pretty decent FPS gains... any reasons why I shouldn't run any of the methods selected in the screenshots here? http://postimg.org/gallery/3c0l909gw/ (Average FPS outputted to console in screen-shots, showing which ones have bone setting changes and which ones don't in the screenshots.) They still seem to draw their shadows and handle collision properly, just get a nice FPS boost... This is a freshly created project with nothing other then an average FPS counter and the code to change bone settings in the map callback. Also, does anyone have any ideas as to how I can make this automatically happen to bones whenever they're created by the engine?

Makes sense.

In my C++ project the following crashing on the 'GetTextWidth' line, during the following code in my App.lua after updating my project: //Create a context. context = Context::Create(window); System::Print("TESTING"); //Makes it here, then crashes. //context->SetFont(Font::Load("Fonts/Arial.ttf", 36)); //When uncommented, makes it here, then crashes. System::Print("Size: " + to_string(context->GetFont()->GetTextWidth("gfdgdgfdgfd"))); System::Print("Made it here!"); System::SetProperty(PROPERTY_MOUSESENSITIVITY, mousesensitivity); I'm wondering if anyone else is having issues with GetTextWidth (In C++ only, works in Lua for me...) or if this is just a me thing. I added that test code because BEFORE I added it GetTextWidth was crashing elsewhere in my project. I find it very weird that this only crashes the app when called in C++.

Yeah that does look great, hope that comes in an update soon.

Give me a few minutes, I'll post some screenshots its a fresh project. Edit: here's the map file since you wanted that instead. https://www.upload.ee/files/6069655/start.map.html Edit#2 since you think I'm lying to you about FPS numbers -.- : -1 Crawler http://i67.tinypic.com/6ibb6h.jpg 742 FPS -2 Crawlers http://i67.tinypic.com/174fty.jpg 580FPS -3 Crawlers http://i65.tinypic.com/2n8v3u0.jpg 369FPS -4 Crawlers http://i63.tinypic.com/8wk47p.jpg 350FPS -5 Crawlers http://i64.tinypic.com/33cyah2.jpg 270FPS. -6 Crawlers http://i67.tinypic.com/2432gdg.jpg 216 FPS -7 Crawlers http://i63.tinypic.com/2mgtwrq.jpg 162 FPS So as you can see, I'm not lying to you about the numbers, don't know why you'd think I'd make up FPS numbers... -.- I'm not complaining about the performance it's fine, I'm wondering why it starts out with such immense drops.

Thank you! Animations were the only thing in LE eating my FPS... can't wait to see if there's a noticeable FPS boost. Edit: Gained a solid 20 FPS on a scene w/ about 10 crawlers. Couldn't be happier, gained tons of FPS in my actual test scene. 0.o Although (of course) animated NPCs are still the most expensive thing in my project, drop about 25-60 FPS per crawler. Is that normal? FPS: -7 crawlers, 180 FPS. -5 crawlers, 300 FPS. -2 Crawlers 750 FPS. Tested on a new project w/ a 1024x1024 terrain, and a hollowed box containing the crawlers and the player inside.

Are you not able to check if they collide with the door? then stop them. I'd recommend keeping the 'pick' too... there's probably a quite simple way to make the pick alone detect the door every time, but I just woke up and I'm too lazy to think about the simple math involved... maybe later.

Fixed a simple bug that was caused by a Lua work-around not needed in the C++ verison (--n;), can you re-upload if its not linked to the pastebin directly.?

That's the work around I ended up doing... I just feel like it'd be nice to have these hooks regardless.

So if you want to know your first and last block, and make sure ones at one end, and the others at the other end. Do something where you'd randomize the X and Z positions of each block (left/right, up/down) BUT for the Y axis, calculate the next block's position based on the (blockCount * distancePerBlock) then you'll know it keeps moving in one direction. (You can even add slight random offsets to the Y position after you do the (blockCount * distancePerBlock) calculation to determine the next blocks y-axis position.) Otherwise you're just looking for the block in the furthest direction each way.. there's no guarentee blocks won't spawn in each other and that you'll be-able to get across them. Edit: I forward in LE the Y axis is up/down and Z is forward/back for some odd reason. (Turns out I just live under a shell and this is pretty common in games.) Untested and not-very thought through but heres an example showing what I'd do: http://pastebin.com/7eScHecb In the future you may even want to make the offset's scale based on the 'box' size and what not just so you can have a really dynamic, easily customization obstacle generator.

Great job guys, looks awesome. Shadmar that water looks... wow.

Looks pretty slick.

I know this'd probably be a pain to implement but I feel like it'd be a really great hook to have... The problem I'm facing now is I'm trying to attach a "PhysicsMaterial" to every Leadwerks::Material that's created, and right now I just use PhysicsMaterial everywhere instead of Material and the methods in PhysicsMaterial create the Material... but this is kind of a head ache, and not so Lua friendly.. I was wondering if it would be possible to get an Object::CreateHook because it's make life easier in so many situations, and it'd be a great counterpart to Object::DeleteHook... It'd be nice because then I could just create my PhysicsMaterial on this CreateHook for the material and that'd be that, instead of this big, headache of a class that makes creating materials in Lua a headache til I expose PhysicsMaterial through toLua++... I just feel like in general it'd be a great hook to have in so many systems... especially because in things like Materials, many entities may share one Material so I can't create my "PhysicsMaterial" when the entity is created. It'd be nice to hear back on this from you Josh because if you're planning on adding it I definitely want to put my project on hold as this would make life so much easier in the future. Edit: -Another problem w/ the way I'm doing it now is I have to do a sloppy hack spawning a huge box to change what type of material every LE entity and collapsed brush that's created in the editor uses... -I also don't know how you'd implement CreateHook since like.. it'd have to be global and not object specific (because we obviously can't object->AddHook() when there's no object) but something like this would be so handy... I guess the hook system couldn't do it but if you could think of another way to implement this it'd be so amazing. A callback like this is literally make-or-break (work-arounds working pretty well) for people who want to make robust C++ games, because otherwise we have to have tons of hacks every time we have a situation like this where we want to extend the behave of an LE object type. I'll try to post an example of a situation where this'd help later... basically the problem right now is we need to implement seemingly unnecessary hacks (that could be avoided with a callback) every time we want to extend the behavior of LE object types, and in turn this really limits the type of projects that can be made in LE But again, I do realize this'd be a pain to implement in a neat, working manner because we run into all kinds of issues like what type of object is it, etc.. maybe LE would benefit from some form of global-hook system? Physics Material Files for info on how we're extending "Material": http://pastebin.com/HZBfZGi6 http://pastebin.com/twVLUPWG Again! I know this would be a pain, but it'd make LE Objects so much easier to extend, right now its SUCH a headache. I really feel like LE is too focused on Lua, to the point where it's next-to-impossible to make a pure C++ project that is unique, and robust... this simple solution would make all our C++ problems go away! we even have our C++ entities working w/ the flowgraph editor (thx reepblue)! This is the last problem (to my knowledge) we need to conquer. Edit2: Why can't we just have some global hooks thru System::AddHook for creation of LE objects?

I noticed when implementing a system today that even on some surfaces GetMaterial() returns null.... So I guess some surfaces simply don't have materials on them, just check and make sure 'Surface::GetMaterial() != NULL'. I noticed this in a similar situation, when I was relying on the fact that Surface::GetMaterial() never returned null, when in fact it does in many cases so I had some crashing til I did a check to make sure the returned value isn't NULL, now I'm getting the expected behavior.

Is a torus not a doughnut shape? Pretty sure it is.

Sorry not going to be by a computer for a few days and i dont have Animationmanager.lua handy so ill show you the arguments for the c++ animation manager. void SetAnimationSequence(const std::string& pSequence, const float pSpeed = 1.0f, const int pBlendTime = 500, const bool pMode = false, func_ptr pEndHook = nullptr); (Ignore endhook because that arguments different here, but up to there its the same on the Lua version (except every numeric type in Lua is a double.).) Try: Self.animMan:SetAnimationSequence("attack", 0.4, 500, 1) So that'd be speed of 0.4 blendtime of 500 and a mode (repeat or not?) of 1 (Don't repeat). Right now your blend time of 0.5 seems really, really low... And im not sure if 'mode' defaults to one or zero. Edit: Just checked before leaving for the weekend... in the Lua AnimationManager 'mode' defaults to 0 which is repeat mode.... The line I pasted above should w/o a doubt work. Although are you sure self.model is the entity you're meaning to attach this to? and not 'self.entity'? I'm just saying this because it looks like you're meaning to attach your script to an entity in the editor, which would then make the visible object you see in the editor 'self.entity'.

So I'm suggesting this because reepblue and myself have systems that both use large, physics-less,, invisible entities as triggers and it works great... minus one thing, when building GI thinks look really messed up. We were hoping in the near future we could get something like a flag for materials to prevent this issue, and other issues alike when building GI.

Pfft, it'll be even MORE perfect more MY dev console Read only text-viewer widget + text input widget under it = <3 Also, Josh does this just add the scrollbars at the start or does it not create scrollbars until they're needed?

Without reading to far into this, my first question would be are you running this code under your main loop? "while" loop...? That'd explain why it'd run on program exit, when we break out of your main loop it'd finally beable to reach this code.. although I could be very wrong cause I just skimmed through your problem. It is very possible to save and load in the same session, and should be very simple... if you want help with this I'd need to know more about how you're going about doing this. Feel free to send me a forum PM or through my page add me on Steam... This shouldn't be too hard to get working. Keep in mind that FileSystem::WriteFile creates a NEW file and writes to it, or OVERWRITES existing files, to add to a file that already exists use FileSystem::OpenFile and FileSystem::WriteLine, you could even do a check to see if the file exists before trying to open it, and if it doesn't, create it. What you have there should work assuming the code's being executed properly, so I'm going to assume maybe I misunderstood and you're not wanting the existing contents of the file to get overwritten? here's an example of that: if window:KeyHit(Key.F1) then local path = "test.lua" --Because I'm too lazy to re-write it over and over. if FileSystem:GetFileType(path) == 0 then self.test = FileSystem:WriteFile(path) --create file, doesn't exist. else self.test = FileSystem:OpenFile(path) --Open file, because it exists and we just want to add to it. end self.test:WriteLine("Test") self.test:Release() end From the looks of your code I'm assuming you don't want the stream to stay opened, so that's how I wrote the example. Also, unless you're writing code to this file it really doesn't have to be a Lua file.

I'm confused as to what you're asking? By seed do you mean you have a given 'x' value already, and you want to generate a new one based on that? local x = 250.0 -- For example sake lets say this is our already known x value local offset = math.random(-25.0, 25.0) --Now we generate a random offset between -25.0 and 25.0 units. local x2 = x + offset --Add our offset to our x value to get our new x value (x2). Is that kind of what you're trying to do? or? Keep in mind if you're using this to generate positions to place physics objects you should be doing something to make sure this newly generated position is within the world boundaries and not under terrain like a hill or something... which is why you'd choose a suitable max and min offset for your math.random offset generation. You may be able to do some kind of AABB bounds checking to help ensure it's not going to intersect with other nearby entities. Just make sure you compare them as if they were both boxes to avoid situation where the position of the new entity isn't intersecting, but the max or the min boundary might be.

Just make sure you post this one: .cpp file: http://pastebin.com/PCfEBzW0 .h file: http://pastebin.com/fHRhPrvp The other ones dependant on reepblue's template.

Weird on two of my computers it's on and another LE user told me it's on by default which prompted me to suggest this. We must've done something to enable this or something... This can be closed then.

Yeah that's a really handy feature many people don't know is even there. In the new examples we switched to range based loops or I'd definitely be using that. (We didn't update the code in the original post, sorry.)

I just thought of this after discussing Blueapple's performance problems with him, and helping him try to fix them. .. I noticed that like many others he had shadows enabled for his grass venation which of course leads to a HUGE shadow poly count, and performance issues... I think for convenience this option should be off by default. Apparently this is just a me thing and it's already off by default.. this can be closed, lol.

You guys should really focus more on finishing your stuff then optimizing though or you'll drive yourself mad. Leadwerks is more than capable of producing performant games. Even on a complex scene where I can only get ~100 FPS (I have a pretty powerful PC) it doesn't matter what else I throw at it it'll stay around 100 fps and that's what I love about Leadwerks and it's deferred rendering. But yeah entity-count does seem to be one of the biggest bottlenecks in LE. Also I noticed my NVIDIA card tends to fight sometimes w/ v-sync enabled... nothing crazy but when I limit FPS in other ways I generally get significantly better performance. And my PCs with AMD cards are just **** in general on most modern games.. (never buying an AMD card again -.-). I think it's worth trying to run your application with v-sync off and then see what kind of FPS you get... I bet you it'll be higher, even though I think in theory it shouldn't be. EDIT: Disable shadows on your grass! big no no. So incase anyone has performance issues last I heard from Blueapples: -He disable grass shadows for a huge shadow poly drop. -He removed his post processing shaders. -He disabled v-sync. -He re-enabled occlusion culling on his entities. Now he says he's getting 80fps +