Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Am I crazy or is there a major issue with DBP sprites here? 6+ month project about to be scrapped :'(

Author
Message
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 31st Jan 2013 01:20 Edited at: 3rd Feb 2013 15:37
EDIT 2/3/13:Thanks everyone for their help so far! I haven't 100% fixed the problem, but I have learned a lot from your posts and GREATLY improved my program as a whole. I really appreciate everyone's help and suggestions.


I'm hoping these forums aren't completely dead - I'd REALLY appreciate anyone's input on this. I've been working on a project for 6+ months, and just now have found what seems to be a major issue with a basic sprite command.

Moving a sprite across the screen at a set speed and angle is not smooth - every couple of seconds it lags/gets jittery for a very short amount of time (maybe less than a quarter of a second).

I'm hoping that it is some setting, or something that I'm doing wrong, but I've literally narrowed it down to a few basic lines of code with a SINGLE sprite that is being moved around on the screen, and still get the bumpy/jittery effect every couple of seconds.

I don't see how it could be possible for this to be acceptable behavior, which is why I'm assuming I'm doing something wrong... but after having tested it on 3 different computers I'm at a loss. I would hate to have to completely start over with my project in another programming language/kit, but it looks extremely unprofessional with these bumpy/jittery movements every couple of seconds.

If anyone could spare the time to download the attached file testMap.png and run this code I would be extremely grateful. If I can fix whatever is happening here I feel confident that I can complete my project which I have been working on feverishly, and would be semi-devastated to have to scrap this far in.

The program will automatically move the sprite around, so if you just focus on one of the flowers on the sprite, you'll notice it will be smooth for 3-10 seconds, and then get bumpy for about a quarter of a second, and then smooth for 3-10, etc. Please watch it for a good 20 seconds at least, because it is subtle (but noticeable).

THANKS A LOT!!!!!!!!!!!!!!!!!!


paul5147
20
Years of Service
User Offline
Joined: 11th Jan 2006
Location: Hot & Sunny
Posted: 31st Jan 2013 07:00
Hi Jamez0r,is this the whole of your background image your trying to move as one sprite (4000x2500)? It nseems a little on the large size to use as a sprite.
Hodgey
16
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 31st Jan 2013 08:19
Try turning vsync on. It's been so long since I last used DBP that I've forgotten the command but I remember this being the solution to the jittering I got when using DBP.

Andrew_Neale
16
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 31st Jan 2013 09:10
VSync was my first guess as well. You simply add an extra flag at the end of the 'set display mode' command.

E.g. set display mode 1920, 1080, 32, 1


Previously TEH_CODERER.
Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 31st Jan 2013 09:21
Jamez, be patient. This is now your 3rd thread about the same issue.

Though I didn't say it in your other thread, the way the jitter appears would also lead me to believe it may have something to do with the vertical sync.

I've just tried their suggestion and it appears to resolve the issue.

"You're not going crazy. You're going sane in a crazy world!" ~Tick
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 31st Jan 2013 13:54
This will help you understand what vertical sync is : http://hardforum.com/showthread.php?t=928593&highlight=vsync

TheComet

http://blankflankstudios.tumblr.com/
"ZIP files are such a retarded format!" - Phaelax
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 31st Jan 2013 14:07
You guys are lifesavers, thanks so much! It was vsync, and I didn't realize that was an option in 'set display mode'.

Didn't mean to spam the forum - was getting confused/frustrated with the posts/edits having to be approved before they go through. I want to delete the other two threads, but I couldn't find the option to delete (I looked for a couple minutes... is there not an option?). At one point I had edited the old post to make it blank, but then it reappeared later on (?). Anyway, I guess that just means I'll need to be active on the forum so I can get Normal User priviledges.

Quote: "Hi Jamez0r,is this the whole of your background image your trying to move as one sprite (4000x2500)? It nseems a little on the large size to use as a sprite."


Hey Paul, yes I have been using that as a background (for testing purposes at the moment). That background is basically the largest that I will be using, so I didn't think I would need to do a tiling setup.

Is there a different command that is faster/more efficient for a static (but scrolling) background? Like "paste image" possibly?

