Development Blog

Note this will not affect your game yet, since the C++ lib has not been updated.

Even though I'm on stable+pro I still really love seeing things like this.

Just curious did the old AnimationManager suffer from what you fixed in the new one? I still use the Lua AnimationManager since it's more flexible but if a change needs to be made there as well I'd be curious to what that would be.

No the Lua version is fine.

This report makes me very happy. Glad to see improvements. might give this update a look.

 

Also, the current Vectronic Demo on the game launcher has less point lights and smaller spotlight cones which may have contributed to the performance increase as well, but I saw very little improvement with 4.2.

Right now the beta branch of the game launcher has 4.3 and the default branch has 4.2, so it is possible to compare them directly side by side.

 

This update will make an enormous speed increase once it is all ready. The renderer is nearly 100% GPU-dependent. Everything in the game launcher is running at 80+ FPS, and in the hundreds for many games.

 

The exceptions I found are SpookmonGo and One More Day. I believe the first game has a ridiculously high poly count to where it's clogging up the GPU, and One More Day has a huge draw distance and could get a big speed increase if the developer set smaller models to have a shorter view range.

 

When 4.3 is released, your games will always run fast unless you are doing something really extremely wrong. It will be easy to keep games running at 90 FPS for Virtual Reality rendering. There's not much point in optimizing the renderer past that for now, because anything beyond that would only affect really specialized situations. The best overall thing I could do would be a multithreaded renderer using Vulkan, but industry support for that is a ways off.

Does the rewritten way lights and objects affect each other, include the water and light bug fixed?

if the developer set smaller models to have a shorter view range.

 

Believe me I have done this already to a great extent so little to no gains left there given the map layout. But I am looking at the map again (after long pause in dev) with the latest betas. I am experimenting with dropping the terrain size for the map to 512 from 1024 which also will reduce the navmesh and maybe this will push it up some more. If I can get close to 30fps on my low end rig I'll be happy. Great to see these engine optimizations.

