Your quake era engines tend to go through and scan a quick and easy potentially visible list of convex cels, slap all of the objects and polygons contained therein up to the card and let the card sort it out.
Dynamic obscura such as half open moving doors, smoke grenades, aren't calculated into this. (well, most of the time, there are some optimizations for closed doors) largely because the overhead of sorting every a model into a span-buffer or beam-tree to check if it should be visible can be very high and doesn't scale linearly. (I had to do so once for an engine I designed to handle hard lighting) Even so, it probably won't catch 'visibility' hacks through alpha-translucent smoke.
It isn't being lazy to try to ship a product that runs when more than 3 people are visible on the screen. There is a certain point where pragmatic considerations come into play. Wildly varying frame processing times are not acceptable to the modern gamer. If your game slows to 4 fps so your machine can chooose exactly what polygons to render to eliminate one subclass of cheaps, you may feel a bit more secure, but you are still vulnerable to proxy based cheating methods, etc.
Add to this the fact that you have to allow for updates of light sources from every cel which can be seen from any point within any visible cel, there is a good reason for many of these games to give you enough information to 'see around corners', even if you can build an efficient enough culling algorithm that your server can just tell the client that there is a flashlight coming around the corner.
heaven forbid you want to do any secondary lighting, or play with realtime radiosity and need more information a the client.
Plus, you need to allow for the any motion prediction that is beeing ddone client side to smooth the action. this adds an additional fuzz factor, which in the interest of smoother operation might give the 'wallhacker' a hundred millisecond drop on the trusting mainstream gamer.
There is a certain amount of trust required for twitch gaming over the internet. if you want to build a 'secure' internet game go sell your soul to palladium while building up your network protocols over a public key infrastructure and hope that it is all that microsoft wants it to be, convert to a less twitchy game design. or preemptively build the cheats into the game to level the playing field.
I am not particularly fond of any of these options.
The argument that you can learn a small subset to be productive tends to bite you when you start trying to ramp up to multi-developer projects.
When you are provided with 20 different tools with which to accomplish a goal, developers are going to choose different ones, and if you eschew code ownership, each of them will have to be familiar with each other's favorite hammers to be able to make changes to each others code.
If you go in for code ownership then you wind up with no redundancy and a single developer holds you hostage.
In large scale development in such languages, if you have one high end programmer and several who are not so proficient with the language, the work-load gradually becomes unbalanced and you need an equally high-end programmer to replace your top guy when he leaves even if the code has devolved to maintenance and is not actively in production.
In a perfect world he may have left you clean interfaces and functional documentation, but the variety of syntactic sugar available can make maintenance difficult and expensive.
Do you think I should use Dijkstra's Algorithm or A* to find out how to get to the funeral home?
I should probably use Dijkstra's algorithm out of respect, but I'm afraid that I might run out of memory in the process and forget my original purpose or spend too long thinking about it and not arrive in time.
I was just re-reading an old Jerry Pournelle novel (Prince of Mercenaries, a novel of Falkenberg's Legion) in which just such a slippery chemical spraw was used for crowd control while one of the main characters was in the crowd.
I find it somewhat ironic that 2 days later I'm reading about the same thing in the real world.
As life borrows yet another idea from the world of science fiction.
I have been toying for a while now with how to represent data efficiently in a manner in which it can be efficiently walked with an XML document-object-model, if not in XML itself.
My core concern is actually building the indexing tools to handle the matching of insane numbers of actual Xlinks (or a mildly simplified form thereof), to make a dataset that is distributed and provided by multiple subsystems hold together.
My most recent iteration used a simplified form of Xlink to join data supplied by code that implemented a specialized DOM model (code that understood how to browse a given object model, for reflection purposes), with data taken from a flat text XML document (browsed with a different implementation of that model).
The real concern I have with this sort of system is the time it takes to register a document against all of the current X-links and deriving an efficient system for parent-child connection when multiple parents can exist (transparent links from other nodes). Registering a new node or worse, changing data in a node is an expensive operation in this model.
My need for extensive X-link support is to be able to provide a sort of on-the-fly XSL translation of one branch of data into another. The links would then connect to the translated data rather than the original.
A secured view of the data could be provided by handing a link to a DOM node that was walking the XSL view, rather than the original data. User security becomes a XSL-like document.
My filesystem becomes a branch of the tree. It is admittedly an awkward security mechanism to do XSL-style matching against the tree, but it does not have to be done in XSL itself, another utility which walked a base dataset and returned a filtered view in the same DOM model provides the same security mechanics.
There are some issues with the current mechanisms for conveying XML information (DTDs do not localize well, etc).
Method invocations are shaky at best and rely on sharing handles of some sort (SOAP, CORBA, etc). I transmit data either by copying a branch of the tree, or handing off a handle to a CORBA or SOAP object that can walk the DOM on the local system.
Either way looks the same to the client.
A hierarchal model has a certain level of appeal because of the simplification of the new-branch registration process, but severely limits the effectiveness of the tree processing tools you can build. OTOH, the relational model could be reconstructed with some stylesheet tricks.
My present use is in an operating system project as the mechanism for accessing system resources, the 'file system', user data, etc.
There is appeal when it comes to generating a backwards compatible view of the data, because you can provide a translator which takes the current data and translates it back to a view compatible with what a given application expects, etc. Method invocations through a function call-translator can allow for constrained arguments to methods, etc.
The transparent linking model also has appeal for simplified remote method invocation, a filename is just an Xlink, etc.
You might want to read Schneier's Applied Cryptography. The 'real encryption' used in Zip files uses an ever-so-secure CRC32 (32 bit) convolution kernel rather than a piddly MD5 (128 bit) or SHA (160 bit) one-way hashing function like those hokey real cryptographers use. (not counting the fact that a CRC is also far more vulnerable to linear/differential cryptanalysis for its bit strength).
It is exactly this form of bad encryption backed by bad legislation that has the encryption community up in arms over the DMCA. The mindset that grows is that "well, this will keep the casual hacker out and we can sue the rest."
The point that the reply was trying to make is that the 'bright' LEDs aren't bright enough when scanned over that large of an area, you need one that is (using his math) 1200 times brighter given the amount of area that the LED can effectively illuminate. If you sweep an LED over a wider area all you get is the same amount of light spread over a wider area. Sweeping the light doesn't magically make it put out more light.
You could do this with wimpy little keychain lights and some fancy optics, but the picture would be Real Dim (tm).
Yes. However, I was replying to an individual who already had a large ASCII database. Hence I feel it is reasonable to assume that his existing data would transcode nicely to UTF-8 with little if no size-bloat. I was trying to dispel the myth that Unicode encoding would flat-out double the size of his existing data. UTF-16 would guarantee that.
A console is a very different environment. You can tune exactly for the hardware because there will be no variances. A PC game has to allow for 30 different graphic cards using APIs that supposedly make the different cards look the same to you but fail miserably. By the time you get done tweaking for the current morass of cards, a new generation of them is present with their own damn bugs. In the console world you deal with 2-3 environments IF you are allowed/it is practical to port given the current state of exclusive games. Also, if you've ever developed for a console, its very different, with a PC you have a lot of freedom to build how you want and what you want, in the console world you pretty much have to build around the hardware. This means you are constrained to build the same kind of engine for most every game you build on that console. If you don't you are just looking for different ways to cull the scene down to fit into the same miniscule space.
The two environments are very different, and most of that fat can't be trimmed by wishing it away or blaming on programmers.</RANT>
As for bloatware, start modelling cloth, hair, IK, bump maps, and the hardware gets used again. The reason the games aren't doing it now is because they want the comfortable sales window.
Honestly pushing ultra-high-end features that cut your market to 4% of what it could be isn't a big selling point - good luck convincing your publisher to bring the game to market - and trying to build an engine to scale between low and high-end aggravates the bloat of PC vs. console problem even worse.
Your best bet would be to use UTF8 to encode the information rather than UTF16. If your data is all ASCII right now, then you shouldn't see an increase in size (unless you use an over abundance of high (0x80+) ascii characters) The increase for high unicode characters later on becomes incremental.
A lot of Unicode's bad name comes from the bloated oversimplistic nature of the UTF16 and UTF32 formats. They are useful as internal representations for small buffers, but not for large amounts of data.
IIRC, he was 33 when he got the ring, and didn't appear age for the 7 years he had the ring before setting off - "showing signs of being remarkably well preserved".
"IP on everything" - seen on a shirt worn by Van Jacobsen - the guy who came up with the TCP compression used over PPP that helps telnet-style protocols) at a linux convention a long time ago
Yes, but the price/performance ratio they claim for the soupercomputer is based on a false assumption that the time and bodies it takes to assemble the cluster are worth nothing.
There is a difference between voiding a warantee and throwing someone in jail for reverse engineering the brake system in order to replace a worn shoe.;)
Yes there is a legitimate use. Many eBooks are protected from use with the speech synthesis software used by many blind computer users.
With this software you can remove that protection, thereby allowing it to be fed to a synthesizer.
I'm not clear on whether or not you can tell if the ebook in question is going to work with synthesis software until you have downloaded or unlocked it. (Anyone?)
I worked for the Greater Detroit Society for the Blind for 3 years, and you'd be amazed at some of the hoops these users have to jump through.
So you're saying that the number of users of a particular illegal application has an impact on the legality of the application? What defines the critical mass to become unprocecutable?
(A) is primarily designed or produced for the purpose of circumventing protection afforded by a technological measure that effectively protects a right of a copyright owner under this title in a work or a portion thereof;
Too bad effectively protecting your copyright isn't a requirement. Seems Adobe gets upset when you demonstrate that their approach is ineffective. Yes, I do understand that they were going for a different meaning.
Actually I think the analogy would be closer to getting arrested for being the locksmith that someone called to get them into their own house, after locking themselves out.
Big business would rather argue that they are the landlord and you should come to them for the key, rather than calling the locksmith yourself. Nevermind that they want to charge you an exorbitant fee for use of a lock a determined kid might pick with a paperclip.
Unfortunately, under the DMCA, none of us really own anything any more, and as time goes on more commonplace activities are going to be denied us.
Just think what would happen if the car companies caught wind of the full ramifications of the DMCA. "You let who change your brakes? They're not authorized to do that!" And heaven help you should you look under the hood and try and readjust a hose because it came loose.
Yes, but mostly that was just because Thomas Edison's propaganda machine couldn't get their collective heads out of their asses long enough to see that DC wasn't the way to go. The 'great american inventor' made more than his share of mistakes.
Slashdot Mirror
Patening a linked list? Why not, IIRC Animatek managed to patent looking up a 3d vector in an array.
Am I the only one who instantly visualized a 'prequel' with crook wielding pharisees coming after Jesus in bullet time?
The problem isn't so much laziness as efficiency.
Your quake era engines tend to go through and scan a quick and easy potentially visible list of convex cels, slap all of the objects and polygons contained therein up to the card and let the card sort it out.
Dynamic obscura such as half open moving doors, smoke grenades, aren't calculated into this. (well, most of the time, there are some optimizations for closed doors) largely because the overhead of sorting every a model into a span-buffer or beam-tree to check if it should be visible can be very high and doesn't scale linearly. (I had to do so once for an engine I designed to handle hard lighting) Even so, it probably won't catch 'visibility' hacks through alpha-translucent smoke.
It isn't being lazy to try to ship a product that runs when more than 3 people are visible on the screen. There is a certain point where pragmatic considerations come into play. Wildly varying frame processing times are not acceptable to the modern gamer. If your game slows to 4 fps so your machine can chooose exactly what polygons to render to eliminate one subclass of cheaps, you may feel a bit more secure, but you are still vulnerable to proxy based cheating methods, etc.
Add to this the fact that you have to allow for updates of light sources from every cel which can be seen from any point within any visible cel, there is a good reason for many of these games to give you enough information to 'see around corners', even if you can build an efficient enough culling algorithm that your server can just tell the client that there is a flashlight coming around the corner.
heaven forbid you want to do any secondary lighting, or play with realtime radiosity and need more information a the client.
Plus, you need to allow for the any motion prediction that is beeing ddone client side to smooth the action. this adds an additional fuzz factor, which in the interest of smoother operation might give the 'wallhacker' a hundred millisecond drop on the trusting mainstream gamer.
There is a certain amount of trust required for twitch gaming over the internet. if you want to build a 'secure' internet game go sell your soul to palladium while building up your network protocols over a public key infrastructure and hope that it is all that microsoft wants it to be, convert to a less twitchy game design. or preemptively build the cheats into the game to level the playing field.
I am not particularly fond of any of these options.
The argument that you can learn a small subset to be productive tends to bite you when you start trying to ramp up to multi-developer projects.
When you are provided with 20 different tools with which to accomplish a goal, developers are going to choose different ones, and if you eschew code ownership, each of them will have to be familiar with each other's favorite hammers to be able to make changes to each others code.
If you go in for code ownership then you wind up with no redundancy and a single developer holds you hostage.
In large scale development in such languages, if you have one high end programmer and several who are not so proficient with the language, the work-load gradually becomes unbalanced and you need an equally high-end programmer to replace your top guy when he leaves even if the code has devolved to maintenance and is not actively in production.
In a perfect world he may have left you clean interfaces and functional documentation, but the variety of syntactic sugar available can make maintenance difficult and expensive.
It just happens to be able to find all shortest paths in the same amount of time it takes to find one, hence the running out of memory comment.
I hate to respond to a troll, but I'll bite.
A terrible tragedy.
I should pay my respects.
Do you think I should use Dijkstra's Algorithm or A* to find out how to get to the funeral home?
I should probably use Dijkstra's algorithm out of respect, but I'm afraid that I might run out of memory in the process and forget my original purpose or spend too long thinking about it and not arrive in time.
Oh my.
I was just re-reading an old Jerry Pournelle novel (Prince of Mercenaries, a novel of Falkenberg's Legion) in which just such a slippery chemical spraw was used for crowd control while one of the main characters was in the crowd.
I find it somewhat ironic that 2 days later I'm reading about the same thing in the real world.
As life borrows yet another idea from the world of science fiction.
I have been toying for a while now with how to represent data efficiently in a manner in which it can be efficiently walked with an XML document-object-model, if not in XML itself.
;)
My core concern is actually building the indexing tools to handle the matching of insane numbers of actual Xlinks (or a mildly simplified form thereof), to make a dataset that is distributed and provided by multiple subsystems hold together.
My most recent iteration used a simplified form of Xlink to join data supplied by code that implemented a specialized DOM model (code that understood how to browse a given object model, for reflection purposes), with data taken from a flat text XML document (browsed with a different implementation of that model).
The real concern I have with this sort of system is the time it takes to register a document against all of the current X-links and deriving an efficient system for parent-child connection when multiple parents can exist (transparent links from other nodes). Registering a new node or worse, changing data in a node is an expensive operation in this model.
My need for extensive X-link support is to be able to provide a sort of on-the-fly XSL translation of one branch of data into another. The links would then connect to the translated data rather than the original.
A secured view of the data could be provided by handing a link to a DOM node that was walking the XSL view, rather than the original data. User security becomes a XSL-like document.
My filesystem becomes a branch of the tree. It is admittedly an awkward security mechanism to do XSL-style matching against the tree, but it does not have to be done in XSL itself, another utility which walked a base dataset and returned a filtered view in the same DOM model provides the same security mechanics.
There are some issues with the current mechanisms for conveying XML information (DTDs do not localize well, etc).
Method invocations are shaky at best and rely on sharing handles of some sort (SOAP, CORBA, etc). I transmit data either by copying a branch of the tree, or handing off a handle to a CORBA or SOAP object that can walk the DOM on the local system.
Either way looks the same to the client.
A hierarchal model has a certain level of appeal because of the simplification of the new-branch registration process, but severely limits the effectiveness of the tree processing tools you can build. OTOH, the relational model could be reconstructed with some stylesheet tricks.
My present use is in an operating system project as the mechanism for accessing system resources, the 'file system', user data, etc.
There is appeal when it comes to generating a backwards compatible view of the data, because you can provide a translator which takes the current data and translates it back to a view compatible with what a given application expects, etc. Method invocations through a function call-translator can allow for constrained arguments to methods, etc.
The transparent linking model also has appeal for simplified remote method invocation, a filename is just an Xlink, etc.
Active Directory, eat your heart out.
Its not a bug, its a feature.
You might want to read Schneier's Applied Cryptography. The 'real encryption' used in Zip files uses an ever-so-secure CRC32 (32 bit) convolution kernel rather than a piddly MD5 (128 bit) or SHA (160 bit) one-way hashing function like those hokey real cryptographers use. (not counting the fact that a CRC is also far more vulnerable to linear/differential cryptanalysis for its bit strength).
It is exactly this form of bad encryption backed by bad legislation that has the encryption community up in arms over the DMCA. The mindset that grows is that "well, this will keep the casual hacker out and we can sue the rest."
The point that the reply was trying to make is that the 'bright' LEDs aren't bright enough when scanned over that large of an area, you need one that is (using his math) 1200 times brighter given the amount of area that the LED can effectively illuminate. If you sweep an LED over a wider area all you get is the same amount of light spread over a wider area. Sweeping the light doesn't magically make it put out more light.
You could do this with wimpy little keychain lights and some fancy optics, but the picture would be Real Dim (tm).
Yes. However, I was replying to an individual who already had a large ASCII database. Hence I feel it is reasonable to assume that his existing data would transcode nicely to UTF-8 with little if no size-bloat. I was trying to dispel the myth that Unicode encoding would flat-out double the size of his existing data. UTF-16 would guarantee that.
A console is a very different environment. You can tune exactly for the hardware because there will be no variances. A PC game has to allow for 30 different graphic cards using APIs that supposedly make the different cards look the same to you but fail miserably. By the time you get done tweaking for the current morass of cards, a new generation of them is present with their own damn bugs. In the console world you deal with 2-3 environments IF you are allowed/it is practical to port given the current state of exclusive games. Also, if you've ever developed for a console, its very different, with a PC you have a lot of freedom to build how you want and what you want, in the console world you pretty much have to build around the hardware. This means you are constrained to build the same kind of engine for most every game you build on that console. If you don't you are just looking for different ways to cull the scene down to fit into the same miniscule space.
.</RANT>
The two environments are very different, and most of that fat can't be trimmed by wishing it away or blaming on programmers
As for bloatware, start modelling cloth, hair, IK, bump maps, and the hardware gets used again. The reason the games aren't doing it now is because they want the comfortable sales window.
Honestly pushing ultra-high-end features that cut your market to 4% of what it could be isn't a big selling point - good luck convincing your publisher to bring the game to market - and trying to build an engine to scale between low and high-end aggravates the bloat of PC vs. console problem even worse.
That is assuming of course that their time has no value.
Your best bet would be to use UTF8 to encode the information rather than UTF16. If your data is all ASCII right now, then you shouldn't see an increase in size (unless you use an over abundance of high (0x80+) ascii characters) The increase for high unicode characters later on becomes incremental. A lot of Unicode's bad name comes from the bloated oversimplistic nature of the UTF16 and UTF32 formats. They are useful as internal representations for small buffers, but not for large amounts of data.
IIRC, he was 33 when he got the ring, and didn't appear age for the 7 years he had the ring before setting off - "showing signs of being remarkably well preserved".
"IP on everything" - seen on a shirt worn by Van Jacobsen - the guy who came up with the TCP compression used over PPP that helps telnet-style protocols) at a linux convention a long time ago
There is a difference between voiding a warantee and throwing someone in jail for reverse engineering the brake system in order to replace a worn shoe. ;)
With this software you can remove that protection, thereby allowing it to be fed to a synthesizer.
I'm not clear on whether or not you can tell if the ebook in question is going to work with synthesis software until you have downloaded or unlocked it. (Anyone?)
I worked for the Greater Detroit Society for the Blind for 3 years, and you'd be amazed at some of the hoops these users have to jump through.
So you're saying that the number of users of a particular illegal application has an impact on the legality of the application? What defines the critical mass to become unprocecutable?
ROT-13 it and put 'licensed for decryption only by Dmitri Skylarov' on it, and they won't be able to decrypt it or you can sue them under the DMCA.
Too bad effectively protecting your copyright isn't a requirement. Seems Adobe gets upset when you demonstrate that their approach is ineffective. Yes, I do understand that they were going for a different meaning.
Big business would rather argue that they are the landlord and you should come to them for the key, rather than calling the locksmith yourself. Nevermind that they want to charge you an exorbitant fee for use of a lock a determined kid might pick with a paperclip.
Unfortunately, under the DMCA, none of us really own anything any more, and as time goes on more commonplace activities are going to be denied us.
Just think what would happen if the car companies caught wind of the full ramifications of the DMCA. "You let who change your brakes? They're not authorized to do that!" And heaven help you should you look under the hood and try and readjust a hose because it came loose.
http://claw.bsdi.com/torek/elec/tesla.html