Again, thanks a lot guys and I apologize for the spammage
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 31st Jan 2013 14:22
Thanks Comet, just read up on that. Good information!
zeroSlave
17
Years of Service
User Offline
Joined: 13th Jun 2009
Location: Springfield
Posted: 31st Jan 2013 22:17 Edited at: 31st Jan 2013 22:19
Hey there. You may want to keep in mind that it is better suited for dimensions of images to be represented in powers of 2(128x128; 256x256, 1024x1024; 4096x4096, etc..) I don't think DBP will give you an error, but if you ever move over to a different language/platform, you might get issues from this. DirectX may automatically size the image up to the nearest ^2. A 3000x3000 image might actually take as much memory as a 4096x4096 image.

I think most graphics cards support non^2 images, but it's not bad practice to get into using ^2 images. It's for C++ and DirectX, but look into D3DXCreateTextureFromFile and D3DXCreateTextureFromFileEx for more information about this.

Also, you could use PASTE IMAGE, but you may run into issues with draw order if the images are not organized really well. I think you can set the draw order for sprites. I'm not sure. I have never really used sprites!

TheComet, thanks! That was a good read.

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.
Jeff Miller
21
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 1st Feb 2013 02:10
I had the problem with an application several years ago. A workaround that worked for me was to hide the sprite and simultaneously expose a plane with a texture bearing the sprite image at an appropriate position and orientation to simulate an invisible swap, move the plane any way I wanted, then re-swap the sprite for the plane at the destination. Required lots of geometry pre-calcs involving screen-position, screen aspect, screen pixel dimensions, and FOV, but likewise allowed some movement effects (like crazy intermediate 3D rotations rather than a restricted 2D rotation) that aren't easy, if even possible, with sprite commands. DBP really burns through the math and is quite fast with 3D movement.
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 1st Feb 2013 06:16
So I'm pretty sure I spoke too soon - for some reason the first time I ran the test program with VSYNC on it seemed to be perfectly smooth. I excitedly tested it out in my program and although the screen tear was gone, in its place is an FPS drop (looks like a 'jump' instead of a 'jitter' now... as would be expected after reading Comet's post).

So I took the advice from a couple of you and converted all of my .bmp to .png. Took me 2+ hours to do so. The .png files are much, much smaller so you'd think it would help, right?

Just ran the game and it appears to be even worse than before. I don't understand how that is even possible. I went from over 300mb of art files to 32mb. I didn't change any code besides changing the .bmp extensions to .png (and then converting the actual images). I'm getting pretty frustrated, so please excuse me if I am venting a bit.

I guess my biggest question at this point is: am I expecting to be able to do too much without experiencing lag? I've scanned through my code - it is pretty efficient and if I monitor my CPU/Memory usage while running the game it never even gets close to 50% after loading the game.

I would think on a 2-year old computer that can run games like Skyrim and Dark Souls without a hitch that I shouldn't be having this problem. In all honesty I didn't even think about the file-types/sizes for my images because I thought I would be able manipulate and display a TON of sprites without even worrying about FPS lag.

I restarted my computer, made sure there were no programs running in the background, and ran the test program (the code I posted up top) with a 512x512 .png sprite and it is STILL LAGGY. WITH A SINGLE SPRITE BEING MOVED

Does anyone have any clue what could be going on? This makes absolutely no sense to me, and its killing me. Is there some "run game in exclusive mode" or something that would make the game a higher priority for CPU/GPU usage? (grasping at straws here...). I'm running Windows 7 on all of my test PCs.
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 1st Feb 2013 06:31
Scouring the forums for info.

So far found one person that had suggested keeping SYNC ON but not setting the SYNC RATE, and letting it default to your monitors refresh-rate speed.

I guess my monitors refresh rate is 60, because it lags exactly the same at the same FPS >.<

The quest continues...
Andrew_Neale
16
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 1st Feb 2013 08:58
Quote: "I would think on a 2-year old computer that can run games like Skyrim and Dark Souls without a hitch that I shouldn't be having this problem. In all honesty I didn't even think about the file-types/sizes for my images because I thought I would be able manipulate and display a TON of sprites without even worrying about FPS lag."


Quote: "So far found one person that had suggested keeping SYNC ON but not setting the SYNC RATE, and letting it default to your monitors refresh-rate speed."


