a) I'm acutely aware of the religion following Slashdot readership. It's become more problematic of late when threads go down that path.
b) I'm suggesting more the latter. But also that I don't think it's a worthwhile topic of discussion unless you are simulataneously considering my argument that the "Christian Entertainment" industry hurts itself by isolating itself. I didn't see the foot (It's Funny, Laugh) icon, so...
c) You have to read all MY posts with tounge fimrly planted in cheek. Seriously. And read the whole thing, carefully.
I couldn't give half of a rats ass about this. Why anyone would want to play a game that's centered around adherance to a religious faith is a mystery to me. Plus, I mean will Mormons play games made by Roman Catholics if they are aware of those elements? Too much stupid shit to think about there. They're not trying to make a game at all, they're trying to make a statement in what is a largely secular field.
It's like people who make "hentai" games. Rarely are they ever fun. You'd waste less time finding ripped screens on USENET.
I mean it's cool if the theme of your game is religious based. I mean, fuck, FFVII gets a lot of its story from Cabbalist mysticism.
But you won't see any bible-thumping programmer surpassing John Carmack any time soon.
The problem is most noticable when you have a PC which is assumed to have roughly instantaneous video/audio output (I mean vsync/sound card dma was once used for timing for gods sake). HDTV systems compensate internally on top of all the other processing they have to do.
Monitors on DVI have no provision to send digital audio down that DVI cable. Usually there's a USB audio connector or RCA jack... or otherwise the audio is routed to a stereo amp or what have you that's external. So we cannot assume that a display with built in audio will have digital input... Unless it has SPDIF. In which case yes, it needs to go ADC, delayed, then DAC. Not a big deal... I'd rather do it at the source in an audio driver on the PC itself. Same thing with a console.
DirecTV typically has a 2 second lag behind network broadcast. So if you watch a game on a local channel, or the news, the cable in the PiP will lead the DirecTV feed. Sometimes we'll have two TVs on in close proximity, one on Cable, the other on the Sat, and when you hear them going at the same time it sounds like being in a really, really big cave or stadium.
When the MICROPHONE in the bass drum kit moves, it has the same stroke issues. So in the mix, the signal levels are as measured. On replay you're just mimicing the mic movement, which is subject to the same physical laws.
It really has no effect. Besides, the guy mixed on some monitors. So use monitors with the same phase/freq plot if you're so damn concerned.
Passive works just as well as active... no I take that back. You can simulate an "active scan" just by attempting to associate with a blank SSID on cards that support the linux wifi API. Or if you don't intend to associate, wireless-tools' "iwlist scan" command is what you want.
You could take the source to kismit and have it periodically run that command and have it pretend it "discovered" those APs at that time in order to deal with APs that don't send beacons but also reply to any request.
Now an AP that doesn't send beacons but also has a set SSID, well then you need to brute force, or listen to other clients. In which case Netstumbler wouldn't help (but kismet could pick up the other clients...)
Did you know that technically JPEG supports the ability to use a CYMK profile? It can support really any colorspace you want, but everyone just sort of assumes otherwise. I think because that full res Y + quarter res UV config is so popular, nobody (with the exception of the IJG guys) ever supported anything else. Why do cameras use it? It doesn't make sense for a camera to use a flat RGB profile though, because all the current sensors use a Bayer arrangement where color information is not known at every pixel anyway. Also, you might have an 8, 10, or 12-bit sensor with an unknown dynamic range and gamma curve, and you can do some clever mapping into the format that can retain a lot of that information internally. So JPEG is a good fit. The other choice is to dump the raw data and do post-proc later, at the expense of being able to store fewer pictures.
But using it during post-proc is retarded, I agree.
delta encoder. That's sort of a 2D version of a "move to front" encoder It then uses zlib to compress the results. If your picture has large regions of a single color, interrupted by large regions of other colors, then PNG compresses great (because the delta encoder will yield lots of zeros where the color didn't change, and lots of one value [i.e. zero] will compress great with zlib in the next stage).
So you need to make sure that you maximize the number of places where the pixel DOESN'T change color with respect to it's neighbors. That and reduce the total number of colors. It doesn't have to be less than 256 or anything, but the fewer distinct colors (and the larger regions where it doesn't change) the better.
Definitely DO NOT dither when you reduce the number of colors. That just ruins it.
Someone says: "oooh, this should be updated to a valid XML DTD and such and such", since it's just begging for it.
But flash and Quicktime started being used extensively by developers, and each has a "solution" for viewing 3D models that's just as useful as featureful as a seperate VRML browser might be. So targeting VRML became kinda pointless because other more common frameworks had support, and there are excellent content creation tools for those environments.
So no one had any reason to keep the VRML standard going.
Also VRML is presentation oriented, which makes it only useful at the "edge". You don't keep the files around, but you have the original models. So it sort of quietly disappears.
It sounds like U3D will be useful both for a workflow and for archival (and hence presentation) purposes. I think it's probably the right time to tackle that and design it with lessons learned.
So now they've just legitimatized what was practiced all along. (Well I'm not saying everybody did, but now even the nice guys will convert everyone to salaried to save money).
It applies to me although I rarely qualify for overtime. Since I know this won't have any effect on the loss of said jobs overseas, I don't see how it's even necessary.
There are a lot of people here who will just run you around in a circle. They figure out your domain of expertise. And then hit home with their opinion with no verifiable information to back it up under the pretense of "these are the facts".
And then they chalk it up as a win, and their egos are thus inflated.
Don't fall for it. Argument and logical skills don't even enter into it. People would like you to believe that's what they're using, but it's just cleverly constructed rhetoric.
I yearn for a day where logical elitism is a legitmate criticism. It'd be much nicer than our current state.
Speculation that we will be able to control those who have the resources that are used to produce goods in other countries that we also enforce favorable trade relationships with.
Which all comes downs to our arsenal. We bank on our destructive ability, even if we seem to wield it foolishly. You don't want to be on the wrong end of the pointy stick.
Because that leads to babies, which statistically, leads to volunteers in our armed forces.
What the hell kind of logic is that?
He should boycott EVERY operating system since you will find an instance of each of them on some military systems nowadays, from Solaris to Windows to Linux to FreeBSD and OpenBSD.
I want my operating system to be milspec. I happen to like simplicity and predictability. Oh, and there are tons more deployed Windows-based systems in the field then there are Linux (think about that for a second, which would YOU prefer?)
The original intent was to use ECMAscript because it was 'already there', seeing as XUL and the XHTML DOM are pretty close in purpose so you wouldn't be writing code twice. And it's a great language for the job, letting you do nice things like using closures to handle events, or doing funky things like adding properties to objects instances and shit. useful in an event driven environment where things are being thrown around willy nilly, properties being checked for, and their existance spawning all manner of conditional behavior. javascript is a really ass-easy language to plug your gui components together. In this way you can skin simple behaviors into the interfaces with it, and try different modes of interaction without recompiling. You shouldn't actually WRITE non-trivial applications with it, though. You should be using XPCOM callbacks that talk to native code for that (i.e. C/C++, java, python).
Newt is a toolkit for making text mode user interfaces. It has C, TCL, python and perl bindings.
It's a RedHat thing but it's apparently become popular (available on Debian, FreeBSD, well anything that has ncurses). It supports UTF-8 which is nice.
That'd sort of be your toolkit (ala GTK). So you're halfway there.
Slashdot Mirror
a) I'm acutely aware of the religion following Slashdot readership. It's become more problematic of late when threads go down that path.
b) I'm suggesting more the latter. But also that I don't think it's a worthwhile topic of discussion unless you are simulataneously considering my argument that the "Christian Entertainment" industry hurts itself by isolating itself. I didn't see the foot (It's Funny, Laugh) icon, so...
c) You have to read all MY posts with tounge fimrly planted in cheek. Seriously. And read the whole thing, carefully.
d) Give me a fucking break.
What, how many people here actually care about Christian games? I thought this was "news for NERDS", not the 7100 club.
I couldn't give half of a rats ass about this. Why anyone would want to play a game that's centered around adherance to a religious faith is a mystery to me. Plus, I mean will Mormons play games made by Roman Catholics if they are aware of those elements? Too much stupid shit to think about there. They're not trying to make a game at all, they're trying to make a statement in what is a largely secular field.
It's like people who make "hentai" games. Rarely are they ever fun. You'd waste less time finding ripped screens on USENET.
I mean it's cool if the theme of your game is religious based. I mean, fuck, FFVII gets a lot of its story from Cabbalist mysticism.
But you won't see any bible-thumping programmer surpassing John Carmack any time soon.
The problem is most noticable when you have a PC which is assumed to have roughly instantaneous video/audio output (I mean vsync/sound card dma was once used for timing for gods sake). HDTV systems compensate internally on top of all the other processing they have to do.
Monitors on DVI have no provision to send digital audio down that DVI cable. Usually there's a USB audio connector or RCA jack... or otherwise the audio is routed to a stereo amp or what have you that's external. So we cannot assume that a display with built in audio will have digital input... Unless it has SPDIF. In which case yes, it needs to go ADC, delayed, then DAC. Not a big deal... I'd rather do it at the source in an audio driver on the PC itself. Same thing with a console.
DirecTV typically has a 2 second lag behind network broadcast. So if you watch a game on a local channel, or the news, the cable in the PiP will lead the DirecTV feed. Sometimes we'll have two TVs on in close proximity, one on Cable, the other on the Sat, and when you hear them going at the same time it sounds like being in a really, really big cave or stadium.
When the MICROPHONE in the bass drum kit moves, it has the same stroke issues. So in the mix, the signal levels are as measured. On replay you're just mimicing the mic movement, which is subject to the same physical laws.
It really has no effect. Besides, the guy mixed on some monitors. So use monitors with the same phase/freq plot if you're so damn concerned.
s/War on (some) drugs/strategic action plan against certain narcotics of mass destruction/
Passive works just as well as active... no I take that back. You can simulate an "active scan" just by attempting to associate with a blank SSID on cards that support the linux wifi API. Or if you don't intend to associate, wireless-tools' "iwlist scan" command is what you want.
You could take the source to kismit and have it periodically run that command and have it pretend it "discovered" those APs at that time in order to deal with APs that don't send beacons but also reply to any request.
Now an AP that doesn't send beacons but also has a set SSID, well then you need to brute force, or listen to other clients. In which case Netstumbler wouldn't help (but kismet could pick up the other clients...)
Did you know that technically JPEG supports the ability to use a CYMK profile? It can support really any colorspace you want, but everyone just sort of assumes otherwise. I think because that full res Y + quarter res UV config is so popular, nobody (with the exception of the IJG guys) ever supported anything else.
Why do cameras use it? It doesn't make sense for a camera to use a flat RGB profile though, because all the current sensors use a Bayer arrangement where color information is not known at every pixel anyway. Also, you might have an 8, 10, or 12-bit sensor with an unknown dynamic range and gamma curve, and you can do some clever mapping into the format that can retain a lot of that information internally. So JPEG is a good fit. The other choice is to dump the raw data and do post-proc later, at the expense of being able to store fewer pictures.
But using it during post-proc is retarded, I agree.
I'm goina patent TRACTOR PULLIN' on the INTARWEB. I gots that fancy kit from Inventar's Helpline. YEEEEEEHAW!!!! We're gonna be rich.
delta encoder. That's sort of a 2D version of a "move to front" encoder It then uses zlib to compress the results. If your picture has large regions of a single color, interrupted by large regions of other colors, then PNG compresses great (because the delta encoder will yield lots of zeros where the color didn't change, and lots of one value [i.e. zero] will compress great with zlib in the next stage).
So you need to make sure that you maximize the number of places where the pixel DOESN'T change color with respect to it's neighbors. That and reduce the total number of colors. It doesn't have to be less than 256 or anything, but the fewer distinct colors (and the larger regions where it doesn't change) the better.
Definitely DO NOT dither when you reduce the number of colors. That just ruins it.
Steve Wozniak and Linus Trovalds. Notably absent: Michael Dell.
He wants to know where he can find an example of himself. I figured you might know.
but it's been done a few times already. Not really funny anymore.
Someone says: "oooh, this should be updated to a valid XML DTD and such and such", since it's just begging for it.
But flash and Quicktime started being used extensively by developers, and each has a "solution" for viewing 3D models that's just as useful as featureful as a seperate VRML browser might be. So targeting VRML became kinda pointless because other more common frameworks had support, and there are excellent content creation tools for those environments.
So no one had any reason to keep the VRML standard going.
Also VRML is presentation oriented, which makes it only useful at the "edge". You don't keep the files around, but you have the original models. So it sort of quietly disappears.
It sounds like U3D will be useful both for a workflow and for archival (and hence presentation) purposes. I think it's probably the right time to tackle that and design it with lessons learned.
...as I was shooting from the hip.
Ahhhh! I must commit ritual suicide.
After lunch.
So now they've just legitimatized what was practiced all along. (Well I'm not saying everybody did, but now even the nice guys will convert everyone to salaried to save money).
It applies to me although I rarely qualify for overtime. Since I know this won't have any effect on the loss of said jobs overseas, I don't see how it's even necessary.
There are a lot of people here who will just run you around in a circle. They figure out your domain of expertise. And then hit home with their opinion with no verifiable information to back it up under the pretense of "these are the facts".
And then they chalk it up as a win, and their egos are thus inflated.
Don't fall for it. Argument and logical skills don't even enter into it. People would like you to believe that's what they're using, but it's just cleverly constructed rhetoric.
I yearn for a day where logical elitism is a legitmate criticism. It'd be much nicer than our current state.
Have equipment envy?
And you speak for the entire country on these issues? Bull.
What the fuck is this, 18th century Quaker Pennslyvania? Mod this down obvious flamebait.
Speculation that we will be able to control those who have the resources that are used to produce goods in other countries that we also enforce favorable trade relationships with.
Which all comes downs to our arsenal. We bank on our destructive ability, even if we seem to wield it foolishly. You don't want to be on the wrong end of the pointy stick.
No wonder everyone hates us.
Because that leads to babies, which statistically, leads to volunteers in our armed forces.
What the hell kind of logic is that?
He should boycott EVERY operating system since you will find an instance of each of them on some military systems nowadays, from Solaris to Windows to Linux to FreeBSD and OpenBSD.
I want my operating system to be milspec. I happen to like simplicity and predictability.
Oh, and there are tons more deployed Windows-based systems in the field then there are Linux (think about that for a second, which would YOU prefer?)
The original intent was to use ECMAscript because it was 'already there', seeing as XUL and the XHTML DOM are pretty close in purpose so you wouldn't be writing code twice. And it's a great language for the job, letting you do nice things like using closures to handle events, or doing funky things like adding properties to objects instances and shit. useful in an event driven environment where things are being thrown around willy nilly, properties being checked for, and their existance spawning all manner of conditional behavior. javascript is a really ass-easy language to plug your gui components together. In this way you can skin simple behaviors into the interfaces with it, and try different modes of interaction without recompiling. You shouldn't actually WRITE non-trivial applications with it, though. You should be using XPCOM callbacks that talk to native code for that (i.e. C/C++, java, python).
Newt is a toolkit for making text mode user interfaces. It has C, TCL, python and perl bindings.
It's a RedHat thing but it's apparently become popular (available on Debian, FreeBSD, well anything that has ncurses). It supports UTF-8 which is nice.
That'd sort of be your toolkit (ala GTK). So you're halfway there.