flat assembler
Message board for the users of flat assembler.

Index > Linux > opengl and printf newline

Author
Thread Post new topic Reply to topic
ProphetOfDoom



Joined: 08 Aug 2008
Posts: 120
Location: UK
ProphetOfDoom 02 May 2016, 15:47
Hi,

I don't really want to post my code as it's thousands of lines, very untidy and a mixture of C and assembly...

BUT... Here is the problem. I was trying to debug a collision detection algorithm so I was doing a lot of "printf" calls including the newline character "\n". I was probably printing about 100 newlines per second. My previously well-behaved opengl drawing went crazy. Objects moved about the screen in a really jittery/jerky way, for example something that was meant to move by one pixel would appear to move by 10 pixels. However, when I printed out the coordinates to the terminal during drawing (before and after a lot of matrix multiplication) it still showed a smooth one pixel increase.

I eventually narrowed the problem down to the newline "\n" character. Remove all newlines, and the opengl code would behave perfectly. Also, if I redirected the "\n" characters to a file on disk, the code would behave perfectly. From Googling I understand that printf is "flushed" every time a "\n" is encountered. Does this involve a switch from user mode to kernel mode, or any other long delay etc.? Something that would explain this behaviour? Or does it suggest some other bug in my code?

Thanks.
Post 02 May 2016, 15:47
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20344
Location: In your JS exploiting you and your system
revolution 03 May 2016, 08:51
Without code it is impossible to say what is happening.

Perhaps you can try to gradually remove unrelated things from the code until the problems disappears. Figure out the minimum that is needed to get it to fail and work from a smaller base.
Post 03 May 2016, 08:51
View user's profile Send private message Visit poster's website Reply with quote
ProphetOfDoom



Joined: 08 Aug 2008
Posts: 120
Location: UK
ProphetOfDoom 03 May 2016, 20:23
Thanks revolution I will try what you suggested. Problem is the program (as well as being large) has masses of dependencies and I can't really expect others to install it just to hunt for this bug. I just know that sometimes coders get intuition about things and can suggest a fix. For example I helped someone out a while back with a segfault and didn't need to read his code just his description of what he was trying to do.
Anyway, I've just ruled out the possibility that printf("\n") is causing timing problems. It takes up almost no time. Maybe if I can shave the code down to a few hundred lines I will post it on here, certainly not in a compilable state though. IIRC even the .tar.gz file is too big for this forum.
Post 03 May 2016, 20:23
View user's profile Send private message Reply with quote
ProphetOfDoom



Joined: 08 Aug 2008
Posts: 120
Location: UK
ProphetOfDoom 03 May 2016, 21:08
Okay I fixed the problem.
I had this call (probably copied and pasted from the web) in my C code:

Code:
SDL_GL_SetSwapInterval(1);    


I changed it to:

Code:
SDL_GL_SetSwapInterval(0);    


And now things are super smooth even when printing loads of newlines. It seems strange that newlines and the swap interval would interact in that way, but apparently they do. And yes I suppose, if all else fails, read the source. Smile
Post 03 May 2016, 21:08
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.