I'm in the same boat. This was originally a site designed to help people stay in touch with one another, but the company's desire to monetize its data is making them drift further and further from that goal. I don't care that a friend of mine became a fan of Fluffy Bunnies and Toe Socks, or that they befriended a number of people I've never heard of, and I really won't care that they visited musicalclusterfuck.net and Liked a pop country band, or that they frequent Fox News. It's well on its way to becoming a malware-crawling, adfotainment hellhole... really the ultimate manifestation of Eternal September, with lots of well-moneyed players swarming on its back like a Surinam toad of e-commerce.
The Nvidia drivers run very well in Linux; in the realm of OpenGL, I've literally found no difference in performance or quality. If anything, the Linux drivers are somewhat better-behaved - setting a 16-bit 3D video mode results in ugly dithering in Windows, but not in Linux.
I have not had occasion to try the fglrx drivers on remotely modern hardware, but last time I tried them it was reminiscent of ATI's driver situation in Windows from a decade earlier: glitchy and somewhat prone to memory leaks, but definitely better than nothing, and leagues ahead of the open source drivers.
No, but it tends to put me in a frame of mind that expects to be irritated, and that is more likely to be pleased when the system works as it should. Windows 7 was a positive surprise by those metrics, and it generally feels good and acts right... but whenever I hop back into Linux with Enlightenment 16, things snap back into perspective.
No, you taffer, 258-bit! One bit for the power switch, and another for parity.
Re:and my time is $100 - $200 an hour ...
on
Ubuntu on a Dime
·
· Score: 1
Or, perhaps, an average joe trying to stretch his income during the worst recession in 75 years. There are plenty of people less skillful and lucky than you, and it's a safe bet that you're outside the target market for this book.
Nexuiz isn't Quake III-based. It's built on a fork of the DarkPlaces engine, which itself is a heavily modified, uber-gnarly derivative of the original Quake engine.:)
OK. I've seen it running now, and can make a few comments.
It's difficult to tell exactly what the framerate is - it rises and lowers in certain places, but it's difficult to tell with certainty whether that represents the playable state, or if it's just chugging because they used Fraps to capture it on a lower-end system. The Intel video's historically undercooked GL driver isn't helping, and I don't know whether Jake2 or vanilla Quake II run well on that hardware by default.
The most interesting thing I noticed was that the executable was periodically generating.mp3 files derived from the original.wav sounds. Precaching and storing those would be a good first step to improving speed, as dynamically encoding them on an as-needed basis would be unnecessary computational work.
Good work, Google! This certainly looks better than Quake II did on the hardware around in 1998 that ran the game at an equivalent speed, and I'm keen to see whether this goes anywhere.
Duke3D was pseudo-3D, but ran on the Build engine, not Doom.:) It had a much nicer feature set: support for resolutions higher than 640x400, room-over-room support, sloping floors, etc.
Ach, I hate responding to myself, but the FDIV bug wasn't isolated to Socket 4 (60/66 MHz) Pentiums like I'd thought. It apparently persisted all the way up to some Socket 5 120 MHz models, before being truly fixed. Back to the show.
He could have gotten away with 8 MB of RAM cheerfully. The engine's minimum running environment was really around 6 MB, though at that point it dropped sound effects and the textures started getting really blurry... Upgrading to 24 MB RAM was easily one of the better things I did in 1997.
Quake was listed as officially unsupported on anything less than a Pentium, and they recommended that it be run on a Pentium 75. That was the only way to be sure that the infamous Pentium FDIV bug didn't rear its misshapen head. It's hard to believe Quake would be in high school by now if it were a person.
Duke3D definitely ran faster - on a system meeting Quake's minimum specifications you could get away with running in 640x480, or other lower resolutions if your graphics card supported VESA 2.0 and were comfortable with editing a config file. That said, it was no picnic on a 486DX/33 with no L2 cache...
Um, dude? I know this certifies me as Gamer Grandpa, but you were unlikely to see a solid 30 fps in Quake II with the software renderer on less than a Pentium 166. Behold the miracles of the (many, many) layers of browser abstraction in action. Or perhaps inaction...
That's all well and good for passive internet viewing or jotting out a quick Facebook message, but for doing serious content creation that's a dubious assertion. Try running ArcGIS, 3Ds MAX, or any other high-end content creator on a netbook some time, let alone an iPad. You can get away with it on a higher-end laptop, but at the end of the day the best way to ensure that you have plenty of available horsepower for demanding applications is by entrusting it to a system designed for high workloads, and uncompromised by the concessions to power saving and heat generation necessary to carry the thing around with you all the time.
Your dreams of incandescence for wayward travelers in your home or office would have been nicely facilitated by a quad CPU Tejas workstation. You might have needed three-phase power, ear protection, and an asbestos suit, but that's just the price to pay to be a True Hardcore Gamer.
I may not have mod points, but I'd suggest that the included *nix apps are badly outdated, and - combined with its permissive security model - the OS could be rooted in any number of terribly creative ways. That said, this was a joke in the first place, so wheeeeeee
In that case, you should be fine. Just make sure that airflow remains good, and that all relevant fans are in proper working order, and keep rocking the old hardware.:)
Ripping, I can believe, but encoding should be dramatically faster on the new system. GPU-assisted solutions like Badaboom should grind through high-definition video with some facility, and modern h.264 software encoders (such as Handbrake) are very well-optimized for arbitrary numbers of CPU cores.
That said, I'm in the same camp of keeping multiple computers around. My Athlon X2 5050e with a 9600GT's done fine for all the games I play, and my media center PC with a Radeon 9800 Pro went from bearable to peppy when I replaced its 3.2 GHz Pentium 4 with a Celeron e1500.:)
Yes, this was a widely discussed issue back when the Northwoods were in vogue. "Sudden Northwood Death Syndrome" was caused by electromigration within the CPU, and voltages beyond 1.7V always eventually killed the proc. I won't stand here and say that you shouldn't overclock, but I'd suggest picking up a spare on eBay just in case it fries out...
They don't necessarily pick up his tab. He's entirely free to buy the software, then download the cracked and slimmed down version. The world's not binary, though I'm not foolish enough to assume stonewallred is entirely noble based on his tone.
I'm in agreement with you. Note my encouragement that people keep using 0.9.3 if they wish to use DiVX. h.264 decoders are moving forward - ffmpeg-mt is a major boon, even allowing my Celeron e1500 to decode 1080i video in software - but taking the presumptuous stance that DiVX simply doesn't matter because it's not technically "pure" and in spite of its very large presence in the marketplace is arrogant wishful thinking.
And yeah, even in standard definition h.264 encode times are a bitch. My systems grind through the high-profile preset at a pinch slower than real-time; the saving grace is Handbrake's ability to queue multiple encodes, so I can set up a batch job and then leave it to work overnight. The GPU-accelerated solutions haven't impressed me that much: so far Badaboom only outputs the mp4 container format, and it doesn't support queueing of multiple encodes. Ultimately movie format choices are down to individual preference and need: use the right tool for you.
I'm in the same boat. This was originally a site designed to help people stay in touch with one another, but the company's desire to monetize its data is making them drift further and further from that goal. I don't care that a friend of mine became a fan of Fluffy Bunnies and Toe Socks, or that they befriended a number of people I've never heard of, and I really won't care that they visited musicalclusterfuck.net and Liked a pop country band, or that they frequent Fox News. It's well on its way to becoming a malware-crawling, adfotainment hellhole... really the ultimate manifestation of Eternal September, with lots of well-moneyed players swarming on its back like a Surinam toad of e-commerce.
The Nvidia drivers run very well in Linux; in the realm of OpenGL, I've literally found no difference in performance or quality. If anything, the Linux drivers are somewhat better-behaved - setting a 16-bit 3D video mode results in ugly dithering in Windows, but not in Linux.
I have not had occasion to try the fglrx drivers on remotely modern hardware, but last time I tried them it was reminiscent of ATI's driver situation in Windows from a decade earlier: glitchy and somewhat prone to memory leaks, but definitely better than nothing, and leagues ahead of the open source drivers.
No, but it tends to put me in a frame of mind that expects to be irritated, and that is more likely to be pleased when the system works as it should. Windows 7 was a positive surprise by those metrics, and it generally feels good and acts right... but whenever I hop back into Linux with Enlightenment 16, things snap back into perspective.
No, you taffer, 258-bit! One bit for the power switch, and another for parity.
Or, perhaps, an average joe trying to stretch his income during the worst recession in 75 years. There are plenty of people less skillful and lucky than you, and it's a safe bet that you're outside the target market for this book.
Nexuiz isn't Quake III-based. It's built on a fork of the DarkPlaces engine, which itself is a heavily modified, uber-gnarly derivative of the original Quake engine. :)
OK. I've seen it running now, and can make a few comments.
It's difficult to tell exactly what the framerate is - it rises and lowers in certain places, but it's difficult to tell with certainty whether that represents the playable state, or if it's just chugging because they used Fraps to capture it on a lower-end system. The Intel video's historically undercooked GL driver isn't helping, and I don't know whether Jake2 or vanilla Quake II run well on that hardware by default.
The most interesting thing I noticed was that the executable was periodically generating .mp3 files derived from the original .wav sounds. Precaching and storing those would be a good first step to improving speed, as dynamically encoding them on an as-needed basis would be unnecessary computational work.
Good work, Google! This certainly looks better than Quake II did on the hardware around in 1998 that ran the game at an equivalent speed, and I'm keen to see whether this goes anywhere.
Duke3D was pseudo-3D, but ran on the Build engine, not Doom. :) It had a much nicer feature set: support for resolutions higher than 640x400, room-over-room support, sloping floors, etc.
I'm at work behind a video-unfriendly firewall, so thank you for pointing that out. :) That will be worth checking out when I get home.
Ach, I hate responding to myself, but the FDIV bug wasn't isolated to Socket 4 (60/66 MHz) Pentiums like I'd thought. It apparently persisted all the way up to some Socket 5 120 MHz models, before being truly fixed. Back to the show.
He could have gotten away with 8 MB of RAM cheerfully. The engine's minimum running environment was really around 6 MB, though at that point it dropped sound effects and the textures started getting really blurry... Upgrading to 24 MB RAM was easily one of the better things I did in 1997.
Quake was listed as officially unsupported on anything less than a Pentium, and they recommended that it be run on a Pentium 75. That was the only way to be sure that the infamous Pentium FDIV bug didn't rear its misshapen head. It's hard to believe Quake would be in high school by now if it were a person.
Duke3D definitely ran faster - on a system meeting Quake's minimum specifications you could get away with running in 640x480, or other lower resolutions if your graphics card supported VESA 2.0 and were comfortable with editing a config file. That said, it was no picnic on a 486DX/33 with no L2 cache...
Um, dude? I know this certifies me as Gamer Grandpa, but you were unlikely to see a solid 30 fps in Quake II with the software renderer on less than a Pentium 166. Behold the miracles of the (many, many) layers of browser abstraction in action. Or perhaps inaction...
That's all well and good for passive internet viewing or jotting out a quick Facebook message, but for doing serious content creation that's a dubious assertion. Try running ArcGIS, 3Ds MAX, or any other high-end content creator on a netbook some time, let alone an iPad. You can get away with it on a higher-end laptop, but at the end of the day the best way to ensure that you have plenty of available horsepower for demanding applications is by entrusting it to a system designed for high workloads, and uncompromised by the concessions to power saving and heat generation necessary to carry the thing around with you all the time.
Your dreams of incandescence for wayward travelers in your home or office would have been nicely facilitated by a quad CPU Tejas workstation. You might have needed three-phase power, ear protection, and an asbestos suit, but that's just the price to pay to be a True Hardcore Gamer.
I may not have mod points, but I'd suggest that the included *nix apps are badly outdated, and - combined with its permissive security model - the OS could be rooted in any number of terribly creative ways. That said, this was a joke in the first place, so wheeeeeee
It was a funny joke But you didn't quite get it No laughter for you.
Windows 1.01 was worse - fire engine red and bright yellow. It literally looked like Dante's GUI.
In that case, you should be fine. Just make sure that airflow remains good, and that all relevant fans are in proper working order, and keep rocking the old hardware. :)
That said, I'm in the same camp of keeping multiple computers around. My Athlon X2 5050e with a 9600GT's done fine for all the games I play, and my media center PC with a Radeon 9800 Pro went from bearable to peppy when I replaced its 3.2 GHz Pentium 4 with a Celeron e1500. :)
Yes, this was a widely discussed issue back when the Northwoods were in vogue. "Sudden Northwood Death Syndrome" was caused by electromigration within the CPU, and voltages beyond 1.7V always eventually killed the proc. I won't stand here and say that you shouldn't overclock, but I'd suggest picking up a spare on eBay just in case it fries out...
They don't necessarily pick up his tab. He's entirely free to buy the software, then download the cracked and slimmed down version. The world's not binary, though I'm not foolish enough to assume stonewallred is entirely noble based on his tone.
No, no, it has to stay on brand - Windows Annoyance New Technology.
Yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeah! *scenic views of Miami*
I'm in agreement with you. Note my encouragement that people keep using 0.9.3 if they wish to use DiVX. h.264 decoders are moving forward - ffmpeg-mt is a major boon, even allowing my Celeron e1500 to decode 1080i video in software - but taking the presumptuous stance that DiVX simply doesn't matter because it's not technically "pure" and in spite of its very large presence in the marketplace is arrogant wishful thinking.
And yeah, even in standard definition h.264 encode times are a bitch. My systems grind through the high-profile preset at a pinch slower than real-time; the saving grace is Handbrake's ability to queue multiple encodes, so I can set up a batch job and then leave it to work overnight. The GPU-accelerated solutions haven't impressed me that much: so far Badaboom only outputs the mp4 container format, and it doesn't support queueing of multiple encodes. Ultimately movie format choices are down to individual preference and need: use the right tool for you.