I didn't expect this to hit Slashdot, so we were a bit unprepared for the amount of feedback:)
But yeah, its all legal and above board. A project like ScummVM isn't really something anyone would expect Paypal to take issue with:)
For those that like reading about lost causes, heres our (denied) appeal (including Paypals initial complaint and the response to our appeal).
Speaking of which, the site most of the tutorials were lifted from hasn't had that notice displayed since the half-complete redesign at the beginning of the year.
Ah, QuakeMovie. Those were the good ol' days, huh Tux?:)
That full-length machinima is Nehahra, and is renderered in real-time using the engine. Apart from being the first (well-known, at least) full length machinima, its all displayed by the Quake engine in real-time.
This is unlike the majority of the genre, which is typically distributed only in pre-edited video formats. Of course, THAT has the advantage that the movie will look the same on all video cards *g*
Of course, all these newer engines are far prettier than Quake, but still, check it out: http://www.planetquake.com/nehahra/:)
Ignoring the impending language debate, the merits of Java as a desktop development language are completely different from developing a speech recognition in it:)
So while Joe Blog User may be lucky enough to have a top-specced desktop. My main system is 800mhz x86, and a system doing speech recognition is going to be specced similarly at best.
Neither I nor most of the companies in this part of the world have the money to waste on needless hardware. We reuse a lot, and very few companies in Australia buy into the 6-monthy hardware purges.
And every year the Java yaysayers use the exaggerations of being 'ready-to-run' or 'cross-platform', which become less and less true every year as more different VM versions are deployed everywhere:)
Sure, Java can do X, Y and Z, but if your actually attempting to become a programmer the very FIRST question must be -should- you USE Java for X, Y, and Z?
For most cases of the above variables, the answer is no. Sure, you CAN, but you shouldn't. It's a matter of the right tool for the right job, and as somebody posted above Java is becoming the new Lisp in terms of being used for things which are just silly. Java is not the swiss-army knife of programming languages by any means:)
While I've been waiting for Sphinx to mature into something useful for a long time now, the move to Java makes the whole package pretty useless to me.
Java is a memory hog, and it's certainly not going to be on any device I would want speech recognition on. Heck, I don't have Java installed on any of my machines, mostly because of the absolutely ridiculous footprint on disk as well as when running in ram.
And integrating Java applications into other applications is very difficult. Now, Java is good for certain things, but a speech recognition engine in Java sounds like the worst abuse possible:)
That and I still can't train it to recognise my slight australian accent, unlike every other bit of SR software I've used on Win32:P
Whether or not Sphinx-4 works, and whether or not Java is 'fast' enough to do speech recognition processing, its of no use to me.
Don't you mean nvidia opengl? :)
on
OpenGL 2.0 Released
·
· Score: 2, Informative
Apart from having no relevance to OpenGL, most of the lighting examples etc on the page rely heavily on either NVs registry combiner extension or NVs 'CG' shader asm.
Both of which are non-standard methods that have been depreciated for ARB standards for a while now.
If such a thing does exist, this guy sounds like a canidiate for it:)
I have never ever heard of anybody proving the existence of the so-called 'Photographic Memory' ability, mind you. And common theory is that it doesn't exist outside of childhood eidetic memory.
Then again, the idea still persists and many people are under the belief that it IS a proven and reliable ability.
I ran the resampled version through a quick noise removal and bass boost in Audacity to come up with this:
http://www.enderboi.com/Ender_Filtered.mp3
Obviously this was a quick job, as the sample was too short to come up with a decent noise profile.
And to answer a quick question about the presence of RIAA in the filename.. Whilst conspiracy theories are fun here at/., and we all know Cowboy Neal did it anyway..
I believe that 'RIAA' was a type of amplification method in old vaccum tube kits. I assume the RIAA in the filename is implying it was normalised based on the RIAA response curve.
Disclaimer: I'm not old enough to know what I'm talking about. I'm sure there are some old-timer audiophiles around here that know the details tho:)
The original goal for ScummVM was obviously to run all LucasArts/LucasFilm SCUMM games.
This is the first release with all SCUMM games supported. The next release will probably be 1.0, once we have fixed some remaining major bugs (mostly in the later games, such as new addition Full Throttle which is, obviously, new and the main reason this isn't release 1.0)
Even if I AM more than a unrepentant about my spelling and grammar, I am pleased with feedback like paiute posted earlier in this thread.
However when people make comments like this, and throw insults like 'pathetic' and 'reenforcing stereotypes' around that I believe they are a little too anal-retentive for my liking. What if I AM a stereotypical geek? Hmm?
Anyway, had to throw this in to avoid insulting people who post polite feedback like paiute. But let us not turn it into a flamewar.
As I have said time and time again when people critique my spelling and grammer on Slashdot... I really don't care as long as my points are understandable and valid (which is something the language is ill-suited for anyway).
Besides, if the Americans can get away with butchering the language, I don't see why I can't one-up them with being inconsistant. And I hardly believe the BBC have any right to be critical when they go publishing articles such as this:)
I would like to make a rather strong complaint regarding Stephen Evans's article "Linux cyber battle turns nasty", as featured as a front-page article on the 5th of Feburary.
This article is presented as a factual piece, not an opinion column, and draws patently incorrect conclusions. Whilst the MyDoom virus does indeed target SCO and (in it's -B varient) Microsoft, the main payload of this virus is a spam gateway.
As someone whos main source of income deeply involves computer security, I find it insulting that Mr. Evans has apparantly made no attempt to research the history of these forms of virii, nor has he apparantly contacted any reputable anti-virus company regarding it. Meanwhile he postulates claims such as "it [revenge] must be one of the theories at the top of any investigator's list", and "in the case of the MyDoom computer worm, the motivation seems clearer". I find it very bad reporting that these claims are made WITHOUT actually asking any of the investigators opinion of the virus. It is a widely expressed opinion (see 'references' at the end of this message) by these security professionals that the Denial of Service attack is the SECONDARY function of the virus, and not at all related to it's true purpose. A simple search on Google, let alone contacting even local London-based security firms such as mi2g, would easily prove how factually incorrect this article is. In fact, to be harsh, it is a downright lie against common knowledge and opinion.
It is current common understanding in the anti-virus community that this virus is indeed designed specifically to facilitate commercial spammers, and that the inbuilt Denial of Service attack against SCO and Microsoft are a secondary effect and not intended as part of the original design.
Current monitoring of activity through infected machines indicate that the spamming functionality appears to be used by a very organised group of individuals, indicating the virus was possibly contract-coded. Current belief holds that the Denial of Service payload was added by said contracted coder.
As such, I do not belief it fair, nor good reporting, to use a proproted factual article to attribute the secondary (and in my opinion far easily avoidable!) of the virus as it's "purpose". The secondary effects may indeed by the result of a Linux user seeking revenge, but is currently understood to be more of a diversion from the viruses demonstratable true intent. There is a long tradition of this type of 'smoke screen' in many viruses intended for commercial benefit, as Mr. Evans would no doubt have discovered if he had researched the article more instead of using it as a pure propeganda platform and drawing unconfirmed conclusions.
I request that the article either be re-labeled as an OPINION piece, removed, or an more factually correct article be posted.
References: These other news sites, containing articles by researchers willing to do actual research, contain quotes from reputable security and virus research firms confirming the opinion above:
http://thewhir.com/marketwatch/myd012704.cfm
- Contains opinion by London-based firm mi2g
http://www.msnbc.msn.com/id/4113278/
- Contains quotes from researchers at well-known antivirus developer F-Secure and Symantec
http://www.ajc.com/business/content/business/0104/ 28worm.html
- Contains quotes from various other computer security researchers
I have, and I also have been deeply involved in the Quake codebases and reverse-engineering of Half-Life itself... So I am WELL aware of exactly how all the API hooks interact and the possible testing procedures they could use.
I still hold true that any of the potential changes they should (from the result of the source-leak, assuming thats the SOLE reason for the delay) want to make are not those that should affect the majority of the engine or interaction between the core components. Eg, localised testing of the changes.
That's true, but the API and protocol changes need only be compatibility-breaking and superficial. It really only needs to affect the renderer and network portions of the game (the SDK will almost certainly be opened up for modding, so that API - being the major and most tricky one - shouldn't need any real changes).
Even with a month of hard-core testing afterwards, the timeframe really just doesn't add up.
Four months to rewrite what exactly? Apart from possible Steam issues, for which I can't see four months solving any more than two weeks, there is (allegedly) nothing in the actual game source worth changing. Let's outline what will probably be done, to what should really NEED to be done:
* A week or so to fiddle with Steam and break compatibility enough to prevent the leaked source being of any use. Although, as it is supposibly a secure content distribution system, I do not see how the source floating around would hurt it. But then again, HL2's "Source" engine was supposed to be all new, but in reality it's (allegedly) still based off of Quake1/the original HL1 codebase.
* A few days to change some APIs to prevent engines compiled against the leaked code from running the release game DLLs. Again, this shouldn't really be needed - the server should be anti-cheat enough to catch abnormal physics behavior (eg, no walk/shoot-through walls, Neo style flying blah blah), and optimised enough not to send entitiy data for players/objects not REALLY in the players view (eg, no see-through-walls cheat)
* Another few days to similarly break the network protocol. This is easy enough to do ACCIDENTLY when coding engines, so...:)
In reality, nothing SHOULD need to change... and the only things worth changing should only take a short amount of time and only be in the form of obscurification and not be subject to the need for extensive re-testing.
Despite the claims, after spending concious effort in reading the first three words of that phrase, I was easily able to scan over the rest of it. Disclaimer: I am a speed reader, hence my automatic recognition ability may be a little more sensitive than some.
While this does appear harder to decypher than mere scrambling, my brain was able to easily get in the pattern of automatic recognition just like the scramble. I really do not think this is a fair comparision anyway.
The brain recognises words based on patterns. By scrambling the inner contents of a word, you do not aversely affect the letter distribution (this will vary depending on the length of the word) nor the brains ability to still immediately recognise most words in this distorted state. However, inversing the inner contents of a word is a completely different function - you are deliberatly inversing letter distances, not simply distorting the content.
Obviously, this is going to make it harder. However, for me at least, it only took a few words to get my brain in the pattern to automatically reverse as I scanned the text.
I didn't expect this to hit Slashdot, so we were a bit unprepared for the amount of feedback :)
But yeah, its all legal and above board. A project like ScummVM isn't really something anyone would expect Paypal to take issue with :)
For those that like reading about lost causes, heres our (denied) appeal (including Paypals initial complaint and the response to our appeal).
http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+ Gateway
It needs work still, and isn't integrated into anything yet. However, it's still a start!
I just dug up the old reference site we had about this from my backups.
See the Trainwreck Files for the reaction of people at the time!
Speaking of which, the site most of the tutorials were lifted from hasn't had that notice displayed since the half-complete redesign at the beginning of the year.
I must fix that.
One site to keep an eye on for your Quake3 source needs is QuakeSrc, particularly the forums.
Most of the current Quake engine moders hang out here.
Ah, QuakeMovie. Those were the good ol' days, huh Tux? :)
:)
:)
That full-length machinima is Nehahra, and is renderered in real-time using the engine. Apart from being the first (well-known, at least) full length machinima, its all displayed by the Quake engine in real-time.
This is unlike the majority of the genre, which is typically distributed only in pre-edited video formats. Of course, THAT has the advantage that the movie will look the same on all video cards *g*
Of course, all these newer engines are far prettier than Quake, but still, check it out: http://www.planetquake.com/nehahra/
- Ender. One of the "other" programmers
Ignoring the impending language debate, the merits of Java as a desktop development language are completely different from developing a speech recognition in it :)
So while Joe Blog User may be lucky enough to have a top-specced desktop. My main system is 800mhz x86, and a system doing speech recognition is going to be specced similarly at best.
Neither I nor most of the companies in this part of the world have the money to waste on needless hardware. We reuse a lot, and very few companies in Australia buy into the 6-monthy hardware purges.
And every year the Java yaysayers use the exaggerations of being 'ready-to-run' or 'cross-platform', which become less and less true every year as more different VM versions are deployed everywhere :)
:)
Sure, Java can do X, Y and Z, but if your actually attempting to become a programmer the very FIRST question must be -should- you USE Java for X, Y, and Z?
For most cases of the above variables, the answer is no. Sure, you CAN, but you shouldn't. It's a matter of the right tool for the right job, and as somebody posted above Java is becoming the new Lisp in terms of being used for things which are just silly. Java is not the swiss-army knife of programming languages by any means
(even after building a Sphinx3 model and converting it back)
The speaker-independency of Sphinx2 is debable, I have never been able to get a single successful word recognised :)
While I've been waiting for Sphinx to mature into something useful for a long time now, the move to Java makes the whole package pretty useless to me.
:)
:P
Java is a memory hog, and it's certainly not going to be on any device I would want speech recognition on. Heck, I don't have Java installed on any of my machines, mostly because of the absolutely ridiculous footprint on disk as well as when running in ram.
And integrating Java applications into other applications is very difficult. Now, Java is good for certain things, but a speech recognition engine in Java sounds like the worst abuse possible
That and I still can't train it to recognise my slight australian accent, unlike every other bit of SR software I've used on Win32
Whether or not Sphinx-4 works, and whether or not Java is 'fast' enough to do speech recognition processing, its of no use to me.
Apart from having no relevance to OpenGL, most of the lighting examples etc on the page rely heavily on either NVs registry combiner extension or NVs 'CG' shader asm. Both of which are non-standard methods that have been depreciated for ARB standards for a while now.
If such a thing does exist, this guy sounds like a canidiate for it :)
I have never ever heard of anybody proving the existence of the so-called 'Photographic Memory' ability, mind you. And common theory is that it doesn't exist outside of childhood eidetic memory.
Then again, the idea still persists and many people are under the belief that it IS a proven and reliable ability.
I ran the resampled version through a quick noise removal and bass boost in Audacity to come up with this:
/., and we all know Cowboy Neal did it anyway..
:)
http://www.enderboi.com/Ender_Filtered.mp3
Obviously this was a quick job, as the sample was too short to come up with a decent noise profile.
And to answer a quick question about the presence of RIAA in the filename.. Whilst conspiracy theories are fun here at
I believe that 'RIAA' was a type of amplification method in old vaccum tube kits. I assume the RIAA in the filename is implying it was normalised based on the RIAA response curve.
Disclaimer: I'm not old enough to know what I'm talking about. I'm sure there are some old-timer audiophiles around here that know the details tho
I said no text, you dogs!
The original goal for ScummVM was obviously to run all LucasArts/LucasFilm SCUMM games.
This is the first release with all SCUMM games supported. The next release will probably be 1.0, once we have fixed some remaining major bugs (mostly in the later games, such as new addition Full Throttle which is, obviously, new and the main reason this isn't release 1.0)
- James 'Ender' Brown
Co-Project Leader, ScummVM
I told Alexander Stohr about this, after he left ATI, and he apparantly passed it on the driver team.
:P
But of course, knowing about it and fixing it are two different things. Meh.
I'm using XF4.4RC2 now, as the native driver there works fine. But I miss s3tc
They tried, a while ago :)
- James 'Ender' Brown
Co-Project Leader
ScummVM (http://www.scummvm.org/)
Even if I AM more than a unrepentant about my spelling and grammar, I am pleased with feedback like paiute posted earlier in this thread.
However when people make comments like this, and throw insults like 'pathetic' and 'reenforcing stereotypes' around that I believe they are a little too anal-retentive for my liking. What if I AM a stereotypical geek? Hmm?
Anyway, had to throw this in to avoid insulting people who post polite feedback like paiute. But let us not turn it into a flamewar.
*shrugs*
:)
As I have said time and time again when people critique my spelling and grammer on Slashdot... I really don't care as long as my points are understandable and valid (which is something the language is ill-suited for anyway).
Besides, if the Americans can get away with butchering the language, I don't see why I can't one-up them with being inconsistant. And I hardly believe the BBC have any right to be critical when they go publishing articles such as this
I would like to make a rather strong complaint regarding Stephen Evans's article "Linux cyber battle turns nasty", as featured as a front-page article on the 5th of Feburary.
/ 28worm.html
This article is presented as a factual piece, not an opinion column, and draws patently incorrect conclusions. Whilst the MyDoom virus does indeed target SCO and (in it's -B varient) Microsoft, the main payload of this virus is a spam gateway.
As someone whos main source of income deeply involves computer security, I find it insulting that Mr. Evans has apparantly made no attempt to research the history of these forms of virii, nor has he apparantly contacted any reputable anti-virus company regarding it. Meanwhile he postulates claims such as "it [revenge] must be one of the theories at the top of any investigator's list", and "in the case of the MyDoom computer worm, the motivation seems clearer". I find it very bad reporting that these claims are made WITHOUT actually asking any of the investigators opinion of the virus. It is a widely expressed opinion (see 'references' at the end of this message) by these security professionals that the Denial of Service attack is the SECONDARY function of the virus, and not at all related to it's true purpose. A simple search on Google, let alone contacting even local London-based security firms such as mi2g, would easily prove how factually incorrect this article is. In fact, to be harsh, it is a downright lie against common knowledge and opinion.
It is current common understanding in the anti-virus community that this virus is indeed designed specifically to facilitate commercial spammers, and that the inbuilt Denial of Service attack against SCO and Microsoft are a secondary effect and not intended as part of the original design.
Current monitoring of activity through infected machines indicate that the spamming functionality appears to be used by a very organised group of individuals, indicating the virus was possibly contract-coded. Current belief holds that the Denial of Service payload was added by said contracted coder.
As such, I do not belief it fair, nor good reporting, to use a proproted factual article to attribute the secondary (and in my opinion far easily avoidable!) of the virus as it's "purpose". The secondary effects may indeed by the result of a Linux user seeking revenge, but is currently understood to be more of a diversion from the viruses demonstratable true intent. There is a long tradition of this type of 'smoke screen' in many viruses intended for commercial benefit, as Mr. Evans would no doubt have discovered if he had researched the article more instead of using it as a pure propeganda platform and drawing unconfirmed conclusions.
I request that the article either be re-labeled as an OPINION piece, removed, or an more factually correct article be posted.
References:
These other news sites, containing articles by researchers willing to do actual research, contain quotes from reputable security and virus research firms confirming the opinion above:
http://thewhir.com/marketwatch/myd012704.cfm
- Contains opinion by London-based firm mi2g
http://www.msnbc.msn.com/id/4113278/
- Contains quotes from researchers at well-known antivirus developer F-Secure and Symantec
http://www.ajc.com/business/content/business/0104
- Contains quotes from various other computer security researchers
I have, and I also have been deeply involved in the Quake codebases and reverse-engineering of Half-Life itself... So I am WELL aware of exactly how all the API hooks interact and the possible testing procedures they could use. I still hold true that any of the potential changes they should (from the result of the source-leak, assuming thats the SOLE reason for the delay) want to make are not those that should affect the majority of the engine or interaction between the core components. Eg, localised testing of the changes.
That's true, but the API and protocol changes need only be compatibility-breaking and superficial. It really only needs to affect the renderer and network portions of the game (the SDK will almost certainly be opened up for modding, so that API - being the major and most tricky one - shouldn't need any real changes). Even with a month of hard-core testing afterwards, the timeframe really just doesn't add up.
Also, I hear the leaked code compiles fine - so I'm not sure where this 1/3rd figure comes from. Gamecode I guess...
Four months to rewrite what exactly? Apart from possible Steam issues, for which I can't see four months solving any more than two weeks, there is (allegedly) nothing in the actual game source worth changing. Let's outline what will probably be done, to what should really NEED to be done:
:)
* A week or so to fiddle with Steam and break compatibility enough to prevent the leaked source being of any use. Although, as it is supposibly a secure content distribution system, I do not see how the source floating around would hurt it. But then again, HL2's "Source" engine was supposed to be all new, but in reality it's (allegedly) still based off of Quake1/the original HL1 codebase.
* A few days to change some APIs to prevent engines compiled against the leaked code from running the release game DLLs. Again, this shouldn't really be needed - the server should be anti-cheat enough to catch abnormal physics behavior (eg, no walk/shoot-through walls, Neo style flying blah blah), and optimised enough not to send entitiy data for players/objects not REALLY in the players view (eg, no see-through-walls cheat)
* Another few days to similarly break the network protocol. This is easy enough to do ACCIDENTLY when coding engines, so...
In reality, nothing SHOULD need to change... and the only things worth changing should only take a short amount of time and only be in the form of obscurification and not be subject to the need for extensive re-testing.
Ah well.
Despite the claims, after spending concious effort in reading the first three words of that phrase, I was easily able to scan over the rest of it. Disclaimer: I am a speed reader, hence my automatic recognition ability may be a little more sensitive than some.
While this does appear harder to decypher than mere scrambling, my brain was able to easily get in the pattern of automatic recognition just like the scramble. I really do not think this is a fair comparision anyway.
The brain recognises words based on patterns. By scrambling the inner contents of a word, you do not aversely affect the letter distribution (this will vary depending on the length of the word) nor the brains ability to still immediately recognise most words in this distorted state. However, inversing the inner contents of a word is a completely different function - you are deliberatly inversing letter distances, not simply distorting the content.
Obviously, this is going to make it harder. However, for me at least, it only took a few words to get my brain in the pattern to automatically reverse as I scanned the text.