Well... not everyone can (or wants to) download and compile code to play a sports game.
And perhaps there's enough mods and branches to the point where you may find value in a company packaging the code up into a tidy package. Or perhaps a real statistics database? (they aren't free) Not to mention there are some aspects of game development that don't lend themselves well to open source (ie: audio production for commentary).
I've been kicking the idea around for a few months now.:o)
The Xbox 2 specs have already been leaked. 3 G5 chips, no hard drive, etc. It's not even backwards compatible with the Xbox. That's not to say it won't have some sort of media center features. But it ain't a PC in console clothes like the Xbox is.
CHAPEL HILL, NC--Area resident Jonathan Green does not own a television, a fact he repeatedly points out to friends, family, and coworkers--as well as to his mailman, neighborhood convenience-store clerks, and the man who cleans the hallways in his apartment building....</snip>
Keep in mind HP numbers are wishy-washy...
Is it HP at the crank or wheels? There's a loss of power as it travels through the transmission and to the wheels.
Is factory HP numbers? Sometimes the factory fudges the HP for various insurance/financial reasons.
Is it dynometer HP numbers? The baseline HP should acquired on the same exact dyno the mods were tested on. There's crank and chassis dynometers of various types. You also don't get any "ram air effect" on a dyno. So the motor has to do all the work of pulling air into itself.
I can claim a 20% HP gain by just quoting the wheel HP versus the crank HP. To get the whole story, you need torque and power/weight numbers as well.
Re:Retuning for maximum durability?
on
Hack Your Ride
·
· Score: 1
I wouldn't be so sure that the factory wants your car to last forever. If certain things don't fall apart or need replacing just after your warranty expires, the service and parts department wouldn't be the cash cow it is today. Would it?;o)
Re:Wow, flashback to high school (Other bass CDs)
on
Giant Sub-Woofer
·
· Score: 1
I think your assumptions about the poster are ignorant and rude. GOOD Code monkeys usually ship products on time. BAD self-proclaimed "Engineers" do a lot of hand waving and constantly gripe about how things should be done instead of doing anything. Unfortunately, executives and non-technical folk are most easily impressed by the "engineer".
Don't get me wrong. Design is important. To a degree. You have to establish general architecture, boundaries and concepts. But at a certain level of detail, you're making assumptions that you shouldn't waste your time with.
Forget about "poorly defined requirements". What about well defined constantly changing ones? Big Design Up Front makes a gamble that the project won't evolve or change shape during development. The odds are worse than a lottery ticket in Hong Kong.
Common sense, motivation, self-discipline, communication, and, most importantly, hard work will ship a project far more on target than reams of design docs and meetings. I'll take 5 good code monkeys over your 10 engineers any day. bee-otch.
I'm not an open source zealot at all. You don't think this flaw was found and fixed because GreyMagic could the see HTML/JavaScript in webpages? Are they just really good guessers? I agree it can be done with compiled closed source. But reverse engineering assembler is a lot harder that looking at HTML/Javascript to figure out what's going wrong.
This really demonstrated to me the power of open source code. It seems to me that the reason this flaw was discovered, and fixed, was because it was an exploit with a scripting language. Which means anyone (like GreyMagic) can examine the code, find an exploit, write up a reproducable case, and provide it back to the software owners.
I don't know what the big deal is about all this size stuff. My high-end state of the art desktop was smaller than the keyboard. It even has the keyboard built-in!
Well, OK. Fine. It was high-end for the 80's (128KB and CP/M Bee-otch!).
Re:For crying out loud
on
My Visit to SCO
·
· Score: 2, Funny
NEWS FLASH! SCO has just announced the following function was maliciously ripped from their code....
int main(int argc, const char** argv);
"See! See! We used that same exact function in our code! We also use the int variable i in our for loops."
Please remove these offending snippets from Linux immediately or prepare to be buried by a littany of smarmy IP attorneys.
"grab an XDK and your favorite IDE"
Yeah, as long as your favorite IDE is VS.Net or VC6.
I'm a Lead Programmer on a PS2 project and I have to say that SCE/A/EE have been very helpful with developer support. It's true the Japanese developers get first drops of any new technology and we get the translated second passes. But, in my opinion, there hasn't been anything I wanted to do on the PS2 that didn't have some sample code, some developer that has already done it that I could talk to, or (in rare cases) comprehensive documentation. Perhaps I'm fortunate that the PS2 has matured a bit.
I can't speak for XP specifically, but lightweight development has been nothing but a positive experience for my team. But it's a tricky question. Because if you truly believe in the "Agile" methodologies, you find that the development process quickly becomes customized based on your team members and type of project. It's all about creating the path of least resistance for your team while still moving towards the end product.
I work in a game studio where our last project had 6 months of pre-production time. We generated reams of technical design documents. The intention was good, but they were never maintained or even referenced after their initial creation. We just said "documentation is necessary" and it needed to be done. In production, the team wasn't on the same page. Every programmer had a task list they just milled through. The assumption was the initial requirements won't change. The result was ugly. The product was subpar and a couple months late. Everyone was miserable. It sucked.
I'm currently leading a new project here. We're 6 months into production and every milestone has been delivered ON TIME and accepted by our customer. The team is focussed on the current milestone, there isn't a lot of process to get in the way. The best part is, writing code is fun again. We don't have goals we can't accomplish. And we fully expect the product requirements to change during production.
I could get into specifics about our process. But I don't think it would be that helpful. I think specific methodologies like XP are guidelines to get you started. From there, you really should re-evaluate your process frequently (a fundamental excercise to be "Agile") and make changes as necessary. Kind of like optimizing your code.
The following links gave me all the information I needed to devise an initial process plan (which included TDD). But once it was put into practice, it naturally evolved into the process we have now (which doesn't include TDD)...
That's funny. Because CodePlay has been around for a few years now pitching their PC compiler. The PS2 compiler is still in development. PS2 devlopers have access to the prerelease versions right now.
So I think it's incorrect to say they're porting their PS2 technology to the PC.
I would imagine they aren't using MP3 encoding due to the ridiculous royalties they would have to pay to Fraunhoffer. Which would only add to the price.
What about Ogg? Well, Ogg probably doesn't have a slick business partnership manager to wheel and deal for them like LiquidAudio does.
This guy has been working on way to graphically model C++ programs. Basic shapes represent different constructs and you graphically connect them together. The tool then generates C++ from the model. Kind of cool for visualizing code:
OK. Fine. I meant to say "partial screen rendering".
I never said the Dreamcast was multiprocessor. Nor did I say it was a new/revolutionary technique. I was just explaining how 16 PS2's work together on the GSCube.
I got to play with the GSCube first hand last year. It is essentially 16 PS2's in a single box. The workload is distributed by dividing the screen up into tiles and having a PS2 dedicated to rendering 1/16th of the screen. Distributing this workload over a network sounds a little far fetched to me.
FWIW, the Dreamcast used this "tile based" rendering as well.
Compared to PC hardware, the PS2 is SLOOOOOOW. It's core CPU is a 294 mHz MIPS.
The real speed comes in with the specialized vector units (VU0 & VU1) that are specifically built to scream through large sets of 4 component floating point vectors (used as 3d coordinates in games) and perform a limited number of operations on them.
Slashdot Mirror
I'm going to take a long coiling dump on the floor- whatever symbol it makes will represent the result when you multiply any number times nullity.
HSA's are cheaper and more flexible than your typical HMO/PPO healthcare plans
t hIns/MSAs.html
http://www.forhealthfreedom.org/Publications/Heal
Well... not everyone can (or wants to) download and compile code to play a sports game.
:o)
And perhaps there's enough mods and branches to the point where you may find value in a company packaging the code up into a tidy package. Or perhaps a real statistics database? (they aren't free) Not to mention there are some aspects of game development that don't lend themselves well to open source (ie: audio production for commentary).
I've been kicking the idea around for a few months now.
The Xbox 2 specs have already been leaked. 3 G5 chips, no hard drive, etc. It's not even backwards compatible with the Xbox. That's not to say it won't have some sort of media center features. But it ain't a PC in console clothes like the Xbox is.
Area Man Constantly Mentioning He Doesn't Own A Television
CHAPEL HILL, NC--Area resident Jonathan Green does not own a television, a fact he repeatedly points out to friends, family, and coworkers--as well as to his mailman, neighborhood convenience-store clerks, and the man who cleans the hallways in his apartment building....</snip>
You are annoying.
Keep in mind HP numbers are wishy-washy... Is it HP at the crank or wheels? There's a loss of power as it travels through the transmission and to the wheels. Is factory HP numbers? Sometimes the factory fudges the HP for various insurance/financial reasons. Is it dynometer HP numbers? The baseline HP should acquired on the same exact dyno the mods were tested on. There's crank and chassis dynometers of various types. You also don't get any "ram air effect" on a dyno. So the motor has to do all the work of pulling air into itself. I can claim a 20% HP gain by just quoting the wheel HP versus the crank HP. To get the whole story, you need torque and power/weight numbers as well.
I wouldn't be so sure that the factory wants your car to last forever. If certain things don't fall apart or need replacing just after your warranty expires, the service and parts department wouldn't be the cash cow it is today. Would it? ;o)
What about DJ Magic Mike? ;o)
Don't get me wrong. Design is important. To a degree. You have to establish general architecture, boundaries and concepts. But at a certain level of detail, you're making assumptions that you shouldn't waste your time with.
Forget about "poorly defined requirements". What about well defined constantly changing ones? Big Design Up Front makes a gamble that the project won't evolve or change shape during development. The odds are worse than a lottery ticket in Hong Kong.
Common sense, motivation, self-discipline, communication, and, most importantly, hard work will ship a project far more on target than reams of design docs and meetings. I'll take 5 good code monkeys over your 10 engineers any day. bee-otch.
I'm not an open source zealot at all. You don't think this flaw was found and fixed because GreyMagic could the see HTML/JavaScript in webpages? Are they just really good guessers? I agree it can be done with compiled closed source. But reverse engineering assembler is a lot harder that looking at HTML/Javascript to figure out what's going wrong.
This really demonstrated to me the power of open source code. It seems to me that the reason this flaw was discovered, and fixed, was because it was an exploit with a scripting language. Which means anyone (like GreyMagic) can examine the code, find an exploit, write up a reproducable case, and provide it back to the software owners.
When Sony gets (read: buys) exclusivity with a title, it's in the console domain only. So a PC version is not out of the question.
I believe this is related to XAML which is designed to take the nightmare out of windows UI coding.
What are you talking about? Right there on the iTunes homepage, they just added Sir Mix-A-Lot's "Mack Daddy" album. Open your eyes, man!
Maybe a few hundred thousand American programmers could get work visas and support it for a fraction of what the Indian guys charged.
I don't know what the big deal is about all this size stuff. My high-end state of the art desktop was smaller than the keyboard. It even has the keyboard built-in!
Well, OK. Fine. It was high-end for the 80's (128KB and CP/M Bee-otch!).
NEWS FLASH! SCO has just announced the following function was maliciously ripped from their code....
"See! See! We used that same exact function in our code! We also use the int variable i in our for loops."
Please remove these offending snippets from Linux immediately or prepare to be buried by a littany of smarmy IP attorneys.
"grab an XDK and your favorite IDE" Yeah, as long as your favorite IDE is VS.Net or VC6. I'm a Lead Programmer on a PS2 project and I have to say that SCE/A/EE have been very helpful with developer support. It's true the Japanese developers get first drops of any new technology and we get the translated second passes. But, in my opinion, there hasn't been anything I wanted to do on the PS2 that didn't have some sample code, some developer that has already done it that I could talk to, or (in rare cases) comprehensive documentation. Perhaps I'm fortunate that the PS2 has matured a bit.
I work in a game studio where our last project had 6 months of pre-production time. We generated reams of technical design documents. The intention was good, but they were never maintained or even referenced after their initial creation. We just said "documentation is necessary" and it needed to be done. In production, the team wasn't on the same page. Every programmer had a task list they just milled through. The assumption was the initial requirements won't change. The result was ugly. The product was subpar and a couple months late. Everyone was miserable. It sucked.
I'm currently leading a new project here. We're 6 months into production and every milestone has been delivered ON TIME and accepted by our customer. The team is focussed on the current milestone, there isn't a lot of process to get in the way. The best part is, writing code is fun again. We don't have goals we can't accomplish. And we fully expect the product requirements to change during production.
I could get into specifics about our process. But I don't think it would be that helpful. I think specific methodologies like XP are guidelines to get you started. From there, you really should re-evaluate your process frequently (a fundamental excercise to be "Agile") and make changes as necessary. Kind of like optimizing your code.
The following links gave me all the information I needed to devise an initial process plan (which included TDD). But once it was put into practice, it naturally evolved into the process we have now (which doesn't include TDD)...
The New Methodology by Martin Fowler
The Agile Manifesto
Agile Software Development Ecosystems by Jim Highsmith
I also suggest reading the chapters on "thematic milestones" in Writing Solid Code.
So I think it's incorrect to say they're porting their PS2 technology to the PC.
What about Ogg? Well, Ogg probably doesn't have a slick business partnership manager to wheel and deal for them like LiquidAudio does.
http://www.gel.ulaval.ca/~dumais01/genu/
"What is Genu?
Genu is an interface to C++. It brings to the user:
-Intuitive approach to programmation with the analogy of C++ and tree.
-Interface for managing complex projects and instant recognition of important part of the program"
OK. Fine. I meant to say "partial screen rendering".
I never said the Dreamcast was multiprocessor. Nor did I say it was a new/revolutionary technique. I was just explaining how 16 PS2's work together on the GSCube.
I got to play with the GSCube first hand last year. It is essentially 16 PS2's in a single box. The workload is distributed by dividing the screen up into tiles and having a PS2 dedicated to rendering 1/16th of the screen. Distributing this workload over a network sounds a little far fetched to me.
FWIW, the Dreamcast used this "tile based" rendering as well.
Compared to PC hardware, the PS2 is SLOOOOOOW. It's core CPU is a 294 mHz MIPS. The real speed comes in with the specialized vector units (VU0 & VU1) that are specifically built to scream through large sets of 4 component floating point vectors (used as 3d coordinates in games) and perform a limited number of operations on them.