Analog clock screensaver

hi!

are you interested in a simple screensaver which looks cool, but does not take any CPU and graphical usage?
you got it!

download: http://stuff.dev-ch.de/index.php?article=stuff_analogclock

tell me your opinions and thoughts! :)

How can it not use CPU cycles and gfx?

I don't think having a bright white background is a good idea for a 'screensaver', BTW. :)

my task manager measures 0% CPU usage, which means that it must be less than 0.5% and that's low.

Low is different from none at all. I'm just being pedantic. ;)

man kind is not physically correct in every sentence and still people deliver a message even if they are stupid and cant speak a language very well.

anyhow, dyou like it?

Looks like it does what it says on the tin, from the screenie. I don't use screensavers myself, though.

oh and another thing: in the case of an LCD monitor, the color while (FFFFFF) only means, that the backlight fully shines trough the pixel. the color black (000000) means that the backlight does not shine trough the pixel at all. so in that case it doesnt matter which color the screen has unless you turn it off.

since screen burn only affected monochrome monitors the term screen saver has always been a bit pointless

these are like those "fireplace" dvd's for your tv
it gives you something to watch (or ignore) on your screen without reaching over to switch it off

i myself never use screen savers i just leave my desktop showing safe in the knowlage that my lcd wont have "the mistress of the red couch" an image i got from deviant art years ago etched into it

That's not true, it affected all CRTs, it was more apparent on dumb terminals (usually monochrome) as there was often static elements on the screen all the time.

Surely a bright white screen would use alot more power than a black one?

Not entirely true -- I've seen color CRT's with the windows login window burned into them as well. It was just a lot more pronounced on the monochrome CRT's since there was much less variation in the colors displays, so more potential for burn-in.

I was led to be under the impression that the way colour CRT's were set up (mostly by being colour) that they negated the screen burn by the beam not being as intense 100% of the time

as dumb terminals were black or white (or green) not grey like tv's
but a pc unless running a dos application for years on end had more colour variances ... mspaint here word their minsweeper inbetween
never noticed anything 'wrong' on my old CRT ... perhaps i never let it stay static for too long ;)

in these days, screensavers are just pretty. if you want to avoid a screenburn, just make one that changes the color after a second

edit:

Graphics 1024,768,32,2:SetBuffer BackBuffer():While Not GetKey():ClsColor Rand(255),Rand(255),Rand(255):Cls:Flip 0:Delay 100:Wend

(129 bytes of code)
anti-screen-burn screensaver, have fun.

Hey DC, did you use my watch code from the archives? If so then I want my logo on every hand of the watch ;)

BTW this watch is looking exactly like the train station watches we got here. Only the second hand is a little diffrent, see here: http://mct.sbb.ch/mct/immobilien.htm


Screensavers look cool (I really like those aquariums, and eg. boiled sweets tunnel race savers), but they are badly integrated in the System (from the OS side), so I usually turn them off.

Well if we're talking code archives....

http://www.blitzbasic.com/codearcs/codearcs.php?code=317

I posted this 5 years ago!

nope, i didnt use your code. besides:

Flip
Delay 5

replaced with:

Flip 0
Delay 1000.0/60.0

will save cpu usage, because Flip True will usa a lot of cpu usage because the Flip command itself is pausing!!

btw: does my code look like yours? i dont think so ;)

Wait a minute, it was

if a new second
 render
 flip
endif
delay 5

so flip is done only once a second. And of course I know Flip 0, Personally I also use Vwait:Flip 0 instead of Flip 1 in a game loop. But for the little watch demo it wasn't that important.

I didn't see your watch code, did you release it? Or are you talking about code in general? Did you mean my style is crap and yours is perfect? :P

After all, it's the thing that shows up on screen that counts.

i did release it. you'll find a download link in my first post.

ps: Flip True will use much more CPU usage than you think! open your task manager and see for yourself...but more than 10% cpu usage is nothing for a screensaver. besides: you can shrink it to a minimun of 1% very easily

Well, how do you know what I think? My watch isn't using 10%, but a max of 2% in the taskmanager, most of the time it shows 0% tho. Testing it with Sysinternals Process Explorer shows a max of 1.54% (on a 1.6GHz single core cpu BTW). And all this with Flip true. With Flip false both tools show zero most of the time, but the app consumes up to 6% cpu when you move the window, or move an other window on top of it, so windows has to restore rectangular parts of the desktop.

Flip true (assuming Flip uses 60Hz) is going to take a max of 16.667 ms. This is 1.67 percent IF it is called only once a second.

I totally agree with you, Flip true is wasting CPU cycles.

A loop like this:

while not keyhit(1)
flip
wend

consumes up to 98% !
Vwait:Flip 0 would be a substitute.
But there is a problem with Vwait: on some Laptops and LCD screens it won't wait at all, but completely ignore the command (Vsync seems to be set all the time).

Since Vsync is required to properly Flip the buffers, we probably have to determine if Vwait works at all (measuring the elapsed time between two VWaits) and then, in the worst case when Vwait is ignored, simply use a "Delay rest-of-frametime" as a substitute for Vwait or Flip true.

In the real world it isn't such a desaster when Vwait doesn't work since a fullfledged game usually won't run with hundreds of frames per second in full speed (assuming controls etc. are delta-adjusting). It may become a problem when the game runs too fast, so you'll have parts of multiple frames on the screen.

ok. that sounds like a great "tutorial for blitz cpu usage problems"! i like the way you explained it. on another topic: since my simple clock takes _less than a millsec_ to render a frame, we can simply count it as no-time. that means, that delay 1000/60.0 will give almost EXACTLY 60 fps.
so why using flip true anyway? your clock does use as less polys as mine, so the rendering time goes against zero.
was this an argument?

Almost exactly 60 Hz may be even worse than say 50, or 70, because now the real flip will be in interference with the screens hardware sync frequence, theoreticly resulting in wandering bars, caused by a moiré pattern. But hey, this is only theory and maybe on a LCD screen you won't notice anything at all (I rarely see CRT monitors these days anyway).

The best may be to resync every couple of seconds, using Vwait, if possible.

I'd really like to know if Vwait fails on all LCD and TFT screens.

i know what you mean by the "stripes on an TFT screen". but since i use delay 1000.0/60.0, it will be almost exactly 60 fps. do you see stripes? i dont...

Well, this would make a fine thing for my handy which is missused as clock anyway ... but on my desktop I've the ultimative screen saver: background defrag with many colorfull blocks filled and half filled to watch ... very relaxing, can watch it for faaaar too long ;-)
if I need the time, I look at my G15 display

But nice usage of resource usage reduction methods :)