The more powerful the computer the worse, at least in theory, this issue would be. When the game tries to render the screen faster than the monitor's refresh rate you get this issue because the game is already rendering the next frame before the monitor has had a chance to display the next one. The more powerful your machine, the higher the frame rate, the more this issue is likely to be noticeable.

Vsync basically just enforces your monitor's refresh rate as a maximum frame rate and tells the game to wait for the last frame to be fully drawn to the screen before starting the next one to prevent this tearing/lagging effect. You could also do this manually by keeping a timer in your game loop so that every loop it checks if at least 16/17 milliseconds have passed, otherwise it doesn't call the 'sync' command. This allows everything else in the game to maintain as high a frame rate as possible which, whilst same may argue is unnecessary, personally makes the control feel smoother and more responsive.


Previously TEH_CODERER.
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 1st Feb 2013 14:06
Thanks for the suggestion Andrew - I'm going to convert the program over to time-based instead of SYNC/FPS-based and see if that helps.

If anyone else has any input I'd love to hear it. Thanks everyone!
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 1st Feb 2013 15:35
So I just converted the test program to base the movement on time (moves the sprite every 15ms) rather than SYNC speed, and turned SYNC 60 and VSYNC off



I'm getting 1500+ fps but the image is still jumpy. Tested it with a 1024x1024 .png sprite. Seriously wondering WTF is going on here. About to call it quits someone help!!!
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 1st Feb 2013 19:57 Edited at: 1st Feb 2013 20:06
It's jerky cause the frame rate/timer (use Ian M's hitimer for better results) isn't consistent enough, this line 'if moveTimer < timer()' is executed at different intervals even if it's based off the timer. To fix this problem you need to enter the world of timer based movement, which gives consistent movement even if the frames differ at times.

The idea is we check to see how much time has pasted between frames, then use this value as a difference scalar (delta) to what we're moving.

So an example (basic timer based movement):


For more information on timer based movement either google, ask here or search the forums
Ashingda 27
18
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 1st Feb 2013 22:06 Edited at: 1st Feb 2013 22:07
@Jamez0r
Your problem may not have much to do with the example snippet. Perhaps it's because of the way you are coding your sprites. You may be using too many sprites or the sprites are too large and that may be what is causing the graphics lag.

I've experience this problem earlier on and later found solutions. But to confirm if it's the same issue...

1. What is the number of sprites used?
2. Is your Background / Terrain a sprite?
3. If so, are they tiled or single image?

2D is way more trickier than 3D and much harder to work with. It may be easy at the start but gets hard later, the opposite goes for 3D.

Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 2nd Feb 2013 10:28 Edited at: 2nd Feb 2013 10:29
Ashingda 27, Jamez0r last example he was only using one sprite and found that he has the same issue, I can tested and it's there. My move to timer based movement fixed the issue though.
Ashingda 27
18
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 2nd Feb 2013 12:12
Well he did say it worked after the vsync then messed up after loading all the graphics, I'd assume it's the excessive usage of sprites or very large textures. I had issues with that in my old laptop.

There's a reason why there are methods using tiles, a single super background image isn't very effective.

@Sasuke
Then again I didn't really notice the first problem, different machine giving different results...

Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 2nd Feb 2013 15:29
Ashinga - Like Sasuke said, I was getting the FPS lag/jumps with the sample code + a single 512x512 .png sprite (which is what led me to believe it was some basic command/setting that I was misusing).

Sasuke - I tested with your (much better) timer-based code and it worked for the single sprite, thanks! I am going to read up on the timer based movement and then implement it in my game.

Thanks a lot guys!!!!
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 2nd Feb 2013 17:08
@Ashinga - sorry, I didn't explain how I was testing things very well (I was going back and forth from the "test program" and my actual project).

Thank you for your input though!
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 2nd Feb 2013 17:33
So I've learned a lot from this thread (thanks everyone).

A couple new questions arise:

At what point does it become more efficient to TILE your background instead of just having a single image/sprite?

Lets say my screen size is 800x600, and that the room I'm in is 1600x1200 (aka twice as wide and twice as tall). Would it be taboo to just have the background as a single 1600x1200 sprite? I would imagine moving a single 1600x1200 could be more efficient then creating, deleting, and moving "X" number of tiles.

