TheConceptBoy

Any chance you will look into emissive texture maps casting light as well?

Come to think of it, I don't know if they are. So far this isn't a player class, its just some code in the loop I palced in main.cpp bool main(){ while(true){ // player head bob and other player stuff } } I don't know if the while true is perhaps a suitable place for placing these sort of time critical things? That is where the player head bob code currently resides. Perhaps that is the cause of that particular issue and I should be creating a player class from the Actor and programming the head bob inside of it's world update function?

More yes. about 15 instances before the performance hit is bad enough to notice and bad enough to complain about if you paid for a game that ran like that. I'd really like to say it's due to my old hardware but at the same time a large part of my Steam library plays fine so. As the matter of fact. I can have a pretty packed level of static objects that run just fine. Add a few actors (since this is a zombie game) and it grinds below 15 fps. Engine should really be able to provide way more head room than than I believe. I have to experiment some more.

I guess no spawning hordes of zombies for me then. Gotta use the resources sparingly. Puzzle games and tough enemies it is.

Enemies are spawned as models too though. The only place where I use entities is when I look through the world entity markers to place enemies on those markers. And that only happens when I press the keyboard key

So do you use context and drawing variables as GUI items and widgets to the game context to debug?

Well actually notice how even as the frame rate drops the hand sprint animation pretty much stays the same? Notice the head bob starting way too fast than what I based it off in the debugging (close resembled when I spawned some entities.)

2019-06-26 22-00-15.mp4

As the matter of fact, the more Entities I add, the slower my time critical counters are operating, Like camera wobble that uses wibble = sin(wobble_time) however my player movement speed stays the same, as if internally compensated by delta time. This is bizarre.

Just ran in release mode. Got the same result as you two, suddenly can spawn hordes of these things on my 10yo machine. What in the name of optimization is going on here? @wadaltmon lmao if Janko was here he'd have a stroke... Also things like timers and counters are totally wrong in release mode, some are too fast. So Debug mode can't be relizably used then, otherwise I'm gonna have to re-code half of the game's time critical events.

Thanks for the suggestion. How do I disable debugging mode? Also what is so horrible about it that impacts the performance so much? Is it the Print to console commands?

Makes me wonder indeed. An old game like L4D on this very same machine could handle dozens of zombies so I wonder what's happening under the hood that's making them so expensive.

yes, these are rigged models. Is there another way to animate characters that I don't know about in LW?

Further testing with leadwerks. I've got to be doing something wrong here. If you press "E" you will create instances of an enemy object, they will be positioned at the T pose character models. There is also a 3rd character with an Actor that is used as the starting template to be Instanced from. There's absolutely no code inside these Actors and yet 6 barely objects in and the performance Tanks. I was looking to spawn anywehre betyween 15- 30 of these Would anyone mind taking a look? I've removed pretty much all objects, effects and anything that could possibly cause this. Some forum posts did say they that for repeated objects you should Instance them, which is what I did. GTX 750, Core 2 Quad Q8300. 8GB of RAM. Any other project test I've done in leadwerks, so far ran like butter. But this one, that involves Actors is severely laggy. I've got to be doing something wrong with handling actor instances. PS: This is a C++ Project so make sure yo Consult the Visual Studio Solution. EDIT: I have uploaded an updated project (Overrun_2). I speculated that the tanking performance could be due to the collision objects getting stuck inside one another and the collision solver is getting overloaded. So I've added a little offset to make sure NO instances are created inside one another or inside the dummy placeholder mesh. Unfortunately still the same results are observed. Overrun.zipOverrun_2.zip 2019-06-26 14-43-25.mp4

Ok, just found the reason why it wasn't workign so I'm posting it here for discover ability. The reason it worked first and did not work after is most likely because my naming changed in Blender and when I re-imported animations for the gun into Leadwerks, it couldn't find the right bone to play the animation for. Now these two answers have helped: So basically what I did is First Play the whole arm gun animation and then play the single bone animation. pistol_9mm->PlayAnimation("shot", 0.05, 0, 1); pistol_9mm->PlayAnimation("shot_b", 0.01, 0, 1); shot_b is the chamber of the gun moving and shot is the recoil animations for the whole wrist. The chamber and the wrist are a part of two different rigs in Blender. One is parented so that when the wrist moves, the chamber moves with it, but that apparently doesn't mean that when you play the wrist animation, the chamber will play it's animation too. Only if both the gun AND the wrist are made from the ONE same rig with all bones connected to the same root, is when you'll get all bones playing the same animation all together. Now from what I've interpolated based on the above mentioned threads, If you DO have a single rig for the entire mode, like a zombie that can play the run animation with the lower body and either a sprint or attack animation with it's upper body depending on the proximity to the player, then you will have to actually find the specific parent bone that starts the upper body and call it's animation like this. wholeBody_Enemy->PlayAnimation("sprint", 0.05, 0, 1); wholeBody_Enemy->FindChild("upperBody")->PlayAnimation("attack_swipe", 0.01, 0, 1); So you want to find that first bone that starts the upper body set of bones and fire an attack animation only for it.