Which of cause is a total bogus argument. When you count by hand you don't let one guy do the job, but instead you take one person for every 150 voters (at least thats the numbers from Germany). When you do it that way you have no scalability problem at all, it simply doesn't matter if 300 people vote or 300'000'000. It is a perfectly parallelizable problem and 'sheer numbers' are a complete non-issue because the amount of stuff a person has to count stays constant.
The only real problem with paper voting is that it can't be easily tampered with, which of course is a big issue for certain people.
For sculpting you would need exact 1:1 mapping, which neither the normal Wiimote nor the add on provide. And even if you have 1:1 mapping you still would need feedback to make it really useful, so a Wiimote won't replace a haptic device anytime soon. However it might be possible to use it in the same way you use a SpaceNavigator, i.e. to navigate around in 3D space.
Although I hate using Red Steel as an example, that's one game where they had the option of making sword movements 1:1, but instead opted for simple movements because 1:1 movements would have made the game too complex to play for most people.
Thats marketing speech, the reason why Red Steel doesn't have 1:1 mapping is because the Wiimote simply can't do it. And heck, even if it could, it would likely get tricky to get a realistic response from the gameworld, i.e. you would need some pretty advanced collision detection and physics stuff to have characters behave realistic on a hit.
Motion sensing != IR Pointer function. The Wiimote has two sensors, one is a IR camera that 'sees' the IR-LEDs in the sensorbar, the other is a 3-axis accelerometer. The IR camera is used for the mouse pointer, while the accelerometer is used to detect your swings in tennis and other games. They are completly seperate and none of them really works all that well.
The IR camera itself is fine, but since the sensorbar only has two dots, so it can't give you precise aiming as one would expect from a lightgun. That the Wii's system menus don't provide any real calibration beyond 'above/below TV' of course makes matters even worse. The sad part here is that this would actually be easy to fix with another sensorbar, since the camera can register up to 4 IR dots.
The accelerometer on the other side is not so fine, while it does make its job as designed, acceleration in three axis are simply not enough to detect a position in six axis (pos + rotation). Which shows in a lot of games. Sometimes there are workarounds, but as a general it just doesn't work.
The Wiimote was kind of a nice first step into motion detection, but its still quite a bit away from providing real 1:1 mapping. The new MotionPlus addon will likely at a gyroscopic sensor, which should improve the motion detection quite a bit. But I still doubt that it will give real 1:1 mapping, that has probably to wait for the next generation of consoles.
The aiming in Metroid Prime 3 was ok, however the motion sensing was not, not even close. I did not have one second in the whole game in which the motion sensing (door opening, leaver pulling, grapple, etc.) felt natural, sure one could solve all of them without to much problem, because they where very short, but the motions on screen had basically never a real connection to your motion with the controller. Just random wiggle basically worked just as well as actually trying to mimic the real motion.
I've been pretty happy with it, sometimes the bar won't be set up right...
fine. Except of course that the bar as nothing to do with the motion sensing, its there to give you a cursor on the screen, not to detect your swings.
I think the problem is that developers are still learning how to use it well.
I think now that even Nintendo now admitted that the Wiimote can't do 1:1 we can end that discussion. It has nothing to do with 'developers still learning' and everything to do with the Wiimote simply not having enough sensory for real 1:1 mapping.
The "sensitivty" settings are basically just a brightness control for the Wiimote camera, they don't change anything in how the mouse cursor gets mapped to the screen. They are simply there to filter out other IR light sources that might cause trouble in the pointer detection. Settings to change the actually cursor mapping/calibration exist in a tiny few games, but not in the system menus, which kind of sucks, because it would be rather trivial to add and is really a important feature, given how different sized TVs can be.
If you like the BSD License you accept that not all software has to be BSDL'ed, so the GPL shouldn't be a problem for you, since its just another non-BSD license.
If you like the GPL on the other side you are free to incooperate BSDL code into your GPLed application and you should simply welcome the additional free code out there.
No need to fight, everybody should be happy with the way it is.
When you succeed in manipulating a ballot box, you have manipulated exactly one ballot box with a good chance of being catched in the process, if you try the same with electronic voting machines you can manipulate dozens, hundreds or even thousands at once without anybody having a chance of noticing anything.
I know this may not be a popular question, but what is the point with raytracing for games? The core idea is that rasterization scales linear while raytracing scales logarithmically, i.e. when you have few polygons, rasterization is faster, but when you cross a certain threshold on the number of polygons, raytracing wins. As a nice side effect raytracing can also do some things easily that are hard with rasterization, like reflection.
The whole debate of course is if we have already crossed that threshold or even if we ever will, since the whole thing only works out for the very basic algorithm. When you have a whole game with dynamic stuff that raytracing doesn't like and have engines that chose which polygons they render, instead of just brute-forcing all of them down the rasterizer things get a lot more complicated. And when you add shaders into the mix it gets completly crazy, since you can even do raytracing inside a shader of a rasterization engine.
For the enduser it really is a total non-issue right now. For one thing the raytraced demos just don't look good enough to really impress and then they also need far more CPU power then anybody currently has. And for backward compatibility reasons we will continue to have GPUs for quite a while to come. Maybe things will change with Playstation4 or whatever comes next, but in the end its at the moment more a marketing action from Intel then anything else, since well, they aren't good in GPUs, but they have all those CPU cores where they don't know what to do with them, so raytracing seems like a problem that fits their solution.
So what are ya'll bitching about? Just because the copy-protection is less evil then others doesn't make it good, it simply makes it less evil. The basic problem of copy-protection is simply that it always goes again the paying customer, not against the pirate. The paying customer will have the problems, the pirate will have a cracked copy. And there is of course the other problem that I have yet to see some hard numbers that copy-protection actually works. In some cases the pirated copy is simply used as an unauthorized demo, in other cases its just downloaded to 'have it' not to use it, in other cases the pirate simply doesn't have the money to buy it and sometimes there might be people that would actually have bought it if they wouldn't have been able to download it for free, but then those often don't have to wait long for a crack. I simply haven't seen numbers that prove that copy-protection turns pirates into customers and that that effects is bigger then the lost advertisment.
I would prefer it when companies would focus on doing something for the paying customer, instead of against him. Bring back the big boxes full of extras, manuals, maps and stuff and a payed copy might actually have an advantage over a pirated one.
I fear that if I released it, not even the version I have now, but future snapshots, it would get uploaded to all the shareware sites, where it would be downloaded by unsuspecting novice users, who would find it unpleasant to use. Thats what we have CVS/SVN/Git and friends for. Simply don't release it in tarball form until it is ready, instead just dump it into a public repository and be done with it. The repository will make sure that no shareware sites pick it up and that distris stay away from packaging it. It will also make sure that the end user gets that it isn't done yet.
That wouldn't serve their needs, and further, it would give me and my project a bad reputation. It doesn't have to serve a need, it simply has to be there to take a look. If nothing else just to see that it is actually real and not just one of the thousands of vaporware projects on sourceforge. By just having a webpage up and no code you are basically wasting peoples time.
I know that I have the greatest chance of success if I wait until I have something rock-solid before I make its first public release. On the other side the bus-factor can kick in and we are left with nothing but an empty webpage. It has happened before, it will happen again and maybe to you.
but I believe this is too much of a hassle for people who can't even figure out Yahoo Mail or tell the difference between Internet Explorer and Firefox. Its not only to much hassle, it also doesn't really provide half as much security as one would expect. The header gets send completly unencrypted, so To, From, CC and stuff are easy to read, Subject sometimes to. And for a government it can often be enough to know your peers, the exact content isn't that important and if it is it can be retrieved by more drastic measures (keylocker, etc.). There is of course another issue in that when you sign your emails you lose deniability, so one should better not do that when one wants things to stay secret.
Overall GPG and friends don't really solve the problem. You simply can't fix a broken government with software, you have to fix the government itself.
Why would it be needed when upgrading the Linux kernel is a matter of download/compile/boot. Because kernels are not backward compatible forever and ancient applications and libraries often don't like running on modern kernels, just like modern applications and libraries don't like running on old kernels. Try running some of the early Loki games or many other ancient binary releases on a current system and you have some fun. Binary compability is simply terrible on Linux and even having the source often doesn't help without a lot of extra work.
Nethack example again, that's why noone actually uses tilesets in Nethack, too. The problem with tiles in Nethack is that they don't fix the underlying structure of the game, i.e. in many tiled-nethack clients you still can't tell the difference between a wall and unexplored terrain, both look the same. Same is true with character movement and tons of other stuff. This is more awkward in tile graphics then in ASCII, because tiled graphics normally don't behave like that, they have enough expressiveness to properly represent walls and stuff, while ASCII stuff often behaves exactly like that due to the limited character set.
but merely demonstrating they are getting closer! But are they really getting closer? I have seen demos of shiny raytraced spheres rendered a decade ago on the Amiga, seening those spheres now again in Doom or QuakeWars isn't exactly impressive. Those spheres are pretty much the "Hello World" of raytracing world. I still miss a demonstration of something impressive that my current graphics card couldn't do, shiny spheres alone just don't do it here.
One day maybe, but not today and not tomorrow. Raytracing still has a very long way to go. And even if it ever happens its far from clear that it will happen in this simplistic form. When one is rendering normal polygonal 3D models raytracing simply has very few practical advantages and most games do fine without shiny spheres. The ability to render more polygons is also not really all that important, normal mapping already gets a 5'000'000 triangle model down to a 10'000 triangle model with a very small loss of detail. And for most stuff you don't really have the time or money to model all that detail in the first place.
In the end one also has to keep in mind that the picture that appears on the screen isn't just a simple straight forward rendering these days. A lot of post processing is applied to it, often on the depth-buffer directly and thus completly outside of classic raytracing or rasterization domains.
Raytracing simply isn't a magic bullet. If we have hardware that is fast for raytracing, we will surely find some use for it, but we won't just throw out our GPUs because of that.
And lets not forget backward compability, even if raytracing would be the magic bullet, you wouldn't want to lose backward compability to pretty much all games created in the last 10 years.
Noone would want ray-trace-quality graphics in their games? Realtime raytracing as demonstrated here is good for shiny spheres and little else. I don't know about you, but I have rather little use for shiny spheres in my games and if I do a little fake environment map does the job quite well.
How realistic a rendering looks simply has nothing to do if you rasterize or raytrace, its just a different approach to get pixels on the screen. Global illumination and all that stuff is what matters when you want a really realistic look, but you don't get that for free with either rasterization or raytracing. And when it comes to graphical progress in the last years, a lot of stuff is happening on the framebuffer itself, and is as such completly independed of the way your geometry rendering works.
Anyway, I'd be impressed when they manage to render something that looks *better* then current games, not when they manage to render old games with a crappier look, less fps and a few shiny spheres added.
I've always wanted a realtime graphics engine based on something like the POV-ray ray-tracer CSG can work with a rasterizer, see for example Ensemblist. The problem with CSG however is that it just isn't very practical for game modeling, its nice for industrial work where you want to have exactness, but not for games where you want it pretty and want it fast. And of course CSG is rather useless when you want to model something organic like a human or a monster.
I guess it is simply time. They would need to rewrite all the pixel shaders for their raytracing stuff, they can't just use the the normal ones for the GPUs.
Or maybe cursing at the newbie because he didn't pay attention to the position of a specific lamp and now your team is screwed because your shadows have been noticed. Not really exciting, MetalGear2 had that, SplinterCell had something like that and plenty of other games had similar stuff (Doom3, etc.). You don't need raytracing for that and in terms of gameplay it doesn't really add much, since most games simply are not slow enough that you care about little details like shadows.
It is really no surprise that the OLPC doesn't sell well, since they aren't actually selling it. There are plenty of people who bought a Eee or maybe a N800/N810 who would have gone with a OLPC instead if they would actually had a chance to buy one. Over here in Europe there simply is no proper way to buy one and even G1G1 isn't really an alternative, first of it was only a time limited USA-only offer and secondly it is twice the price, which simply is to much to keep up with the competition. If people have the choice between $400 OLPC and $300 Eee, most will go with the Eee.
They really need to cut that elitist 'only for the third-world' bullshit and just sell the devices over regular retailers.
Slashdot Mirror
Sheer numbers.
Which of cause is a total bogus argument. When you count by hand you don't let one guy do the job, but instead you take one person for every 150 voters (at least thats the numbers from Germany). When you do it that way you have no scalability problem at all, it simply doesn't matter if 300 people vote or 300'000'000. It is a perfectly parallelizable problem and 'sheer numbers' are a complete non-issue because the amount of stuff a person has to count stays constant.
The only real problem with paper voting is that it can't be easily tampered with, which of course is a big issue for certain people.
For sculpting you would need exact 1:1 mapping, which neither the normal Wiimote nor the add on provide. And even if you have 1:1 mapping you still would need feedback to make it really useful, so a Wiimote won't replace a haptic device anytime soon. However it might be possible to use it in the same way you use a SpaceNavigator, i.e. to navigate around in 3D space.
Although I hate using Red Steel as an example, that's one game where they had the option of making sword movements 1:1, but instead opted for simple movements because 1:1 movements would have made the game too complex to play for most people.
Thats marketing speech, the reason why Red Steel doesn't have 1:1 mapping is because the Wiimote simply can't do it. And heck, even if it could, it would likely get tricky to get a realistic response from the gameworld, i.e. you would need some pretty advanced collision detection and physics stuff to have characters behave realistic on a hit.
Motion sensing != IR Pointer function. The Wiimote has two sensors, one is a IR camera that 'sees' the IR-LEDs in the sensorbar, the other is a 3-axis accelerometer. The IR camera is used for the mouse pointer, while the accelerometer is used to detect your swings in tennis and other games. They are completly seperate and none of them really works all that well.
The IR camera itself is fine, but since the sensorbar only has two dots, so it can't give you precise aiming as one would expect from a lightgun. That the Wii's system menus don't provide any real calibration beyond 'above/below TV' of course makes matters even worse. The sad part here is that this would actually be easy to fix with another sensorbar, since the camera can register up to 4 IR dots.
The accelerometer on the other side is not so fine, while it does make its job as designed, acceleration in three axis are simply not enough to detect a position in six axis (pos + rotation). Which shows in a lot of games. Sometimes there are workarounds, but as a general it just doesn't work.
The Wiimote was kind of a nice first step into motion detection, but its still quite a bit away from providing real 1:1 mapping. The new MotionPlus addon will likely at a gyroscopic sensor, which should improve the motion detection quite a bit. But I still doubt that it will give real 1:1 mapping, that has probably to wait for the next generation of consoles.
The aiming in Metroid Prime 3 was ok, however the motion sensing was not, not even close. I did not have one second in the whole game in which the motion sensing (door opening, leaver pulling, grapple, etc.) felt natural, sure one could solve all of them without to much problem, because they where very short, but the motions on screen had basically never a real connection to your motion with the controller. Just random wiggle basically worked just as well as actually trying to mimic the real motion.
I've been pretty happy with it, sometimes the bar won't be set up right...
fine.
Except of course that the bar as nothing to do with the motion sensing, its there to give you a cursor on the screen, not to detect your swings.
I think the problem is that developers are still learning how to use it well.
I think now that even Nintendo now admitted that the Wiimote can't do 1:1 we can end that discussion. It has nothing to do with 'developers still learning' and everything to do with the Wiimote simply not having enough sensory for real 1:1 mapping.
The "sensitivty" settings are basically just a brightness control for the Wiimote camera, they don't change anything in how the mouse cursor gets mapped to the screen. They are simply there to filter out other IR light sources that might cause trouble in the pointer detection. Settings to change the actually cursor mapping/calibration exist in a tiny few games, but not in the system menus, which kind of sucks, because it would be rather trivial to add and is really a important feature, given how different sized TVs can be.
If you like the BSD License you accept that not all software has to be BSDL'ed, so the GPL shouldn't be a problem for you, since its just another non-BSD license.
If you like the GPL on the other side you are free to incooperate BSDL code into your GPLed application and you should simply welcome the additional free code out there.
No need to fight, everybody should be happy with the way it is.
When you succeed in manipulating a ballot box, you have manipulated exactly one ballot box with a good chance of being catched in the process, if you try the same with electronic voting machines you can manipulate dozens, hundreds or even thousands at once without anybody having a chance of noticing anything.
Nothing, most/all(?) of their games work fine in Wine.
The whole debate of course is if we have already crossed that threshold or even if we ever will, since the whole thing only works out for the very basic algorithm. When you have a whole game with dynamic stuff that raytracing doesn't like and have engines that chose which polygons they render, instead of just brute-forcing all of them down the rasterizer things get a lot more complicated. And when you add shaders into the mix it gets completly crazy, since you can even do raytracing inside a shader of a rasterization engine.
For the enduser it really is a total non-issue right now. For one thing the raytraced demos just don't look good enough to really impress and then they also need far more CPU power then anybody currently has. And for backward compatibility reasons we will continue to have GPUs for quite a while to come. Maybe things will change with Playstation4 or whatever comes next, but in the end its at the moment more a marketing action from Intel then anything else, since well, they aren't good in GPUs, but they have all those CPU cores where they don't know what to do with them, so raytracing seems like a problem that fits their solution.
I would prefer it when companies would focus on doing something for the paying customer, instead of against him. Bring back the big boxes full of extras, manuals, maps and stuff and a payed copy might actually have an advantage over a pirated one.
Overall GPG and friends don't really solve the problem. You simply can't fix a broken government with software, you have to fix the government itself.
One day maybe, but not today and not tomorrow. Raytracing still has a very long way to go. And even if it ever happens its far from clear that it will happen in this simplistic form. When one is rendering normal polygonal 3D models raytracing simply has very few practical advantages and most games do fine without shiny spheres. The ability to render more polygons is also not really all that important, normal mapping already gets a 5'000'000 triangle model down to a 10'000 triangle model with a very small loss of detail. And for most stuff you don't really have the time or money to model all that detail in the first place.
In the end one also has to keep in mind that the picture that appears on the screen isn't just a simple straight forward rendering these days. A lot of post processing is applied to it, often on the depth-buffer directly and thus completly outside of classic raytracing or rasterization domains.
Raytracing simply isn't a magic bullet. If we have hardware that is fast for raytracing, we will surely find some use for it, but we won't just throw out our GPUs because of that.
And lets not forget backward compability, even if raytracing would be the magic bullet, you wouldn't want to lose backward compability to pretty much all games created in the last 10 years.
How realistic a rendering looks simply has nothing to do if you rasterize or raytrace, its just a different approach to get pixels on the screen. Global illumination and all that stuff is what matters when you want a really realistic look, but you don't get that for free with either rasterization or raytracing. And when it comes to graphical progress in the last years, a lot of stuff is happening on the framebuffer itself, and is as such completly independed of the way your geometry rendering works.
Anyway, I'd be impressed when they manage to render something that looks *better* then current games, not when they manage to render old games with a crappier look, less fps and a few shiny spheres added.
Raytracing simply isn't a magic bullet.
I guess it is simply time. They would need to rewrite all the pixel shaders for their raytracing stuff, they can't just use the the normal ones for the GPUs.
Ur-Quan Master is based on the original 3DO source code, so it is the 'real thing', its really not different from Doom or Quake in that regard.
It is really no surprise that the OLPC doesn't sell well, since they aren't actually selling it. There are plenty of people who bought a Eee or maybe a N800/N810 who would have gone with a OLPC instead if they would actually had a chance to buy one. Over here in Europe there simply is no proper way to buy one and even G1G1 isn't really an alternative, first of it was only a time limited USA-only offer and secondly it is twice the price, which simply is to much to keep up with the competition. If people have the choice between $400 OLPC and $300 Eee, most will go with the Eee.
They really need to cut that elitist 'only for the third-world' bullshit and just sell the devices over regular retailers.
The difference would be that the technology would be smarter then you and would have build itself.