Sadly I still experiencing hitching and jerkiness with the AI events map. (I'm using GTX970 and I72600k. Shouldn't be a problem with my setup.

 

Set the resolution to 1920x1080,window.FullScreen, Lighting quality to 2, vsync on, msaa=2

 

At the place where there is a decal on the floor, go near the stair and try to rotate( pressing A or D) while looking at one of the stair pole. Got serious hitching and jerkiness. Reported it last month to Josh. It felt like the stair is having an earth quake or something.

 

There is no way to actually record this since it will capped with 60fps while recording with shadowplay and the jerkiness is gone while recording.

 

One quick solution for me is in Nvidia control panel, set "Maximum pre-rendered frames" to 1. It almost solved the problem with leadwerks game or demo.

 

@Josh is there a way for you to implement this("Maximum pre-rendered frames") within leadwerks ?

Sadly I still experiencing hitching and jerkiness with the AI events map. (I'm using GTX970 and I72600k. Shouldn't be a problem with my setup.

 

Set the resolution to 1920x1080,window.FullScreen, Lighting quality to 2, vsync on, msaa=2

 

At the place where there is a decal on the floor, go near the stair and try to rotate( pressing A or D) while looking at one of the stair pole. Got serious hitching and jerkiness. Reported it last month to Josh. It felt like the stair is having an earth quake or something.

 

There is no way to actually record this since it will capped with 60fps while recording with shadowplay and the jerkiness is gone while recording.

 

One quick solution for me is in Nvidia control panel, set "Maximum pre-rendered frames" to 1. It almost solved the problem with leadwerks game or demo.

 

@Josh is there a way for you to implement this("Maximum pre-rendered frames") within leadwerks ?

If the framerate is high and the recorder isn't showing a problem this may be caused by your setup. I have never heard of pre-rendered frames. This sounds like an added-value feature from Nvidia that is causing problems.

Believe me I have done this already to a great extent so little to no gains left there given the map layout. But I am looking at the map again (after long pause in dev) with the latest betas. I am experimenting with dropping the terrain size for the map to 512 from 1024 which also will reduce the navmesh and maybe this will push it up some more. If I can get close to 30fps on my low end rig I'll be happy. Great to see these engine optimizations.

I know the problem has to do with too many objects or polys in the distance because the framerate dips when you look down that long street. It's running at 45 FPS now instead of 30, but there's no reason that map can't run at 200 FPS.

 

I also recommend lowering the draw distance. The size of the terrain doesn't matter, but the visible area of it does.

Nvidia pre-rendered frames causes stuttering on CS:GO:

https://steamcommunity.com/app/271590/discussions/0/611704730329043028/

For me , the solution for now with leadwerks is I have to enabled it in the Control Panel. If I disable NVidia pre-rendered frame, I will experience hitching and jerkiness while rotating and looking at something like the end of staircase. I dont have any problem with Doom, farcry or etc (with the nvidia pre-rendered frame disabled). I only need to enable it for leadwerks.

Nvidia pre-rendered frames causes stuttering on CS:GO:

https://steamcommunity.com/app/271590/discussions/0/611704730329043028/

 

That link shows about GTAV and actually the maximum pre-rendered frames =1 will fixed the stuttering.

 

Really odd problem. I only need to enable it for leadwerks engine. For other engines I don't actually have any problem like this.

 

Is it related more on input devices ? But still I dont have this problem with other games or engines. Only leadwerks.

Before I forget, frame cap or limit to 60fps also fixes the problem for me(without the max pre-rendered settings to 1)

 

I need to use MSI afterburner and set the frame cap or limit to 60. Even though I already have vsync enabled. My monitor refresh rate is 60.

If anything, it would be related to OpenGL, but then Doom by default uses OpenGL so I'm not sure.

I still hope or wish you would implement something like frame smoothing or targeting or something.

 

I have this game engine, it uses Opengl3.3 with pbr and frame smoothing and etc (It is really a buggy game engine). But even though the frame rate dropped to 45 ish, it is still really smooth and seems like fast. I think the guy implemented something called frame smoothing or targeting or something. I hope you will implement something like this in leadwerks.

 

I wont name the game engine because it is the forum rules. Correct ?

So basically you are saying that when VSync is off you have a highly variable framerate?

Vsync off does not fixed the problem. I got about 130fps while doing the rotating around the stair pole near the lift. It does shows multiple tearing. Which is expected ?

 

If I disabled Vsync and enable the prerendered to 1 it does make the scene look more calm and stable (it still is around 130fps at the same place), less jerkiness and hitching but the screen tearing is killing me.

Screen tearing is the effect of having vsync off. It is updating lines on the screen before the previous render is completed. I'm just confused about what you're actually asking for, because it sounds like you just want vsync enabled, which is easy to do.

I will try to record this with my phone to show it to you.

Seems like a failed attempt also. Anyway these are the videos

 

The one without max prerendered enabled

1)https://www.dropbox.com/s/838g0e48jetfocp/2017-01-10%2002.10.13.mp4?dl=0

 

The one with max prerendered =1

2)https://www.dropbox.com/s/p9lm6p7i6i4a88v/2017-01-10%2002.16.16.mp4?dl=0

 

 

I hope you can see that video one jerkiness. The stair yellow pole ? shake alot while I am rotating while looking at it. My monitor is also really dusty. Haha.

 

For video 2, it is still jerky but not as much. You wont see that much jerkiness in real monitor.

 

Anyway quick questions,

 

How come if my monitor refresh rate is 60, vsync is enabled, the frame rate is 60 but I still need to frame limit or frame cap my frame rate to 60 using msi afterburner to get a stable frame rate of 60 ? Shouldnt leadwerks limit itself to the refresh rate automatically when vsync is enabled ?

So when you call sync(true) the frame rate goes above 60? How high does it go?

It is average about 61,60,59. I'm using dual monitor setup. 1st monitor support refreshrate 60,59,50. My second monitor support 60Hz only. I'm testing leadwerks on 1st monitor.

 

I just tried it again with frame limit 60, vsync on, 1920x1080, fullscreen, msaax2.

The demo and gameplay is really smooth.. Sadly there is no way for me to show it to you.

 

Im using steam fps counter instead of leadwerks built in. The leadwerks built in counter changes too fast to read the value.

I don't know what "frame limit" is in your description above.

 

A measured framerate slightly different from 60 can be attributed to rounding error. Your computer's timer only measures milliseconds, and at 60 hertz each frame takes 16.667 milliseconds to render, so the measured framerate will be slightly off.

 

Everything you are describing so far sounds like normal behavior. The game will run smoothly at 60 FPS with VSync on, and run faster but with a variable framerate with VSync off.

 

If you want to artificially limit the framerate at some value above 60, or if you want a constant 60 hz without VSync, then you can just add a delay command in your loop like this:

local t = Time::Millisecs()
if lastrendertime~=nil then
   local elapsed = t - lastrendertime
   if elapsed<17 then
       Time:Delay(17 - elapsed)
   end
end
lastrendertime = t