Sorry your browser is not supported!

Sometimes I run my new game and after a few seconds fps drops by around 5-10 frames. The weird thing is that sometime it doesn't happen other times it happens.

What I do to test this is running with my character on a boat (not too big, something like 7-8 meters by 50), the fps usually do not change more than 2-3, depending on the rotation of the player, but with the time it drops.
For example: I walk for 30 seconds and get around 46-48 fps, after a few minutes the fps drops down to 38-39 for no reason, the boat is standing so the polycount is the same.
I have still to figure out why this happens randomly, sometimes happens, other times the fps are stable even after walking for 5 minutes.

Does anybody knows if there is a bug in the advanced lighting system by Evolved or dbpro itself that can cause fps drops?

I have recently also discovered that some "flickering" and "inaccurate light rendering" can be partially fixed by highering the near value of the drawing camera, from 1 to 3.
If I try to higher this value above 3 I get a blue screen and nothing rendering.
I have also tried to lower the far value of the drawing camera from 64000 to 32000 but the fps are the same, and highering it to 128000 makes a weird artifact where the camera ends to draw.

With regards to fps drops - does this same issue occur with the unaltered code of advanced lighting?

Yes it was the same even with near draw distance kept to 1

Hmm odd, I haven't experienced that specifically with Advanced Lighting as of yet. A few years ago though I had the same issue with anything I compiled with DBP which I couldn't understand at all as even the simplest of code would be affected, it went on for some time, inexplicably the problem would be sporadic - sometimes it would play nice, other times it would occur in the same way you describe - every other compilation. At one point I was convinced it only happened when I compiled and if I ran the exe separately from compilation(ie compile first with F4 then double clicking the exe to run it) , but found that days later it made no difference at all, almost like I was imagining it, I found it to be infuriating! Anyway as I mentioned it went on for some time - a matter of several months and sort of seemed to get worse as time went on. At some point midsummer while playing Oblivion(which used to drain my machines resources) my machine lost power and I had to replace the PSU. To my surprise after replacing the PSU the problem vanished! My only theory is that running DBP at the fastest refresh rate is basically asking the machine to consume as much power as it can, therefore bringing the PSU to the end of it's life much quicker than expected. With my last machine I used to play a fair bit of BF4 which also used to drain resources and so would be playing at frame rates sometimes as low as 30fps, again one summer suddenly BF4 started giving me frame rate drops down to crawling speed then come back up to normal rates once again quite randomly. I tried every software/bios fix known from the forums to no avail including fresh OS installs. I was starting to accept the fact BF4 was just really buggy with older hardware not being accounted for in forced updates, but by the end of summer the PSU packed in mid game, replacing it fixed the issue.

Of course this may not be what your experiencing, borrowing a new PSU to test with might help. One other thing I have noticed with various terrains - advanced terrain, memblock mesh terrains and blitz terrain along with Evolveds older terrains, was that you get a largish fps drop nearer the center of the terrain depending on how big it was and the fact my hardware was feeble at those times. Other things you might consider are other processes going on in the background. For example on windows 10 at least if I run a DBP exe in windows mode and just leave the mouse/keyboard as idle, after a few minutes defender starts an auto hard drive scan which sent the cpu up to 100% when it starts scanning its own directory and also an auto defrag starts to take place at roughly same time, sometimes just one runs other times its both.

All these things when taking into account what performance your hardware is capable of could be the reason, the fact your getting such a low fps suggests at least your graphics card is struggling with Advanced Lighting, perhaps its failing due to all the strain its been put through in the past. Perhaps a recent graphics driver is to blame. Really difficult for anyone to say I should think given that there are so many parameters in play and we know nothing of your hardware or software setup. I can't say I have seen any posts in the forum mentioning this fps drop your experiencing and for a long time I have checked the forum daily , mainly the DBP, bug reports, WIP's, program announcements and geek culture boards. So to me it suggests the issue is specific to your machine at this point, unless of course others reply here confirming the same issue, but your definitely right to ask about it, after all how else would you find out lol. If you have access to other machines, a friends perhaps, then maybe you can try it on that/them to see if the issue is the same there. Best of luck narrowing this down though, let us know how you fare over time.

Thanks for the info James.

I do not use Advanced Lighting, but I very much experience the odd frame drop from time to time. After a number of tests performed over the years, I have found that performing the standard sync call in a loop does not yield the best performance.

This may be irrelavent for advanced lighting, since it is not a system I am fully familiar with; although I use some of Evolves other assets and tools.

The following paradigm can be proven valid if you take a look at the AL update functions; which may help you find the cause. AL does not run that fast on my machine either; it looks good though

Firstly, the standard approach of calling sync in an unconstrained continuous loop will run an update on all of the entities and processes within the DBP engine, including calls to update windows events, object interactions, render sorting, limb frustrum culling; the lot. That may not be what you want to be performing all of the time, which I will now explain.

Depending on the type of game, you may not need to call the full sync hardly ever, or perhaps just a few times per second, it may be better to call FastSync most of the time, which will only focus on the rendering I believe.

