You don't need Translate for that. Just add 0.5 to the x/y-coordinates (assuming that you set up an orthogonal matrix with 1.0 = 1 pixel).
Aah, so we'll use the processor's floating point unit(s) to add to all coordinates instead of the 3D card's T&L processing unit during the absolutely required and unescapable matrix transforms? Even in Ortho2D mode, both projection and modelview matricies are in use. The upside of that is that the Transformf/d is effectively done in T&L hardware once the matrix is set up. Unless, of course, this hardware is already tied up doing something else, or doesn't exist to begin with.....
Well, what is happening? The card processes the data I gave it last time, while I am filling the buffer with new data.
Buffers aren't like magical queues that have no overhead for syncronization and filling. Something's going to have to do this work, and guess what? The CPU/motherboard chipset is the final arbiter of all bus operations.
I'm not entirely sure if this behaviour is fully implemented in dynamic VBOs, it IS implemented in dynamic D3D VBs with the "discard" flag, however.
I tend to stay away from DirectX as I detest 90 meg downloads (part of the bloat I mentioned), vendor lock-in and MS/Com/Com+/brain damage.
Besides, anyone how had to do stuff like complex particle systems or extensive 2D output using 3D had to address this issue
Note that 2D _is_ an issue in OpenGL, which effectively is never really 2D. All internal ops are performed in four dimensions, with W=1 during normal 3D ops, and Z=0 during "2D" ops. Most particle systems use billboarding, which incidentally, is CPU-bound as the card typically doesn't give you an API to cross product or normalizing functions. (Getting a raw raster image into 3D space would be.. ugh, Un/ProjectMatrix crap)
Bloating up? Oh come on. How much space is that geometry gonna take? You don't have to create a PBO for each window, you can reuse one, or create a couple of them and reuse them, but for EACH window a PBO/texture is a total waste. Besides, you are not going to use mipmaps, so another space-wasting thing is removed.
If you don't have a texture/pixel object for EACH window, where is the window coming from when it's being redrawn?... PROCESSOR MEMORY? There must either be a texture/object for each window on the screen being handled by OpenGL, OR it must be reloaded from system ram (ooh so fast, requires muchly painful CPU intervention), which will either make the aforementioned bloating become real in the former case, (recall that textures typically have to be square, really efficient for rectangular windows) or for the supposed performance/efficiency to vanish in the latter case.
NOte that mipmaps don't take much memory, and if you don't use them, the mipmap support structures must still be in place. Remember that the second mipmap is a quarter of the size of the first, and that the third is a quarter of the size (memorywise, of course) of the second. It's the main texture that bloats up all the memory, relatively speaking.
So that leaves us with geometry, which almost NEVER fills up half of the GPU RAM (except when dealing with models with about 12 million triangles). Taking up half of the mem is ridiculous.
Actually 12 million triangles would overflow most cards memory by a wide margin, just on verticies alone, unless your card manages to store them efficiently.
Does your card have only 512 KB RAM?
Oh hell yah, that ATI Charger was upgraded to 512KB at a cost of um.. $70! It is the total pwn now....or it was, at least, lol
As for Quake 4: you do *not* have to repaint the GUI all the time; just when its needed. So Quake 4 won't get into trouble unles
If you aren't using Translate, your pixel/poly ops will not align correctly with point and line ops (see appendix H of your red book) - this can be seen in certain Accolate products:P
Instead, use dynamic vertex buffer objects. Similarly, use pixel buffer objects for the textures (the window contents). And no, nowadays almost nothing is done by the CPU. Just commands are sent, and in this case, vertex data is transmitted. But transfer is mandatory anyway.
Aah, so the GPU is now responsible for system heap allocation. Glad to know a non-local processor is handling memory allocation. This still involves considerable CPU intervention, especially with the allocation and management of these 1.5-only objects. When you're updating verticies, what do you think is happening? Some magical GPU prediction of your next update? This all still has to be processed by the OpenGL pipeline, which is deep and complex and interlaced with both CPU and GPU interactions (Read the Apple Developer Guide).
Also, consider this: While your OS is bloating up the video memory, what's happening to your 3D applications? They don't mind that suddenly you have half the texture memory, or that something is consuming GPU time?
Ever seen a GL GUI? Those things are *FAST*.
To quote Dave Haynie, even crappy architecture is fast when run at 200mhz. I haven't seen anything that ISN'T fast-looking lately. Especially since Dave's 200mhz is now more like 2000mhz. However, the magic is in not using up all the resources _before_ the application starts. My old Amiga 1200 could boot up in seven seconds (including POST) off of a generous 12-meg partition, and surf the web while running multiscreen IRC sessions and a few FTP clients, with 2 megs of video ram and 4 megs of fast ram. I'm just waiting for the next version of Windows/MacOSX/Redhat to announce memory requirements that cannot be handled by a 32-bit addressing range.
With a 2D blitter, you have to perform conversions too (32->16 bit for instance). The CPU has to do setup for a 2D blitter, too
2D blit setup is less than trivial unless there's overlapping regions, and then it's just _trivial_. Integer conversions are also less than trivial, bit ops are sub-cycle for a processor, and sub-sub-cycle for a proper blitter. Floating-to-integer conversions are much less trivial, as floats are more complex and totally incompatible with integers, and require serialized operations (you cannot shift the mantissa until you've extracted and subtracted the exponent down to it's real level, whereas you can extract all four color components and recombine them in an orderless manner (r|g|b is equal to b|g|r which is equal to r|b|g which is..) ) which will not take advantage of modern pipelined _anything_.
No, you are complicating it. As I said, GL GUIs are real and blazing fast. There are tons of GL GUIs for SDL, and ClanLib renders *everything* with GL (yes, the 2D stuff too).
Quoting from Apple, "In OpenGL, there are several obvious and other not-so-obvious ways to cause either the CPU or GPU to stall on the other."... I'm complicating it because it is complicated, and complicated = evil in computing. See above regarding "Fast".
Yes, the lesser machine is a problem. However, 3D support is not. Today, EVERY graphics chip set supports basic 3D rasterization and T&L. In case where there is no support available, simply fall back to traditional methods.
This ATI Charger 512 does not support ANY of that (nor blitting for that matter), and this Rage II here only has the basic rasterization. I don't really know the specs for this S3 Trio64, but I doubt it's more than basic rasterization too, and rather slow rasterization at that. Also see the
A GL desktop actually helps the CPU by taking away the task of drawing stuff from it and having the GPU do it, which is the logical thing to do.
I dunno about that, OpenGL is rather CPU bound. Much of the OpenGL pipeline is still done by the processor, and the primitives for OpenGL are often optimized for fully 3D rendering, which is more than a little unoptimized for 2D blitting. glTranslate3f ?
A 2D-specific blitter is a simple matter of setting up a few registers and letting it happen. A 3D operation in OpenGL has to be converted to native formats, be processed through the fragment pipeline, and then multiplied through several matrix operations before anything happens. While a modern T&L card does much of the more costly things involved in this, there's still all the necessary conversion and setup which is done by the processor.
Some of these OpenGL operations may require serialization, which might even involve a hidden busy loop, depending on how defective the operating system/drivers is/are.
While much of this may be relatively trivial on a modern, ghz-scale system, anything that is taking away from my BOINC credits is teh devil, I say! (Plus one day, you might end up stuck on a lesser machine, waiting for the parts store to open...)
(NB. most of this work is required for a 3D application, so OpenGL operates efficiently when playing Quake IV, as all of these operations would be necessary in any system, save perhaps the type conversion.)
Sometimes I wish it had died. The post-Commodore times were horrible - all that fighting, failed next gen machines, broken promises, missed deadlines, successor confusion.
I still would have liked to see a AAA based system with a fully functional OS, or Phase5's design in action. Think of a GUI designed for advanced hardware overlays instead of layers...
I wonder if a new system could be built around AMD/EMT64.. the 16 multipurpose registers are very much like the 68K's 16 multipurpose registers... naah, too costly.
I'm pretty sure that if you looked deep down into definitions, you'd find that an AMD system is "x86-compatible" rather than just plain "x86". Especially if you're reading Intel's dictionary and/or legal contracts.
Further, if that's the actual quote, that may very well mean that it compiles faster than any other x86 compiler... not that it makes faster code. Typical market-droid logic/doublespeak.
Yet, even with all these shenanigans going on, at $400, it's only about half of Microsoft's offering... Half the processor compatibility, half the price. Heh.
Most Linux development is done using GCC , Most of windows with MSVC++. Only true hard-core inner-loop optimising geeks usually use Intel C/C++ compilers. These are people like game devs, crypto developers and HPC programmers.
I resent that. I optimize my inner loops (and the outer loops, and even the startup initialization data is cache aligned...) and develop games and I use MS VC6 for Windows and GCC for Linux/*BSD* exclusively.
What sort of silly person would expect an INTEL compiler to generate decent AMD code anyways? While I didn't expect intentional sabotage, I'm not entirely surprised either. It's not like it's in Intel's best interest to spend millions on creating an optimizing AMD compiler.
We're talking about the brave new world of digital rights management. You may implement the copy protection, but only if you really feel like it, and if it isn't too inconvenient.
(small print: failure to implement the copyright protection will result in immediate arrest, followed by an execution)
The rusty old world of IETF, sense, logic, and reason is gone. The new world is run by the disgusting alliance of the marketing and legal departments.
Please this correction: "Except Longhorn is a mythical Software Operating System.
Longhorn (also known as Windows 2015 XP.NET Plus Deluxe) is just a scary story parents tell to their children to make them behave; it doesn't really exist. "If you don't go to bed right now, Longhorn will eat all your RAM and make you lag!"
If you want more "up-to-date" packages, run Testing (currently Etch) or Unstable (always Sid). The packages are still in the process of being tested and migrating to a stable state, but the latest bells and whistles can be found there for you to play with if a pretty GUI is all you need.
I run Testing as a Desktop environment, and Stable (OldStable until the security updates year is over) for servers. Works very well. More toys for my desktops, servers never go down, and all I have to do is apt-get update; apt-get upgrade to keep up with security patches.
If I recall correctly, in expert mode the installer will ask if you wish to configure manually instead of DHCP-ing prior to actually doing any configuration. Might be a little easier than the disable_dhcp parameter.
(Personally I have a dhcp3 server running on the network, handing out IPs based on MAC addresses, so my machines get configured fully in that DHCP step, including correct hostname, unless I've changed the network card and failed to update the records)
Actually, the motherboard runs at room temperature in that setup, he said (22-24c). Also, the CPU is running a stock heat sink/fan combo, which would be the limiting factor for getting heat out of the processor core.
I have to say that I find that leaving the side off a case will usually bring the temperature down to a level that's equivalent to the fan-case anyhow. My current ambient temperature is 27C and the motherboard is running 30C (just 3C higher). Processor is running 47C, which isn't bad for AMD with stock cooling kit. (Used to run about 36C and 68C with the case side on)
They'll never do that. That would be intelligent. Instead, they're going to inflict some object-oriented/.net bullshit on admins that will make them cry for the return of command.com/cmd.exe.
I think the whole "shifting" thing is beyond most people's ability anyway
I've had that thought from time-to-time as well.
I'm shopping for a new car with (a) 4 doors, (b) rear wheel drive, and (c) a stick shift. I'm amazed at what a tiny niche I apparently occupy!
Yeah, most four-doors are going to be front-wheel-drive and mostly automatic. To find something like that, you'd either have to have it built from a kit, or buy one of the old classics.
Personally, I've always wanted a 2-door manual with a mid-mounted engine, but aside from the Toyota MR2 (not available in Canada, probably not in production anymore either), I think I'd have to buy a supercar, and I'd really not want to drive anything that requires a mortgage.
What if you need to swerve around a child running into the road. You think you can do that properly with one hand?
If you can't perform emergency maneuvers at full speed with one hand, you shouldn't be driving. What if you have to shift during these maneuvers? Or ARE shifting when the need arises to maneuver? It's not like these things don't have power steering/power assist steering.
You should be able to turn your wheel lock-to-lock with one hand just as quickly as with two. You should be able to do this without removing your hand from the wheel, also. If you cannot, you need practice.
I do agree with putting down the phone though -- concentration is king. Mr. SMS should be paying 100% attention to driving regardless of how many hands he has on the wheel.
So If I drink 18 beers and wake up in the morning sober and full of energy I can't drive until six in the afternoon?
It's supposed to be a constantly running thing - if you drink one beer per hour for 18 hours, you'll only have to wait one hour at the end, in theory. However, I'd still wait until six still, unless I managed to get my hands on a known-good breathalyzer unit. Those big concrete bridge supports can withstand a tank ramming into them...I'd hate to test it with my car.
As I mentioned above in another reply, it's the stated guideline, but there's always exceptions.
Oh, and here in Canuk-ada, you can be arrested for intoxicated driving even if you pass electronic tests. The police do that "touch your nose" and "walk the line" thing too if they have reasonable suspicion of "alternative" or magically undetectable intoxication.
It's the guide that's given to us here in Canada. Obviously there's always exceptions (eg. the guy in the thread who can tank 18 beers, or this girl I know who weighs all of 45kg and can drink most 120kg guys under the table, or this guy I know who passes out after breathing bar air for 15 mins), so caution should always rule when in the control seat of 2000KG of steel death.
That's where my second or third guidelines take over.
Well, if it will turn out to be a preprequel-trilogy, shouldn't it start of at "Episode -2"?
That depends. Does he want to use zero? "Episode 0: Return of the Revenge of the Jedi-Sith Gungans"?
Or maybe it's all a moot point, as the movie industry droids might take a negative number to mean an error, and will be trying to figure out why errno is a random number.. (or maybe it won't be, but will be ETOOMANYPREQUELS)
Bear in mind that this is the first generation that's been online out of the box. Sure it's nothing for us PC gamers, but these consoles are going to open up a door for non-PC gamers to play all their favourite games against real people - the difference between AI and real people isn't something to be sniffed at as "same old song and dance"
Same old song and dance. Why do you think old home computers and consoles have multiple joystick ports? MANY old games were also multiplayer, and did -not- require high speed internet, and did -not- have any lag at all. One small step for man.. one giant leap backwards.. for mankind. Multiplayer is hardly new.
$399 gets you better graphics AS WELLL AS... faster framerates, more intelligent AI, Better Physics, more realistic everything. I understand that it also has to be fun, but the less physical limits the game-makers have, the more likely they will make something that IS fun.
I'd have to say that -fun- seems to take a back seat when "r0x0r graphix!!11" becomes the focus.
I have to say that playing MULE(c64), Racing Construction Set(c64), or even Turbo(A500) with a friend or two is much more -fun- than.. Doom 3.
I'd go out on a branch and even guess that the better you are at making pretty games, the worse you are at making fun games. It's a very different sort of creativity.
Well, if risk of death is a good reason to avoid things, perhaps we should totally ban cars from any usage. They kill about 40,000 people a year down south in the States. (a random googled reference, find your own if you doubt the number)
Obviously caution is warrented in any such project, but let's not get worked up over some dock workers who -might- be at risk if a major catastrophe occurred. Hell, they would have been killed the next week in an auto accident anyways.
I haven't been big on designing my own Windows icons because, before I gave up looking, all icon editors cost $$. Inexplicably the one format Paint doesn't support is *.ico
I believe the official Microsoft way to make icons is via the Visual Studio developer kit. Worst $500 icon editor ever.
I used to have some beauties on my Amiga, and they could be any size I liked, up to the whole screen if that was your wish. IIRC they were easy to draw with something that came with the operating system.
It was a <sarcasm>really counter-intuitive</sarcasm> name, "IconEdit". It was in the Tools folder on your system drive (or disk if/when you used floppies)
Slashdot Mirror
Aah, so we'll use the processor's floating point unit(s) to add to all coordinates instead of the 3D card's T&L processing unit during the absolutely required and unescapable matrix transforms? Even in Ortho2D mode, both projection and modelview matricies are in use. The upside of that is that the Transformf/d is effectively done in T&L hardware once the matrix is set up. Unless, of course, this hardware is already tied up doing something else, or doesn't exist to begin with.....
Buffers aren't like magical queues that have no overhead for syncronization and filling. Something's going to have to do this work, and guess what? The CPU/motherboard chipset is the final arbiter of all bus operations.
I tend to stay away from DirectX as I detest 90 meg downloads (part of the bloat I mentioned), vendor lock-in and MS/Com/Com+/brain damage.
Note that 2D _is_ an issue in OpenGL, which effectively is never really 2D. All internal ops are performed in four dimensions, with W=1 during normal 3D ops, and Z=0 during "2D" ops. Most particle systems use billboarding, which incidentally, is CPU-bound as the card typically doesn't give you an API to cross product or normalizing functions. (Getting a raw raster image into 3D space would be.. ugh, Un/ProjectMatrix crap)
If you don't have a texture/pixel object for EACH window, where is the window coming from when it's being redrawn? ... PROCESSOR MEMORY? There must either be a texture/object for each window on the screen being handled by OpenGL, OR it must be reloaded from system ram (ooh so fast, requires muchly painful CPU intervention), which will either make the aforementioned bloating become real in the former case, (recall that textures typically have to be square, really efficient for rectangular windows) or for the supposed performance/efficiency to vanish in the latter case.
NOte that mipmaps don't take much memory, and if you don't use them, the mipmap support structures must still be in place. Remember that the second mipmap is a quarter of the size of the first, and that the third is a quarter of the size (memorywise, of course) of the second. It's the main texture that bloats up all the memory, relatively speaking.
Actually 12 million triangles would overflow most cards memory by a wide margin, just on verticies alone, unless your card manages to store them efficiently.
Oh hell yah, that ATI Charger was upgraded to 512KB at a cost of um.. $70! It is the total pwn now.. ..or it was, at least, lol
If you aren't using Translate, your pixel/poly ops will not align correctly with point and line ops (see appendix H of your red book) - this can be seen in certain Accolate products :P
Aah, so the GPU is now responsible for system heap allocation. Glad to know a non-local processor is handling memory allocation. This still involves considerable CPU intervention, especially with the allocation and management of these 1.5-only objects. When you're updating verticies, what do you think is happening? Some magical GPU prediction of your next update? This all still has to be processed by the OpenGL pipeline, which is deep and complex and interlaced with both CPU and GPU interactions (Read the Apple Developer Guide).
Also, consider this: While your OS is bloating up the video memory, what's happening to your 3D applications? They don't mind that suddenly you have half the texture memory, or that something is consuming GPU time?
To quote Dave Haynie, even crappy architecture is fast when run at 200mhz. I haven't seen anything that ISN'T fast-looking lately. Especially since Dave's 200mhz is now more like 2000mhz. However, the magic is in not using up all the resources _before_ the application starts. My old Amiga 1200 could boot up in seven seconds (including POST) off of a generous 12-meg partition, and surf the web while running multiscreen IRC sessions and a few FTP clients, with 2 megs of video ram and 4 megs of fast ram. I'm just waiting for the next version of Windows/MacOSX/Redhat to announce memory requirements that cannot be handled by a 32-bit addressing range.
2D blit setup is less than trivial unless there's overlapping regions, and then it's just _trivial_. Integer conversions are also less than trivial, bit ops are sub-cycle for a processor, and sub-sub-cycle for a proper blitter. Floating-to-integer conversions are much less trivial, as floats are more complex and totally incompatible with integers, and require serialized operations (you cannot shift the mantissa until you've extracted and subtracted the exponent down to it's real level, whereas you can extract all four color components and recombine them in an orderless manner (r|g|b is equal to b|g|r which is equal to r|b|g which is..) ) which will not take advantage of modern pipelined _anything_.
Quoting from Apple, "In OpenGL, there are several obvious and other not-so-obvious ways to cause either the CPU or GPU to stall on the other." ... I'm complicating it because it is complicated, and complicated = evil in computing. See above regarding "Fast".
This ATI Charger 512 does not support ANY of that (nor blitting for that matter), and this Rage II here only has the basic rasterization. I don't really know the specs for this S3 Trio64, but I doubt it's more than basic rasterization too, and rather slow rasterization at that. Also see the
I dunno about that, OpenGL is rather CPU bound. Much of the OpenGL pipeline is still done by the processor, and the primitives for OpenGL are often optimized for fully 3D rendering, which is more than a little unoptimized for 2D blitting. glTranslate3f ?
A 2D-specific blitter is a simple matter of setting up a few registers and letting it happen. A 3D operation in OpenGL has to be converted to native formats, be processed through the fragment pipeline, and then multiplied through several matrix operations before anything happens. While a modern T&L card does much of the more costly things involved in this, there's still all the necessary conversion and setup which is done by the processor.
Some of these OpenGL operations may require serialization, which might even involve a hidden busy loop, depending on how defective the operating system/drivers is/are.
While much of this may be relatively trivial on a modern, ghz-scale system, anything that is taking away from my BOINC credits is teh devil, I say! (Plus one day, you might end up stuck on a lesser machine, waiting for the parts store to open...)
(NB. most of this work is required for a 3D application, so OpenGL operates efficiently when playing Quake IV, as all of these operations would be necessary in any system, save perhaps the type conversion.)
Sometimes I wish it had died. The post-Commodore times were horrible - all that fighting, failed next gen machines, broken promises, missed deadlines, successor confusion.
I still would have liked to see a AAA based system with a fully functional OS, or Phase5's design in action. Think of a GUI designed for advanced hardware overlays instead of layers...
I wonder if a new system could be built around AMD/EMT64 .. the 16 multipurpose registers are very much like the 68K's 16 multipurpose registers... naah, too costly.
I'm pretty sure that if you looked deep down into definitions, you'd find that an AMD system is "x86-compatible" rather than just plain "x86". Especially if you're reading Intel's dictionary and/or legal contracts.
Further, if that's the actual quote, that may very well mean that it compiles faster than any other x86 compiler... not that it makes faster code. Typical market-droid logic/doublespeak.
Yet, even with all these shenanigans going on, at $400, it's only about half of Microsoft's offering... Half the processor compatibility, half the price. Heh.
I resent that. I optimize my inner loops (and the outer loops, and even the startup initialization data is cache aligned...) and develop games and I use MS VC6 for Windows and GCC for Linux/*BSD* exclusively.
What sort of silly person would expect an INTEL compiler to generate decent AMD code anyways? While I didn't expect intentional sabotage, I'm not entirely surprised either. It's not like it's in Intel's best interest to spend millions on creating an optimizing AMD compiler.
We're talking about the brave new world of digital rights management. You may implement the copy protection, but only if you really feel like it, and if it isn't too inconvenient.
(small print: failure to implement the copyright protection will result in immediate arrest, followed by an execution)
The rusty old world of IETF, sense, logic, and reason is gone. The new world is run by the disgusting alliance of the marketing and legal departments.
It's not delayed, it's fashionably ahead of the fallback schedule!
Please this correction: "Except Longhorn is a mythical Software Operating System.
Longhorn (also known as Windows 2015 XP .NET Plus Deluxe) is just a scary story parents tell to their children to make them behave; it doesn't really exist. "If you don't go to bed right now, Longhorn will eat all your RAM and make you lag!"
I run Testing as a Desktop environment, and Stable (OldStable until the security updates year is over) for servers. Works very well. More toys for my desktops, servers never go down, and all I have to do is apt-get update; apt-get upgrade to keep up with security patches.
If I recall correctly, in expert mode the installer will ask if you wish to configure manually instead of DHCP-ing prior to actually doing any configuration. Might be a little easier than the disable_dhcp parameter.
(Personally I have a dhcp3 server running on the network, handing out IPs based on MAC addresses, so my machines get configured fully in that DHCP step, including correct hostname, unless I've changed the network card and failed to update the records)
Actually, the motherboard runs at room temperature in that setup, he said (22-24c). Also, the CPU is running a stock heat sink/fan combo, which would be the limiting factor for getting heat out of the processor core.
I have to say that I find that leaving the side off a case will usually bring the temperature down to a level that's equivalent to the fan-case anyhow. My current ambient temperature is 27C and the motherboard is running 30C (just 3C higher). Processor is running 47C, which isn't bad for AMD with stock cooling kit. (Used to run about 36C and 68C with the case side on)
They'll never do that. That would be intelligent. Instead, they're going to inflict some object-oriented/.net bullshit on admins that will make them cry for the return of command.com/cmd.exe.
Windows: Bigger, Slower, Buggier.
I've had that thought from time-to-time as well.
Yeah, most four-doors are going to be front-wheel-drive and mostly automatic. To find something like that, you'd either have to have it built from a kit, or buy one of the old classics.
Personally, I've always wanted a 2-door manual with a mid-mounted engine, but aside from the Toyota MR2 (not available in Canada, probably not in production anymore either), I think I'd have to buy a supercar, and I'd really not want to drive anything that requires a mortgage.
If you can't perform emergency maneuvers at full speed with one hand, you shouldn't be driving. What if you have to shift during these maneuvers? Or ARE shifting when the need arises to maneuver? It's not like these things don't have power steering/power assist steering.
You should be able to turn your wheel lock-to-lock with one hand just as quickly as with two. You should be able to do this without removing your hand from the wheel, also. If you cannot, you need practice.
I do agree with putting down the phone though -- concentration is king. Mr. SMS should be paying 100% attention to driving regardless of how many hands he has on the wheel.
It's supposed to be a constantly running thing - if you drink one beer per hour for 18 hours, you'll only have to wait one hour at the end, in theory. However, I'd still wait until six still, unless I managed to get my hands on a known-good breathalyzer unit. Those big concrete bridge supports can withstand a tank ramming into them...I'd hate to test it with my car.
As I mentioned above in another reply, it's the stated guideline, but there's always exceptions.
Oh, and here in Canuk-ada, you can be arrested for intoxicated driving even if you pass electronic tests. The police do that "touch your nose" and "walk the line" thing too if they have reasonable suspicion of "alternative" or magically undetectable intoxication.
It's the guide that's given to us here in Canada. Obviously there's always exceptions (eg. the guy in the thread who can tank 18 beers, or this girl I know who weighs all of 45kg and can drink most 120kg guys under the table, or this guy I know who passes out after breathing bar air for 15 mins), so caution should always rule when in the control seat of 2000KG of steel death.
That's where my second or third guidelines take over.
Here's a rational thought:
One shot of hard alcohol = one wineglass of wine = one bottle of beer = one FULL hour not driving.
Or if math is too hard:
I've been drinking alcohol tonight. It does not matter how much, I will not be the driver.
Or if an obsessive-compulsive "drinking and gadgets" disorder is present in the person:
There's fifty thousand different types of alcohol analyzers out there that you can buy already. Buy one.
That depends. Does he want to use zero? "Episode 0: Return of the Revenge of the Jedi-Sith Gungans"?
Or maybe it's all a moot point, as the movie industry droids might take a negative number to mean an error, and will be trying to figure out why errno is a random number.. (or maybe it won't be, but will be ETOOMANYPREQUELS)
Same old song and dance. Why do you think old home computers and consoles have multiple joystick ports? MANY old games were also multiplayer, and did -not- require high speed internet, and did -not- have any lag at all. One small step for man.. one giant leap backwards.. for mankind. Multiplayer is hardly new.
I'd have to say that -fun- seems to take a back seat when "r0x0r graphix!!11" becomes the focus.
I have to say that playing MULE(c64), Racing Construction Set(c64), or even Turbo(A500) with a friend or two is much more -fun- than .. Doom 3.
I'd go out on a branch and even guess that the better you are at making pretty games, the worse you are at making fun games. It's a very different sort of creativity.
Lol.. I'd love that.
...I see your Schwartz is as big as mine. Now, let's see how well you handle it...
Hey, I've never done anything to you.
Oh, Renegade programmers. No second R. Nevermind.
Well, if risk of death is a good reason to avoid things, perhaps we should totally ban cars from any usage. They kill about 40,000 people a year down south in the States. (a random googled reference, find your own if you doubt the number)
Obviously caution is warrented in any such project, but let's not get worked up over some dock workers who -might- be at risk if a major catastrophe occurred. Hell, they would have been killed the next week in an auto accident anyways.
I believe the official Microsoft way to make icons is via the Visual Studio developer kit. Worst $500 icon editor ever.
It was a <sarcasm>really counter-intuitive</sarcasm> name, "IconEdit". It was in the Tools folder on your system drive (or disk if/when you used floppies)
(Sys:Tools/IconEdit)