Seems to me that the benefit of tiling comes into place when you have a room that is (just throwing out numbers) 5 times taller/wider, because you can delete the tiles that are scrolled offscreen, and therefore never have to display/handle more than a specific number of tiles.

If my game were to never be more than 3 screen-sizes tall/wide, do you think it would be acceptable to just use a single background sprite?
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 2nd Feb 2013 20:53
Ok, I think I may have found the source of my problem, and I feel like a n00b.

--

If I change
newTick as dword
to
newTick as float
it goes from being perfectly smooth to getting the jerky movement that my program has.

--

1) I've never used the data type "dword". I don't know much about pointers, and honestly don't know what their use is. So why does it make such a huge difference in FPS lag going from DWORD to FLOAT? Is it that much slower to process FLOAT variables, or is this a specific case where DWORD is ultra-important?

2) While I'm at it - is making a variable GLOBAL a big no-no? My program has about 100 GLOBAL variables like the players stats (HP/mana/stamina/etc).

I suppose my newest optimization-quest is to figure out what data type each of my variables should actually be. Thanks again for everyone's help. I SEE THE LIGHT AT THE END OF THE TUNNEL
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 2nd Feb 2013 22:30
DEFINITELY making progress here.

Another thing I learned:

Dividing a float by 1000 is not the same as dividing by 1000.0

Was re-creating the code Sasuke had posted, and just couldn't get it to work quite right. Noticed his "1000.0" versus my "1000"... as of now game appears to be running smoothly!

Gonna have to scan over all of my float variables and see which ones I can convert over. Do you guys make your angle variables integers or floats usually? For projectiles/enemy movement I think I could use integer 0-359 for their angle instead of float...
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 3rd Feb 2013 03:59
Quote: "Just ran the game and it appears to be even worse than before. I don't understand how that is even possible. I went from over 300mb of art files to 32mb. I didn't change any code besides changing the .bmp extensions to .png (and then converting the actual images). I'm getting pretty frustrated, so please excuse me if I am venting a bit."