If none of the shaders in use or the shaders visible from the camera feature animation, you can get away with just one call to sync or fastsync, then hold the frame; at least until something moves. This has the potential to free 99% of your processing resources for game mechanics; so if it is viable to organize your entities to determine which ones require the sync and which ones do not, while the player and all objects in the view are stationary, you can provide the max FPS. Nothing special for certain games, but for others which perform continuous calculations for AI or object loading, this is a plus.

Now, for when things are in motion and your game permits, you may only need to draw such moving elements 20 to 60 times per second with Sync or FastSync; and you can do that without hindering the playing experience by performing non rendering updates as many times as you like, so as long as you only draw things as often as they need to be drawn. Using a multicore physics systems like PhysX and the Dark AI multicore system is a good idea, this means the game mechanics can be handled with the DBP App's CPU focusing on running AL.

So in the case of my game, I only call sync/fastsync when it is necessary. You can still query the moving objects and perform collisions without sync calls, thus process game mechanics.

Finally, a few calls to Nice Sleep (Matrix1) or the Windows API sleep (Not the vanilla DBP sleep) can cool down the CPU and free it for the operating systems own rendering of your game window and its event system. You can call the sleep command perhaps 1 to 10 times per second depending on the type of game; calling sleep every loop will likely slow things down too much.



The point of this paradigm is that the best frame rate possible is that which calls Sync/FastSync less often. This also makes the use of the Screen FPS command as a performance tool redundant, since that is simply the amount of screen renderings per second, not the amount of update frames per second. If tweaking the pipeline, you'd have to make your own FPS calculation based on the amount of game loops, not the amount of sync calls.


That's my two cents.

The Advanced Lighting system already sync in his functions, I prefer not to change anything in that code or I will end up having 100 bugs just to fix 1.

Chris - Some very good advice right there, if I had even tried to explain just a portion of that you would be reading an essay that made little to no sense at all lol, very well worded indeed. Kistech did provide a snippet somewhere entitled something like "decoupling the display loop from game loop" which ties in with your explanation.

With advanced lighting the update function is definitely what takes a hit in performance significantly, it may not just be the fastsync calls to a large number of cameras that lets not forget duplicate draw calls more often than not - but I seem to recall at least on an 8800GT I used to have that usage of commands that pass data from DBP to shaders such as set effect constant also impact performance significantly and there are a fair number of times that those commands crop up in his update function's code, how often they actually get utilized I am unsure of right now, but I have at the least a mild suspicion they may play a significant role. If they do I suppose there is the vaguest of hope that a plugin with faster versions of those command may be plausible but that's way way beyond my meager knowledge/capability. To make changes to the source could be viable as well I suppose but again beyond my capability and I think there was a dynamic cube map command used(possibly dark shader) that the compiler would not recognize in advanced lighting code(GitHub source). You will also get false data with regards to draw call count and poly count with native commands so that's something you have to keep a record of yourself.

Cescano - you should bookmark this page and at some point in the future when you feel up to it you should definitely review what you can so as to let the info sink in.

You are right about the polycount, it show less tris polygons than the actual ones.
When I will do more tests, I will definitely update you guys, as I Always did (like the post where I discovered how to get the public IP to make a proper matchmaking (php + dbpro provided), while nobody have been able to find a solution, or the memory leak with the append object command, and many more).
I wish Evolved could have fixed all the bugs in his advanced lighting system, because it provides stunning graphics for a directx 9.0c engine, and it is the only reason why I am making my new project with dbpro still, and not moved to UE4 for example (I would need to study C++ and I cannot wait 1+ years without making any project).
When I first saw the AL I thought It could not be usable to make a commercial game because I was having like 40-50 fps without adding any object, but working with it I have discovered that if you add things they will not slow down too much the fps, not like adding the same objects in a project without the AL system (in %), so for some type of games that do not require too many objects (something like gta style) it is still duable to make a game with it, if you know how to optimize things.
It also provides some graphics tweakings to adapt the game to your pc specs, so for example with my new project I have like 35 fps with graphics maxed out, 50 with normal and 80 fps with low settings, which is fine for a laptop running a nvidia gt635m.

What I still need to figure out from this AL system is:

- Fixing the black screen bug on resolutions higher than 1024x768 (I have contacted Evolved about it but he never replied)
- Fix this fps drops

I also had problems with objects flickering and inaccurate light rendering (I don't know how to explain that actually), but I have discovered that changing the near draw value from 1 to 3 fix the flickering problem and partially fix the inaccurate light rendering.

Problem spotted.

This time the fault is not DbPro and neither the AL of evolved.

I have analized my gpu temps and clocks with the software GPU-Z, it appears that after a couple of minutes my gpu reaches 93 degrees, from that moment the clock is capped from 661 Mhz to 535 Mhz, that makes my fps to drop from aprox 47-50 fps to 38-43 fps. GPU-Z clearly states that the reason of the cap is Thermal.

The good news is, I have nothing to fix on my code, it works perfectly then.
The bad news is, my notebook is not working fine and I might need to open it and clear some dust (hoping that is the problem).


Anyone found a solution for the black screen problem instead?

After cleaning the fan the temp stop to increase at 82 degrees, and as the performance cap starts at 90 degrees I have no more fps drops.