Crazycarpet

August 16, 2016

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?

August 16, 2016

If I had to guess, it's related to this bug report.

http://www.leadwerks.com/werkspace/topic/14952-contextgetwidth-contextgetheight-no-longer-return-valid-info/#entry101257

Makes sense.

August 16, 2016

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++.

August 16, 2016

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

August 15, 2016

I don't know if it's something on my end, but I updated Leadwerks and rebuilt my projects now they both say the following error when trying to launch:

"The procedure entry point StreamInternal_CreateInterface could not be located in the dynamic link library".

I don't know if this is a bug or what... but any help would be appreciated. It had no problems til I rebuilt it under the new update on the beta branch.

August 15, 2016

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.

August 15, 2016

Thanks guys. Added it the C++ snippets. Its good to see some activity on the C++ front.

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.?

August 12, 2016

Have you thought about initializing the physics material the first time it is queried, if none is created yet?
PhysicsMaterial* GetMaterialPhysicsMaterial(Material* material)
{
if (material->userdata = NULL)
{
PhysicsMaterial* phymat = new PhysicsMaterial;
material->userdata = (void*)phymat;
}
return (PhysicsMaterial*)material->userdata;
}

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

August 10, 2016

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.

August 10, 2016

Great job guys, looks awesome.

Shadmar that water looks... wow.

August 9, 2016

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?

August 9, 2016

Thanks! That worked. It's still crashing when I try to implement it in the SetPixels example but I'll take a moment to try to figure that one out.

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.

August 7, 2016

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

August 6, 2016

1. Start this map as is, hit F11 and look at fps

2. Adjust billboard slider from 100 down to 10 or so. start map and look at fps.

If you untick billboards all togheter it's also faster.

I noticed this too, but in general I'm just getting poor performance on the beta branch no matter what scene I'm in, no matter how complex or simple... if there's shadows I'm getting bad performance..

August 6, 2016

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'.

August 5, 2016

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.

August 3, 2016

So I guess the stream:WriteLine() operation gets executed on exit?

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.

August 3, 2016

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.

August 3, 2016

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.

July 31, 2016

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.

July 31, 2016

You could also be a little more standard library friendly and use remove_if:

items.remove_if([] (item*i) {

bool isActive = (*i)->update();

if (!isActive)

return true;

other_code_involving(*i);

return false;

});

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.)

July 31, 2016

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.

July 30, 2016

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 +

July 30, 2016

Good point, overlooked the fact that one we remove the animation, the vector shifts all elements above it down an index at this point in the script. I prefer the first method because otherwise they'll all delete at once after and that'd be a slight performance drop... not to mention we'll save a tiny bit of memory by keeping Animation it's own class, and keeps the vectors copies when shifting smaller.

Also figured out jittering thanks to Josh, fixing now... will re-upload.

Edit:

*Big thanks to Josh for helping me figure out how to fix jittering, and the last of the issues in the AnimationManager*

Anyways, I cleaned up the code, used forward declaration, removed redundant checks, and this version should work out of box:

.cpp file: http://pastebin.com/PCfEBzW0

.h file: http://pastebin.com/fHRhPrvp

(My projects currently unusable til I generate a few toLua++ bindings and I can't test on it so if for some odd reason the above doesn't work, I fixed the links in my first post to contain a working version but if you use this version you'll have to make a few changes for it to work in your project, just minor things...

SAFE_DELETE(*it) would become delete *it. (You should know when it's safe to delete something reepblue!!

Puppeteer class won't exist for you, etc.)

July 30, 2016

Sleep's overrated anyways.

Also I updated the pastebins and changed the example so 'animationmanager' isn't allocated to the heap, but to the stack as a member of AnimationManager instead of as a pointer to the object just so no-one thinks we were doing it the right way in the example by creating the 'animationmanager' using the 'new' keyword. But yeah, now it's proper in the pastebins and it's all good.

Edit (bcus 2 ppl asked why it's better to make it a member over a pointer to the object):

-Since I made it so 'animationmanager' is a member of the PuppeteerAnimating class it's now both allocated on the stack (faster because it already knows where to insert the memory, instead of finding a place to put it where it'll fit) and it's an automatic variable which means we don't need to destroy it in the destructor, because it'll be destroyed automatically when it goes out of scope. (In this case when the parent, PuppeteerAnimating object is destroyed.)

-Because it's no longer a pointer, and now an actual member you have to access it using 'animationmanager.' instead of 'animationmanager->'.

-Stack allocation is much faster than heap allocation ('new' keyword, malloc, etc) because it's just moving the stack pointer, it already knows where to put the object in memory. Where as allocating memory on the heap it has to find a big enough block, split up the memory, keep information about where it's located, etc.

Not only is it much faster, but it also has to do with the lifespan of the object, this goes back to the fact that it's now an 'automatic variable' because it's a member. Memory that's allocated to the stack is destructed in the reverse order it was allocated in (so it's lifespan is the same as the scope it's declared in, then it's automatically destroyed.)

Memory that's been allocated to the heap (or free-store) has a lifespan you control, which should generally either be shorter or longer than the lifespan of the scope it's allocated in. (If it's the same, odds are you could be allocating to the stack instead and getting those performance gains and slightly lower memory usage! [no pointer]. Although when you NEED dynamic allocation you need it.. just if you don't, don't use it. [like when you don't know the size of an array you have to initialize beforehand.])

(^ in a nut shell, so please don't kill me about heap/free-store terminology, etc. It's just a quick explanation for anyone who was wondering why I changed it.)

Sign In

Blogs

Forums

Store

Gallery

Videos

Posts posted by Crazycarpet