This won't work because you will still information leaked when the bits are toggling vs. not toggling. The reason for that is that the logic (CMOS gates in particular) generates power spikes when a a bit toggles. That needs to be addressed.
vsync? that's what it does, syncs the image redraw to the screen refresh...
Yes, but rarely do programs succeed in using it correctly and frame skipping is common. Vsync on a 60 Hz display requires the material to be an exact multiple of 60 Hz if skipping is to be avoided. On older computers this was the norm!
In the 80's and early 90's on many home computers (like c64 and Amiga) movement of graphics was nearly always perfectly synchronized to the screen frame rate. As this usually was a TV-set or composite monitor running non-interlaced video the rate was 50 or 60 Hz.
Today synchronization is pretty scarce to say the least!
What language makes the most sense now to get the jobs?
C#
I've deliberately omitted.NET — I have no desire to do the Microsoft languages.
Are you interested in which language makes you most employable or not?
I disagree. There are dozens and dozens of C# and Java programmers. If you want to be sought after, learn COBOL or become proficient in low-level C/asm.
Why should we all wrestle with different languages? Why can't there be one language that handles most of the cases?
That would be one heck of a large language!
There are different paradigms that suit different tasks. Consider merging the best of perl, python, c++, vhdl and a few asm-dialects into one language....
Who would require such a diverse language? How do you make an efficient compiler for it?
I think it's pretty obvious that you can see a difference between 60 FPS and 57 FPS on a 60 Hz screen.
57 FPS means that you will get a doubled frame 3 times a second, easily detectable by the human eye.
For optimal smoothness your frame rate should be constant and an even multiple of the display rate.
Slashdot Mirror
This won't work because you will still information leaked when the bits are toggling vs. not toggling. The reason for that is that the logic (CMOS gates in particular) generates power spikes when a a bit toggles. That needs to be addressed.
See here: http://en.wikipedia.org/wiki/Cmos#Power:_switching_and_leakage
vsync? that's what it does, syncs the image redraw to the screen refresh...
Yes, but rarely do programs succeed in using it correctly and frame skipping is common. Vsync on a 60 Hz display requires the material to be an exact multiple of 60 Hz if skipping is to be avoided. On older computers this was the norm!
In the 80's and early 90's on many home computers (like c64 and Amiga) movement of graphics was nearly always perfectly synchronized to the screen frame rate. As this usually was a TV-set or composite monitor running non-interlaced video the rate was 50 or 60 Hz. Today synchronization is pretty scarce to say the least!
C#
Are you interested in which language makes you most employable or not?
I disagree. There are dozens and dozens of C# and Java programmers. If you want to be sought after, learn COBOL or become proficient in low-level C/asm.
Why should we all wrestle with different languages? Why can't there be one language that handles most of the cases?
That would be one heck of a large language! There are different paradigms that suit different tasks. Consider merging the best of perl, python, c++, vhdl and a few asm-dialects into one language.... Who would require such a diverse language? How do you make an efficient compiler for it?
I think it's pretty obvious that you can see a difference between 60 FPS and 57 FPS on a 60 Hz screen.
57 FPS means that you will get a doubled frame 3 times a second, easily detectable by the human eye.
For optimal smoothness your frame rate should be constant and an even multiple of the display rate.