If you actually read the claims of the patent, it only covers doing motion estimation on the GPU and everything else on the CPU. This seems like a rather obvious part to offload to 2004's marginally-programmable GPUs.
Don't the same forces at work in the Monty Hall Problem make it not 50/50, or does the fact that the eliminated "losers" were randomly selected without foreknowledge that they're losers make it 50/50?
The article mentions a new location coming is San Jose this year, but their locations page doesn't. Anyone have more details about this? San Jose would be a lot more convenient for those of us on the other end of 17 from the valley.
Neither. The client/server confusion comes from the use common with internet/web applications. The "client" is the piece the user interacts with and the "server" has the application logic. By that user-centric logic, however technically incorrect it may be, X's names ARE reversed.
This is interesting for people considering a DC-powered server room. The Mini uses 18.5V DC with an external AC-DC converter. No hardware modifications required to run off a DC supply.
You're close to right. There's been a lot of work on completely non-spatial distributed server architectures (mostly using distributed hash tables and occasionally multicast between servers) but they don't scale as well as expected. There's a reason for spatial partitioning - things close to each other tend to interact more.
Fixed partitioning is the easy way to do spatial partioning - you drop boundaries and migrate objects that cross them. Often you use design to allow interaction between partitions to be ignored, so you don't need any communication between servers besides migration. Dynamic partitioning would largely solve this problem (as, generally, you're never actually in a region where you can interact with more than a several dozen other players) but is HARD if you want consistency.
Guaranteeing instantaneous consistency is impossible - you've got hundreds to thousands of servers and keeping them all in lockstep at 30Hz with a potential for same-frame interaction between objects just isn't going to happen. Instead, what if you thought of the game as a simulation of abstract moore machines. Every frame each object looks at the state of of the wold and then sets it's state for the next frame and maybe creates other objects. Inter-object events can be modeled as objects that exist for a single frame and the receiver looks for. This means no instantaneous inter-object communication, but that's generally acceptable and likely unavoidable.
Now, network latency between servers could still be a problem: as the system grows it's impossible to keep it in lock-step even with the slightly relaxed communication requirements. This can be solved by employing a technique used in distributed databases: eventual consistency. Lets explicitly allow inconsistent state to exist between servers instantaneously, but guaranty that it will be eventually be resolved. Lets have objects use a subscription model for their observations and send those subscriptions to all servers that might contain matching objects. When a server sees an object matching a remote subscription it sends over the object with enough state to run a dumb predictor (that can't look at the dynamic state of any other objects). The server with the subscribing object can then use that state and predictor to keep the object in sync and then service the actual subscription. Back on the server with the object that mached the subscription, it makes a local copy of the proxy it sent. It updates the copy along the the rest of the work, and compares it with the real object to detect when the remote server made an incorrect prediction. In this event, it sends an update to the subscribing server with the new state.
Now you should say, "Wait! That update won't arrive until the server had already run the simulation for that frame!". Yep, you're probably right. However, because there's this subscription data available, the server can very efficiently re-run the simulation, touching only objects that might have detected the change (and any consequential changes). This might cause further updates to other servers, but because of generally sparse nature of interactions in games, the state on all servers for a given frame will quickly be consistent.
This was almost my thesis before I got pulled into graphics and wii remotes. If this interests you and you'd like to see an early paper about it, drop me a line: [my_username]@[my_username].org.
As a Google Voice user, I was confused when I tried to call a free conference call service and my phone never rang. No error message and the web UI acted like it was placing the call. I tried through the dial-in interface and got "that number is not valid" or something to that extent. They could at least explain WHY they're not allowing the call to go through.
Map files for unreal-engine games contain, among many other things: * source geometry objects * compiled BSP tree * lights * baked lightmaps * source of any map-specific scripts * bytecode-compiled map-specfic scripts
The source data isn't used by the game at runtime (save dynamic lights) but if you point the editor at any shipped map its all there (except 3rd party maps that have been cleaned/obfuscated). The same goes for the UnrealScript source of the engine itself: it's all available in the various.u files along with the bytecode the game actually executes. The only parts of an Unreal game that isn't source-available are the low-level native code bits of the engine: graphics, AI pathfinding, sound, etc.
The firmware gets involved when the save file is copied from the SD card to the internal memory. Since the save can't be copied off the SD card directly, they can just verify the save before they copy it. Alternately, the games probably use an API from firmware to access save data. They could special case accesses from RZD* and verify at that point.
Slashdot Mirror
If you actually read the claims of the patent, it only covers doing motion estimation on the GPU and everything else on the CPU. This seems like a rather obvious part to offload to 2004's marginally-programmable GPUs.
Don't the same forces at work in the Monty Hall Problem make it not 50/50, or does the fact that the eliminated "losers" were randomly selected without foreknowledge that they're losers make it 50/50?
Hey, at least they didn't resort to Libraries Of Congress Per Month.
jdb/vd312416.jdb?
That wasn't there when I posted my comment. Guess they read slashdot ;).
FYI: I'm a college student and I drive a '91 Honda.
The article mentions a new location coming is San Jose this year, but their locations page doesn't. Anyone have more details about this? San Jose would be a lot more convenient for those of us on the other end of 17 from the valley.
There goes any hopes for Pink Floyd on Rock Band or Guitar Hero...
I came here to say that. Seriously great work until the 2G1C reference.
The reporting agencies directly:
http://www.transunion.com/
http://www.equifax.com/home/en_us
http://www.experian.com/
Neither. The client/server confusion comes from the use common with internet/web applications. The "client" is the piece the user interacts with and the "server" has the application logic. By that user-centric logic, however technically incorrect it may be, X's names ARE reversed.
This is interesting for people considering a DC-powered server room. The Mini uses 18.5V DC with an external AC-DC converter. No hardware modifications required to run off a DC supply.
You're close to right. There's been a lot of work on completely non-spatial distributed server architectures (mostly using distributed hash tables and occasionally multicast between servers) but they don't scale as well as expected. There's a reason for spatial partitioning - things close to each other tend to interact more.
Fixed partitioning is the easy way to do spatial partioning - you drop boundaries and migrate objects that cross them. Often you use design to allow interaction between partitions to be ignored, so you don't need any communication between servers besides migration. Dynamic partitioning would largely solve this problem (as, generally, you're never actually in a region where you can interact with more than a several dozen other players) but is HARD if you want consistency.
Guaranteeing instantaneous consistency is impossible - you've got hundreds to thousands of servers and keeping them all in lockstep at 30Hz with a potential for same-frame interaction between objects just isn't going to happen. Instead, what if you thought of the game as a simulation of abstract moore machines. Every frame each object looks at the state of of the wold and then sets it's state for the next frame and maybe creates other objects. Inter-object events can be modeled as objects that exist for a single frame and the receiver looks for. This means no instantaneous inter-object communication, but that's generally acceptable and likely unavoidable.
Now, network latency between servers could still be a problem: as the system grows it's impossible to keep it in lock-step even with the slightly relaxed communication requirements. This can be solved by employing a technique used in distributed databases: eventual consistency. Lets explicitly allow inconsistent state to exist between servers instantaneously, but guaranty that it will be eventually be resolved. Lets have objects use a subscription model for their observations and send those subscriptions to all servers that might contain matching objects. When a server sees an object matching a remote subscription it sends over the object with enough state to run a dumb predictor (that can't look at the dynamic state of any other objects). The server with the subscribing object can then use that state and predictor to keep the object in sync and then service the actual subscription. Back on the server with the object that mached the subscription, it makes a local copy of the proxy it sent. It updates the copy along the the rest of the work, and compares it with the real object to detect when the remote server made an incorrect prediction. In this event, it sends an update to the subscribing server with the new state.
Now you should say, "Wait! That update won't arrive until the server had already run the simulation for that frame!". Yep, you're probably right. However, because there's this subscription data available, the server can very efficiently re-run the simulation, touching only objects that might have detected the change (and any consequential changes). This might cause further updates to other servers, but because of generally sparse nature of interactions in games, the state on all servers for a given frame will quickly be consistent.
This was almost my thesis before I got pulled into graphics and wii remotes. If this interests you and you'd like to see an early paper about it, drop me a line: [my_username]@[my_username].org.
As a Google Voice user, I was confused when I tried to call a free conference call service and my phone never rang. No error message and the web UI acted like it was placing the call. I tried through the dial-in interface and got "that number is not valid" or something to that extent. They could at least explain WHY they're not allowing the call to go through.
Considering GNOME is affected, it's probably libxml2.
Map files for unreal-engine games contain, among many other things:
* source geometry objects
* compiled BSP tree
* lights
* baked lightmaps
* source of any map-specific scripts
* bytecode-compiled map-specfic scripts
The source data isn't used by the game at runtime (save dynamic lights) but if you point the editor at any shipped map its all there (except 3rd party maps that have been cleaned/obfuscated). The same goes for the UnrealScript source of the engine itself: it's all available in the various .u files along with the bytecode the game actually executes. The only parts of an Unreal game that isn't source-available are the low-level native code bits of the engine: graphics, AI pathfinding, sound, etc.
Tonic is purely peer-to peer and discovers everyone on your broadcastable subnet.
http://r2.com.au/software.php?page=2&show=tonic
Me two.
I believe you mean Aperture Science Vital Apparatus Vent.
The firmware gets involved when the save file is copied from the SD card to the internal memory. Since the save can't be copied off the SD card directly, they can just verify the save before they copy it. Alternately, the games probably use an API from firmware to access save data. They could special case accesses from RZD* and verify at that point.
A Wii Remote would be more ideal.
Headline is inaccurate - he got voted off the island.
The "Modified version" has IR tracking.
The "modified version" has that. No calibration needed even.
The Wii Remote is just a Bluetooth HID device.