DM>> Perhaps on an 8086... but on an 80486?  Probably not...
DM> DG> Ok, let's see then.
DM>Good point.  Evidence.  :-)
DM> DG> #include 
DM> DG> #include 
DM> DG> #include 
DM> DG> #include 
DM>What's DOS.H for?  Get rid of it.
Microsoft couldn't. :)
I just included cause I copied the example for the clock stuff from the
help and it had it there so I left it.
DM>x+(y<<6)+(y<<8): 182
DM>x+y*320: 169
DM>Consistantly your shift is slower by about 6%.  This is
DM>with standard optimizations and debugging.  No fancy stuff
DM>here.  Putting optimization to -O3 obviously destroys the
DM>entire thing.  :-)
Hmmm, wierd. Destroys? How?
DM>Moving over to my BBS machine, a 486 with Warp 3 Connect, I
DM>get some more interesting results.  It was not doing
DM>anything at the time - the modem was not in use, the
DM>network was not requesting files, etc.  The same executable
DM>(literally) was used to produce:
DM>They are basically the same here.
Yep, just the accuracy of the clock I guess. Wierd though.
DM> DG> On mine, a 686 120mhz, under windows 95, the shifting method was 
faster
DM> DG> in every instance.
DM>Is this a Cyrix 686?
Let me check.
...Two reboots later...
Darn non-system disk...
Yep.
I guess really, so long as you don't need lots of frames per
second (ie. not more than 10 or so), it doesn't really matter what
method you use. They are both about the same. And given the speed of
today's processors, and the compilers, it doesn't matter in terms of how
smooth the video is (I mean, shifting or multiplying won't affect
it). You should just not plot too many pixels. If you plot too many
pixels then you should change the algorithim.
Danial.
___
 X SLMR 2.1a X 
--- Maximus/2 3.00
---------------