Sounds like you might have used the [b[Set Display Mode[/b] command after loading your content. This should cause any images/sprites/objects to be deleted.

Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 3rd Feb 2013 04:36
Just curious - how long did it take you guys to become normal users, and not have to get your posts approved?

I posted like 10 hours ago and they still haven't shown up
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 3rd Feb 2013 08:48 Edited at: 3rd Feb 2013 08:49
Quote: "1) I've never used the data type "dword". I don't know much about pointers, and honestly don't know what their use is. So why does it make such a huge difference in FPS lag going from DWORD to FLOAT? Is it that much slower to process FLOAT variables, or is this a specific case where DWORD is ultra-important?"


It really depends on what your doing. For instance, timer() returns an integers range is –2,147,483,648 to 2,147,483,647. So your asking why isn't newTick etc an integer... well it's because timer() can run over into negative numbers, if this happens mid game... well let's just say you don't want it happening. Dword starts at zero which helps insure that are calc never goes into negative numbers but it's not a complete fix (hence why I said it was a basic version), you'll need to look at a better version that deals with averages so timer() overflow doesn't become a problem.

Quote: "2) While I'm at it - is making a variable GLOBAL a big no-no? My program has about 100 GLOBAL variables like the players stats (HP/mana/stamina/etc)."


Depends what it is. Globals insure that a variable can be used anywhere in your program. If your only ever going to use it in a single function then it's what we call a local variable as it's only locally used to what it's contained in. If you have variables that never change through out the whole game then it's best to set them up as constants.
Ashingda 27
18
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 3rd Feb 2013 08:52
To get normal posts I cant remember, you just got to keep posting... It may have been about a week for me.

Quote: "
At what point does it become more efficient to TILE your background instead of just having a single image/sprite? "

If the background is tile-able I would always do it regardless of size. It also saves alot of disk space and aid to speed up map creation. Important thing is, it's just good practice.


Quote: "I've never used the data type "dword""


That is taken from the DBPro's Help. Press "F1" >> "PRINCIPLES" >> "Datatypes and variables". Is just a different type of variable you can use for holding large pos+ values but no neg- values.


Quote: "Dividing a float by 1000 is not the same as dividing by 1000.0"

That's because they are different types. Type casting may slow down your program and or may return unintended results.


For extra help: If you haven't already, check TDK's tutorials. http://forum.thegamecreators.com/?m=forum_view&t=99497&b=10

Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 3rd Feb 2013 15:32
Just got IanM's plugins. The hitimer() command is definitely giving me better timing resolution.

My program is still choppy (my deltaTick spikes over 10ms about once a second, at seemingly random time intervals), but considering the amount of improvement/efficiency I've learned over the past week I feel pretty confident that I can track it down and fix it. I think my first step is to find which function is taking up the most processing time and improve it, which will be possible with hitimer().

I'm still baffled by the fact that changing the data type of "newTick" from dword to float in the tiny test-program (the one posted in this thread) could cause VERY NOTICEABLE lag to appear. Would anyone be able to explain this to me a bit further? Was it the fact that the calculation delta = (newTick-lastTick) / 1000.0 becomes overly-accurate past the decimal point and takes that much more time to calculate?

I feel that this should be my #1 point to research, since it is HIGHLY possible that I am doing a similar calculation elsewhere in my program. I may be calculating the sin/cos/tan of an angle using a float/real (for the angle variable) when I could just be using an integer. It just seems strange to me that a single calculation could cause so much delay. Do you guys use floats for variables when calculating angles?? Is the lag caused by making newTimer a float a specific instance where I shouldn't use it, and normally it is OK to use floats for calculations?

Also, why is it that the lag issue (when you make newTick a float) causes the fps-skip/blip/jitter only about once a second, and not EVERY iteration of the loop? Its like it is smooth and then BAM it skips. Why does it happen periodically and not EVERY time?

Side question:

I've noticed that if I restart my computer and have NOTHING running in the background, that my game is VERY smooth - but if I have something like a video streaming in the background I get the FPS-jitter issue. As stated above, I definitely have some kinks to fix in my program (so it is mostly likely just that), but it just seems a bit strange to me. I can run other full 3D retail video games full-screen on one monitor while streaming video and doing other things without getting a noticeable drop in FPS. Could it be that my game is unnecessarily CPU/GPU intensive to the point where if it has 100% usage it can be smooth, but as soon as it has to share with another program it starts lagging? Does anyone else have the same issue with their projects? Basically I'm asking this to rule-out the possibility of a "known issue" of the application not running well with other programs in the background.

Thanks again for everyone's help. I know I sound like a complete n00b with some of these questions, but after I fix these lag issues and get back to finishing the demo I would really love for you guys to test it out. It is a top-down Zelda-like (SNES) game but uses the mouse pretty heavily (aiming shots, activating abilities by doing specific gestures, etc). I've been working on it for over 6 months, but had only been dealing with single screen-sized rooms and now am expanding to larger-then-screen rooms that follow your character as he moves around - so never noticed the tiny FPS-blips since I didn't have a non-animated sprite moving along a set path for multiple seconds.
Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 3rd Feb 2013 21:34
Well, here is a quick update.

It seems like every time I eliminate a float variable that the laggy-fps problem becomes less and less. Are Basic's floating point operations really slow? If so have you guys heard of any plugins for faster calculations?

Also, (and this one is frustrating me) it seems like sometimes I get an fps-lag-spike that ISN'T due to my main loop processing slowly. With hitimer() I can see how long it is taking per iteration of the loop (the "delta" variable). I have another variable that increments any time "delta" goes above 4ms. When the game is running completely smooth, "delta" is between 1-4. When the FPS spike happens, that variable isn't getting incremented - AKA the loop still isn't
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 4th Feb 2013 05:18
Quote: "Are Basic's floating point operations really slow?"


Nope.

Quote: "Also, (and this one is frustrating me) it seems like sometimes I get an fps-lag-spike that ISN'T due to my main loop processing slowly. With hitimer() I can see how long it is taking per iteration of the loop (the "delta" variable). I have another variable that increments any time "delta" goes above 4ms. When the game is running completely smooth, "delta" is between 1-4. When the FPS spike happens, that variable isn't getting incremented - AKA the loop still isn't "


Something to be mindful of, is that your program is not the only thing running, there's probably 30, 40, or more other apps and services running with you. So if some system operation, or other application needs to do something while your process is being executed, then your app will be switched out and the other process will execute. In such cases you're no longer timing the game loop, but the game loop plus and some other 3rd party application.

Dar13
18
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 4th Feb 2013 05:22
Quote: "Nope."

Actually, yes in DBP's case. IIRC, DBP calls a function to handle float mathematical operations, instead of using the built-in operators. However, I've never noticed floats being that slow.

Jamez0r
13
Years of Service
User Offline
Joined: 30th Jan 2013
Location:
Posted: 4th Feb 2013 05:34
If anyone is able to help me fix this problem (and lives in the US) I will buy you a pizza and have it delivered to your house. Yes, I am resorting to bribery because I need help and I appreciate the time anyone spends trying to troubleshoot this with me

-----------------------------

So I've been trying to fix this all day, and have come to the possible conclusion that there may be two issues here.

Issue #1: floating point operations may be ridiculously slow.

As I was re-enabling my functions one-by-one I noticed one function caused the game to go from smooth to choppy. I noticed there was a division operation where a float was being divided by 15.0 (which based on the possibilities for the numerator would very often produce a repeating decimal point, like 0.5333333333). I changed it to 16.0 and it completely fixed the lag (that had been introduced by re-enabling that function). Like I said above, I'm really starting to question the speed of floating point operations in DBP. Are angle calculations like sin(), cos(), atanfull() just as bad? I use atanfull() a LOT.

A side note about this though - in my last post I talked about how I would get the choppy fps spikes but that my "delta" timer was not going over 4 milliseconds. This remained true even with this situation, and I don't understand how it is possible. Clearly the lag was introduced by the floating point division operation that was being calculated every iteration of the loop - I turned it off and on about 5 times to be 100% sure - and yet the delta time never spikes. Wtf?


Issue #2: Doing ANTYHING in the background while running game

Simply put - it appears that if I have almost any background program running that I get FPS-spikes about once per second. Running a browser on a simple text webpage (this forum) did NOT cause any issue - but streaming a youtube video did. Thankfully (I guess...?) this showed up in my delta timer, which would spike above 5ms. Even running something as simple as an Excel spreadsheet (to keep track of my variables) caused the lag to appear. Note: I can play other video games flawlessly while streaming video, skyping, and having other programs in the background.

So this raises a concern... isn't one of the main points of the timer-based movement to smooth out the display based on the delta time? If my delta time is never going over 10ms, then shouldn't it still be smooth??? I originally had the program at sync 60 which would update about every 15ms, and it would be smooth (when no issues were present). So if my delta timer never goes over 10ms, and I have what appears to be 500+ FPS, how in the heck am I getting these lag spikes? (and no, it isn't simple screen-tearing its pretty significant JUMPING).
Ashingda 27
18
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 4th Feb 2013 08:54 Edited at: 4th Feb 2013 08:56
Try this. Has extra flags and sync rate to 0. The vsync is already turned on so using sync rate will actually mess up your graphics.


Have you tried in different modes if there are differences Windowed/Full/Desktop?


Or you can try posting your codes, maybe the problem is hidden somewhere else in there?


If all still fails you can try the advanced sprite plugin. It's much faster and has more control but also much harder to use.


Run this test and see if it's still laggy. Also try running it with the vsync off.


Dar13
18
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 5th Feb 2013 01:19
@Jamez0r
Floats are slower than they should be, but they're not objectively slow. I doubt your issue is from a simple division operation, but you can test that it's the division operation by changing it to a multiplication operation by replacing the "/ 15.0" with "* .0666".

DBP also has a nasty habit of using 100% CPU when running a game except when a user uses nice sleep() or some other function that gives back CPU cycles to the OS. And getting performance issues from running background processes(streaming Youtube videos can be taxing on lower-end computers) is a fact of life for any realtime graphics application, as those background processes take CPU cycles away from the application/game.

Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 5th Feb 2013 04:24
Speed is a red herring. The problem sounds more a like a underflow/overflow of 32bit float precision given the interval between frames. Which can give some funky cumulative results.

Login to post a reply

Server time is: 2026-07-07 19:35:23
Your offset time is: 2026-07-07 19:35:23