Which glx do you mean? The one that John Carmack and others are working on, that has rage pro & g[24]00 support? Or the one that I hear comes with the Xfree86 V4 pre-releases?
Perhaps, to avoid confusion, we should start calling these "utah-glx" (that's the name I found somewhere in their CVS module:-) and "Xfree86 glx", respectively?
Did you really expect to just plonk a dedicated quake server on your computer and have it automatically prevent cheating and other nasty stuff?
What this situation really needs are, like in the MUD world, active server deities or wizards. When a confirmed cheater is found, normal players just rat about him/her to the wizard, maybe vote to temporarily ban him, and the wizard can banish people permanently if that is really needed. Possibly add a mandatory registration with the server to be able to play, which will probably cut down on the amount of cheaters by itself.
Of course, the cheaters could just re-register after having their score table zeroed out or removed altogether, but that kind of thing can be reduced by setting a "waiting period" before the registration becomes effective, for certain IP ranges. How patient is the average power-hungry script kiddie? Probably less patient than the server owner, who can keep increasing the waiting period until the kiddie in question loses interest. If nothing else, this will at least let the honest players keep slaughtering each other until the kiddy returns.
If you ask me, the problem of power-hungry script kiddies can't be solved effectively with technology alone. More power to the $DEITIES, on the other hand...
I'd hate to start a new thread, so I'll just follow up to this one:-) Hope you don't mind.
I've been working on a multiplayer networked rocket game (see Turboraketti 1/2, turbis and others for a definition of "rocket game") for a while, and I think I've solved the clientserver trust problem pretty well, although the result may not be satisfactory if you're on a slow / laggy link.
I designed the client -> server part of the protocol so that the client only tells the server what changes to the state of the user have just occurred. It is then up to the server to cause that player's ship to turn, fire its engine or something like that. But the point is, the input data packets don't contain anything that could be falsified (like a command "move my ship to some random position and set its velocity to 0,0", to quickly get out of trouble when no such thing can be done without cheating). This also causes the client not to be able to compensate for its lag to the server, but hey - life is tough.
The server also keeps count of shots fired, checks for collisions and other stuff like that. Most of the calculations are also shadowed by the client program, so object movement is pretty smooth with relatively low consumption of bandwidth. This scheme also doesn't require encryption; the server simply performs strict sanity checking of all incoming packets and kicks clients who violate certain constraints right out.
This should make the server side completely cheat-proof, unless I've been smoking crack at some point and just haven't noticed:-)
Unfortunately, as I see it, this method of client-to-server communication can't be easily migrated to Quake, and absolutely not without breaking backward compatibility.
hash include lessthan stdio dot h greaterthan feed feed int main open void close feed curlyopen feed indent-one printf open quotes h e l l o comma space w o r l d backslash n quotes close semicolon feed back-one curlyclose feed
Though I don't really think that editors would try to naively replace the keyboard with a voice recognition interface:-)
There ain't such a thing. It's either a driver for DRI (unlikely, at the time) or an extension for the 3d hardware glx module (the one with pretty nice G200 and G400 support) for X 3.3.
Come on, this isn't windows. There's no such thing as an ICD or any other billgatesland TLAs on linux:-)
I wouldn't be surprised if they released a binary-only driver too. That would be consistent with their previous support of open source (the riva 128 glx source was put thru cpp, for example).
2) If I release the source, everyone will know the Napster protocol, opening lots of security holes.
... And if you don't release the source, someone will just reverse engineer the whole protocol like you did and find an exploitable hole in the binary-only napster server by brute force. It's only a matter of time, you know.
The solution? I'd write a decentralised Mp3 trading program (that, instead of a central server or two has a decentralised network. sort of like IRC, only with less coordination). I don't have the bandwidth to test such a thing, or the time to implement it but I think it'd be a viable project.
Besides, binary-only adware is evil. Especially when the protocol (and other stuff, most likely. I haven't tried napster out) is kept closed.
The security abomination of ActiveX will *never* be duplicated by anybody else.
Wishful thinking. People will forget, PHBs will forget faster. "This new powerful embedded E-mailable application system will enhance our product value!" I can already smell the drool.
Umm... You haven't tried apt, have you? It takes care of package dependencies automatically, so if for example you want to install the newest mutt from unstable, apt will ask permission to download the new glibc, new slang etc etc. and install them in a sane manner. Debian is really an easy system to upgrade, compared to most other distros.
Raw dpkg.... yecch. I can see how people could hose their systems with it:-) Tho, the same is possible with rpm-based systems as well; just use the --force switch a few times too many.
Yes, MPEG2 is more efficient. But the efficiency results mainly in more bang for the bit, i.e. a better looking picture at more frames per sec at the same bitrate.
What I was getting at is that if one were to take the MPEG2 stream apart and encode the decoded frames (and a good compromise of the sound tracks, of course) into a lower-quality MPEG1 stream (as in, lower resolution and less FPS at a lower bitrate), the whole ordeal would result in a MPEG1 system layer stream that would still have better quality than the same video data from any other source because there's no analogue step in between.
Of course it won't be as good looking etc as the original MPEG2 stream, but it'll be storable on a small number of CD-R discs. And quite a bit less resource hungry to play back.
And supervhs is an analogue format and thus not suitable for long-term storage or convenient replaying in a computer:-)
Storing the raw DVD video/audio data is foolish, yes. But the DVD video is of such high quality that it is feasible to downgrade it to, say, 400x300 or 512x384 pixels in truecolor and MPEG-1 it at a reasonable bitrate. That'll still result in higher quality video than what has been previously available to the w4r3z-keepers.
So how did this "Y2K bug" thing happen in the first place? Or maybe I should ask, "who are the gzkdrmn fsckwits who decided that storing the year as ASCII would be a really smart thing to do?". After all, a single signed 8-bit byte can store the values 0 to 127 and a signed 16-bit integer can store from 0 to somewhere in the upper 30Ks.
A smart programmer could just write a small library or a header file with functions or macros to perform basic operations on these "offset years" and so forth. The only thing to remember would be to add the epoch start year to the offset-year and boom, the year just became printf()-able.
Now, either most of the people who wrote software that handles time on some form or another have fucked up royally or I'm just babbling about how the world should be the ideal world where pi is 3, too.
So, aside from stupid legal agreements that Creative may have made, there shouldn't be any real reason why they can't release information about their hardware.
Well, there is the encryption bit. I believe the DVD pushers consider that too a trade secret.
Unless, of course, decryption is handled by the hardware, which I have a hard time believing; wouldn't it make sense to encrypt the whole disk, syncing data and all? If yes, how would the viewer hand the data over to the hardware (since there has to be a kind of "a block here, a block there" system in the stream, right?) without knowing about block boundaries? I personally can't believe that a card would buffer enough encrypted data to make a valid block, decode whatever that block contains into images and a PCM stream and then ask for more - that would be taking the "black box" thing a bit far.
Not that I know anything about the typical hardware implementation of a real DVD decoder, so don't flame me for ignorance.:-)
I'd hack the SDLmpeg code myself to do this, if I knew something about the VCD format:-) After all, it's all in the headers, right? MpegTV (an evil capitalist piece of proprietary chicken poo) does this just by parsing the headers and separating the audio/video stream, IIRC.
You would also need to support still images, menus, remote control functions, playlists, CD-DA tracks & other Video CD 2.0 (White Book) features. VCD is not just about MPEG files.
Ah, I should be more careful with what I write. I meant to say "if I knew enough about the format of the MPEG data on the VCD". But the main function that most users want is the ability to watch low-resolution, low-bitrate pirated movies downloaded from w4r3z ftps. At least, if "most users" is limited to myself:-)
Most of the "typical" VCD interactive content is like the stuff found on a DVD, IIUnderstoodC. Besides, even MpegTV only plays the MPEG video / audio data.
Whatever. This looks like it could be an interesting project. Now if I could just find the time to do this kind of stuff...
If what I remember is correct, Gutenberg originally invented the pre-pre-pre-pre-printing press so that he could automatically copy (i.e. forge) books that until then had to be copied by hand, a monotonous task usually performed by monks, and sell them for profit.
Just an amusing detail. I honestly don't know if this is the truth (it may well not be), but it made me laugh, once.
Well, this is all good and great, but we have a lot of data streams we have to break still:)
-Quick time came up a few weeks ago on slashdot.
I seem to recall that a QT/AVI player on the Amiga had a radius cinepak decoder and a CYUV decoder, in source. Although the formats that people would most desire are still the intel indeos... Yes, there are the xanim linkable files, but reverse engineering ain't fun.
-We need to come up with a good GPLed VCD player (I can't find any, youknow of one?)
I'd hack the SDLmpeg code myself to do this, if I knew something about the VCD format:-) After all, it's all in the headers, right? MpegTV (an evil capitalist piece of proprietary chicken poo) does this just by parsing the headers and separating the audio/video stream, IIRC.
-console based Real-Audio receiver that can save to.wav or.mp3 or something
Uhh... Realaudio sucks, compared to an equal bitrate (equal hz, too) LAME-encoded mp3 stream. IMO of course.
From what I've heard, the decoder doesn't support the YUV conversion stuff in many modern graphics cards yet. So the code is pretty fast, for not-really-optimized C. So when the Xfree86 people come up with an extension to support hardware-based YUV conversion, things are going to get lots better with any format that requires a YUV conversion pass to play.
And by the way, you can pretty much forget about $free{"beer"} decoder card software; from what I've heard, the DVD license comes on a per-developer fee and a hefty NDA. Which means that even if Creative wanted, they couldn't release any critical parts of the DVD "standard", even if the cat is already out of the basket.
The whole PROPAGANDA has a historical error in the "story" bit; finland hasn't had a king since it went and got itself independent and even before that there were only the conquering nations' kings.
Not that I give a fsck, but there are some who might not like Finland misrepresented as a monarchy:-)
How about using the descent 1 engine for stuff like this? It's got the full 6 degrees of freedom and the source is out there. I hear that some people have already done a playable OpenGL version, too.
But seriously, isn't limiting the user/world interaction to just "runnin' around, shootin' stuff" a bit... you know, limited? Killing processes isn't *that* common, even on large, multiuser systems. Pointing and clicking at objects to perform actions on them would be pretty cool, as would be the ability to socialize with other users on the system.
In case you don't realize this guys, 20000 geeks' livelihoods depend directly upon Microsoft. Twenty thousand employees and their families are directly influenced by software piracy. Pirated copies of software cost Microsoft money, and do you think they'll be passing that cost along to BillG? Forget it. It comes straight out of the base employees' salaries.
No it doesn't. Thing is, the software that someone pirates doesn't actively steal money from someone else. The money that would magically appear in microsnot's bank account were that particular piece of software bought legitimately simply does not appear.
The same thing happens when you use open source software instead of paying for proprietary equivalents, really. Yet somehow, I don't feel very guilty over running Linux instead of windows...
Bladeenc is not suggested due to the fact it uses ISO encoding not pyscho-aucstic(sp) which is much better.
No. Bladeenc uses the default psycho-acoustic model from the so called ISO dist10 source code. Unfortunately, this code has a large bug in it: the psy-model allocates bits for the left channel first, leaving the right channel with the minimum of four bits per subband in the worst case. This can be remedied by using huge bitrates with bladeenc, but that uses more space than encoding with LAME in a variable bitrate mode for the same quality. Besides, songs encoded with a dist10 based encoder (8hz, bladeenc, others?) tend to lose some of the bass sounds (compared to the CD original).
Then there's the pre-echo detection bit, but you can read all about it here.
Wasn't it 3dfx that was so jealous about their code and APIs (remember the GLIDE wrapper lawsuits)? I wouldn't be surprised if their "contribution" would be closed-source/with a really restrictive license.
Slashdot Mirror
Which glx do you mean? The one that John Carmack and others are working on, that has rage pro & g[24]00 support? Or the one that I hear comes with the Xfree86 V4 pre-releases?
Perhaps, to avoid confusion, we should start calling these "utah-glx" (that's the name I found somewhere in their CVS module :-) and "Xfree86 glx", respectively?
Did you really expect to just plonk a dedicated quake server on your computer and have it automatically prevent cheating and other nasty stuff?
What this situation really needs are, like in the MUD world, active server deities or wizards. When a confirmed cheater is found, normal players just rat about him/her to the wizard, maybe vote to temporarily ban him, and the wizard can banish people permanently if that is really needed. Possibly add a mandatory registration with the server to be able to play, which will probably cut down on the amount of cheaters by itself.
Of course, the cheaters could just re-register after having their score table zeroed out or removed altogether, but that kind of thing can be reduced by setting a "waiting period" before the registration becomes effective, for certain IP ranges. How patient is the average power-hungry script kiddie? Probably less patient than the server owner, who can keep increasing the waiting period until the kiddie in question loses interest. If nothing else, this will at least let the honest players keep slaughtering each other until the kiddy returns.
If you ask me, the problem of power-hungry script kiddies can't be solved effectively with technology alone. More power to the $DEITIES, on the other hand...
I'd hate to start a new thread, so I'll just follow up to this one :-) Hope you don't mind.
I've been working on a multiplayer networked rocket game (see Turboraketti 1/2, turbis and others for a definition of "rocket game") for a while, and I think I've solved the clientserver trust problem pretty well, although the result may not be satisfactory if you're on a slow / laggy link.
I designed the client -> server part of the protocol so that the client only tells the server what changes to the state of the user have just occurred. It is then up to the server to cause that player's ship to turn, fire its engine or something like that. But the point is, the input data packets don't contain anything that could be falsified (like a command "move my ship to some random position and set its velocity to 0,0", to quickly get out of trouble when no such thing can be done without cheating). This also causes the client not to be able to compensate for its lag to the server, but hey - life is tough.
The server also keeps count of shots fired, checks for collisions and other stuff like that. Most of the calculations are also shadowed by the client program, so object movement is pretty smooth with relatively low consumption of bandwidth. This scheme also doesn't require encryption; the server simply performs strict sanity checking of all incoming packets and kicks clients who violate certain constraints right out.
This should make the server side completely cheat-proof, unless I've been smoking crack at some point and just haven't noticed :-)
Unfortunately, as I see it, this method of client-to-server communication can't be easily migrated to Quake, and absolutely not without breaking backward compatibility.
I can already imagine it.
hash include lessthan stdio dot h greaterthan feed feed int main open void close feed curlyopen feed indent-one printf open quotes h e l l o comma space w o r l d backslash n quotes close semicolon feed back-one curlyclose feed
Though I don't really think that editors would try to naively replace the keyboard with a voice recognition interface :-)
I'd rather not have a binary-only driver that plugs into the X server that runs as root.
So... What exactly is so bad about a minor having a mental image of someone being fucked with a chainsaw?
There ain't such a thing. It's either a driver for DRI (unlikely, at the time) or an extension for the 3d hardware glx module (the one with pretty nice G200 and G400 support) for X 3.3.
Come on, this isn't windows. There's no such thing as an ICD or any other billgatesland TLAs on linux :-)
I wouldn't be surprised if they released a binary-only driver too. That would be consistent with their previous support of open source (the riva 128 glx source was put thru cpp, for example).
The solution? I'd write a decentralised Mp3 trading program (that, instead of a central server or two has a decentralised network. sort of like IRC, only with less coordination). I don't have the bandwidth to test such a thing, or the time to implement it but I think it'd be a viable project.
Besides, binary-only adware is evil. Especially when the protocol (and other stuff, most likely. I haven't tried napster out) is kept closed.
Wishful thinking. People will forget, PHBs will forget faster. "This new powerful embedded E-mailable application system will enhance our product value!" I can already smell the drool.
And we're not criminals, are we? Perish the thought!
Umm... You haven't tried apt, have you? It takes care of package dependencies automatically, so if for example you want to install the newest mutt from unstable, apt will ask permission to download the new glibc, new slang etc etc. and install them in a sane manner. Debian is really an easy system to upgrade, compared to most other distros.
Raw dpkg.... yecch. I can see how people could hose their systems with it :-) Tho, the same is possible with rpm-based systems as well; just use the --force switch a few times too many.
Yes, MPEG2 is more efficient. But the efficiency results mainly in more bang for the bit, i.e. a better looking picture at more frames per sec at the same bitrate.
What I was getting at is that if one were to take the MPEG2 stream apart and encode the decoded frames (and a good compromise of the sound tracks, of course) into a lower-quality MPEG1 stream (as in, lower resolution and less FPS at a lower bitrate), the whole ordeal would result in a MPEG1 system layer stream that would still have better quality than the same video data from any other source because there's no analogue step in between.
Of course it won't be as good looking etc as the original MPEG2 stream, but it'll be storable on a small number of CD-R discs. And quite a bit less resource hungry to play back.
And supervhs is an analogue format and thus not suitable for long-term storage or convenient replaying in a computer :-)
Storing the raw DVD video/audio data is foolish, yes. But the DVD video is of such high quality that it is feasible to downgrade it to, say, 400x300 or 512x384 pixels in truecolor and MPEG-1 it at a reasonable bitrate. That'll still result in higher quality video than what has been previously available to the w4r3z-keepers.
So how did this "Y2K bug" thing happen in the first place? Or maybe I should ask, "who are the gzkdrmn fsckwits who decided that storing the year as ASCII would be a really smart thing to do?". After all, a single signed 8-bit byte can store the values 0 to 127 and a signed 16-bit integer can store from 0 to somewhere in the upper 30Ks.
A smart programmer could just write a small library or a header file with functions or macros to perform basic operations on these "offset years" and so forth. The only thing to remember would be to add the epoch start year to the offset-year and boom, the year just became printf()-able.
Now, either most of the people who wrote software that handles time on some form or another have fucked up royally or I'm just babbling about how the world should be the ideal world where pi is 3, too.
Well, there is the encryption bit. I believe the DVD pushers consider that too a trade secret.
Unless, of course, decryption is handled by the hardware, which I have a hard time believing; wouldn't it make sense to encrypt the whole disk, syncing data and all? If yes, how would the viewer hand the data over to the hardware (since there has to be a kind of "a block here, a block there" system in the stream, right?) without knowing about block boundaries? I personally can't believe that a card would buffer enough encrypted data to make a valid block, decode whatever that block contains into images and a PCM stream and then ask for more - that would be taking the "black box" thing a bit far.
Not that I know anything about the typical hardware implementation of a real DVD decoder, so don't flame me for ignorance. :-)
Ah, I should be more careful with what I write. I meant to say "if I knew enough about the format of the MPEG data on the VCD". :-)
But the main function that most users want is the ability to watch low-resolution, low-bitrate pirated movies downloaded from w4r3z ftps. At least, if "most users" is limited to myself
Most of the "typical" VCD interactive content is like the stuff found on a DVD, IIUnderstoodC. Besides, even MpegTV only plays the MPEG video / audio data.
Whatever. This looks like it could be an interesting project. Now if I could just find the time to do this kind of stuff...
If what I remember is correct, Gutenberg originally invented the pre-pre-pre-pre-printing press so that he could automatically copy (i.e. forge) books that until then had to be copied by hand, a monotonous task usually performed by monks, and sell them for profit.
Just an amusing detail. I honestly don't know if this is the truth (it may well not be), but it made me laugh, once.
I seem to recall that a QT/AVI player on the Amiga had a radius cinepak decoder and a CYUV decoder, in source. Although the formats that people would most desire are still the intel indeos... Yes, there are the xanim linkable files, but reverse engineering ain't fun.
I'd hack the SDLmpeg code myself to do this, if I knew something about the VCD format :-) After all, it's all in the headers, right? MpegTV (an evil capitalist piece of proprietary chicken poo) does this just by parsing the headers and separating the audio/video stream, IIRC.
Uhh... Realaudio sucks, compared to an equal bitrate (equal hz, too) LAME-encoded mp3 stream. IMO of course.
From what I've heard, the decoder doesn't support the YUV conversion stuff in many modern graphics cards yet. So the code is pretty fast, for not-really-optimized C. So when the Xfree86 people come up with an extension to support hardware-based YUV conversion, things are going to get lots better with any format that requires a YUV conversion pass to play.
And by the way, you can pretty much forget about $free{"beer"} decoder card software; from what I've heard, the DVD license comes on a per-developer fee and a hefty NDA. Which means that even if Creative wanted, they couldn't release any critical parts of the DVD "standard", even if the cat is already out of the basket.
The whole PROPAGANDA has a historical error in the "story" bit; finland hasn't had a king since it went and got itself independent and even before that there were only the conquering nations' kings.
Not that I give a fsck, but there are some who might not like Finland misrepresented as a monarchy :-)
How about using the descent 1 engine for stuff like this? It's got the full 6 degrees of freedom and the source is out there. I hear that some people have already done a playable OpenGL version, too.
But seriously, isn't limiting the user/world interaction to just "runnin' around, shootin' stuff" a bit... you know, limited? Killing processes isn't *that* common, even on large, multiuser systems. Pointing and clicking at objects to perform actions on them would be pretty cool, as would be the ability to socialize with other users on the system.
No it doesn't. Thing is, the software that someone pirates doesn't actively steal money from someone else. The money that would magically appear in microsnot's bank account were that particular piece of software bought legitimately simply does not appear.
The same thing happens when you use open source software instead of paying for proprietary equivalents, really. Yet somehow, I don't feel very guilty over running Linux instead of windows...
No. Bladeenc uses the default psycho-acoustic model from the so called ISO dist10 source code. Unfortunately, this code has a large bug in it: the psy-model allocates bits for the left channel first, leaving the right channel with the minimum of four bits per subband in the worst case. This can be remedied by using huge bitrates with bladeenc, but that uses more space than encoding with LAME in a variable bitrate mode for the same quality.
Besides, songs encoded with a dist10 based encoder (8hz, bladeenc, others?) tend to lose some of the bass sounds (compared to the CD original).
Then there's the pre-echo detection bit, but you can read all about it here.
Wasn't it 3dfx that was so jealous about their code and APIs (remember the GLIDE wrapper lawsuits)? I wouldn't be surprised if their "contribution" would be closed-source/with a really restrictive license.
Go check out CipherSaber. If crypto is outlawed, we'll just have to write our own crypto software from memory :-)