Sorry your browser is not supported!

... what could be causing this?

at first i thought it might be a memory leak, something i might've been doing continuously with memblocks... but after searching through the code for the past few days, i can find nothing...

the app starts out at 47 fps, then after about 4 minutes, the frame rate starts to get lower and lower... down to 39... then 34... then 29...

any ideas...

thx

--Mike

Hmmm ... I hate problems like this. Clearly I'm flying in the dark here as I'm not familiar with your code Mike but if your code looks ok might be time to start putting some careful timing checks into the game loop to ascertain whether the slow down is actually in your code or elsewhere. Something that came to mind was the possibility of the graphics card memory getting full and being forced to start paging to your system ram cache. If it is in your code then the timing checks should help track down what's causing it. If your using OOP then creating a series of global variables, one for each class, which are incremented in the constructors and decremented in the destructors should be an easy way of checking for orphaned objects.

Good luck!

yes... good idea Pix... gonna run down this path for a while...

thx

--Mike

@Pixel Perfect - Good ideas!

@Red Ockober - I think Pixel could be onto something with the vid card - because - currently I'm creating terrain etc - and Some sizes - culled or not - Make the FPS TANK - like if I do a 6x6 tiled terrain (64x64 vertices) but if I do 3x3 tiled terrain with the same (64x64 vertices) the FPS is AWESOME ... until I turn on the 100+ ghosted clouds and water shaders (Finally decided on this 3x3 config- needs to run ok on my machine at least after all)

THIS is SO much cooler than DarkBasic though for big projects! Though I wouldn't trade in my DarkBasic for anything - still use it to "try stuff".

Another problem that can occur, is if you continuously create objects and then set them to invisible after a certain amount of time. Although they not being shown any more, they do chug the pipeline a bit. One way I've managed to find, is to cache large numbers of objects to be deleted and then delete them every 5 or 10 objects collected. i.e. bullet objects which are cloned and destroyed in large numbers.

Paul.

@APEXNow - That is a neat way to do it. Kind of your own Garbage collector

I use a different approach - and not because I think its better than yours APEX or anything like that - in fact - I Don't know the BEST way to deal with this admittedly - however I have been warned by various posts in these forums as to how DBPro suffers if there is a lot of Deleting and CReation of Objects - where it eventually just seems to slow down over time. This is bad. (I see enough similiarties with DarkGDK and DBPro - to think they ride on same basic code underlying code - so I take comments from both DArkBasic Pro and DarkGDK into consideration when coding for DarkGDK.

I Also understand, Apex, you are saying they problem might be leaving things in memory hidden. This is kind of what I do - but rather than lose performance over time by adding objects and just hiding them as the game progresses, so far - my strategy to at least get "Whatever" performance and stay there is to load everything once - and then just show/hide as needed.

For Bullets - I basically have a "Supply" of them I recycle over and over. If I run out - you get a blank - if I see that there are too many times with blanks - I adjust the program to try and find that sweet spot between having enough for game play and not just creating unlimited or huge cache reserves - ultimately trying to at least be concious of the fact that "To many things" slow stuff - but adding and removing is not great either.

I do not know of a perfect solution to this - nor the culling problems we face - nor the inability to load objects and instead of just hide them - swap em to normal computer ram versus the video pipeline.

I think that would be a good improvement. I have terrains that are limited in size because I have to use these big super textures for it and if I fill my vid card - (Regardless of culling) it tanks and FPS drop! If I stay well within it - I have room (hopefully) left for the other game things. This isn't perfect - but its an ongoing struggle until someone comes up with some great idea to really make the video card memory/pipeline more manageable.

Back to topic - @Red Ocktober specifically - I hope you haven't stumbled onto some bug that can only be seen now that you've done some major development. Alternately - you are working with shaders a bit if I'm not mistaken and perhaps if its not a dual camera DarkGDK Bug (Not beyond comprehension - I've had bad luck with multi-cam experiments in DarkGDK) it could be the shaders themselves.

I'm the first to admit I don't much about them - I try them - use demo program's as a guide - and hope for the best - some minor tweaking - mostly just chaing texture file names and playing with the textures and seeing what works and what doesn't through trial and error - but I'm trying to get to my point which is that shaders are indeed little mini programs. That much I understand. They are little mini applications that are placed into the video card and are executed during the pipeline stuff - in parallel or per refresh I don't know - but I wonder if shaders can have memory leaks? Perhaps one video card doesn't maintain its "Bullet fast" pipeline if a shader is run continuously - as well as another (would explain off why not easily reproducable if that is the case)

Don't know - but these things scare me - because like many others here - I put more time than is proably healthy making my game and to find that its all for nought because I've coded myself into a dead end because I'm smack up against flaws in either the GFX card or the librarys I use - albeit DarkGDK, DarkBasic, DirectX ??, or the video card's software/hardware renderers... well - its just ominous to think about.

I'm trying to combat certain ills - but making sure my application can turn off "Stuff" fairly easily and eventually for the end user via a menu or something - liek is the case with flight sim and Farcry and many others - things like Use Shaders On/Off (Big performance hit), "Only use lowpoly", "Number of Trees" or Scenery "Low Detail, Medium, High" etc... things liek this - so I can test BARREN - to make sure game code it performaing - then turn on Eyecandy when I'm satisfied with the CORE performance - and just deal. I know I have a weak video card - but I'll TRY to at least come up with something that on a high end machine looks better than what I would typically run.

At the end of the day though - I have fun conquering these things - or at least getting decent results - at the end iof the day - I find I'm having fun using DarkGDK and DarkBasic

Wow, that was a concise explanation. It's good to share this sort of information though so that other programmers can use it to up the performance of their games. Thanks Jason

Paul.

yeah... thx for the additional input guys... good stuff...
i'm still looking...

--Mike

i finally got what was causing the problem pinned down...
dumb, thoughtless mistakes... i had placed a few of the vector 'factory' functions (GetNextVector()) inside the Update() method for my Sky class and for a utility command (GetDistance())...

every iteration of the game loop was creating a new vector...

i'm surprised it didn't cause the whole ball of wax to explode like an a bomb

--Mike

...it would have.... eventually GOOD FIND! Glad you got it!

Good news Mike. You know the old adage ... 10% inspiration 90% perspiration