When was the last time you used SVN? Everything you just said is very confusing, 1.5 came out over a year ago and seems to have most of the features you say it does not.
Chances are we never upgraded the server at work, or if we did it was after 2+ years of fearing SVN merges so I never noticed the new features. I've heard others that work with SVN say unflattering things about the automatic merge tracking but I have nothing but their word on that. Maybe they're wrong. I'd given up on SVN's merges long before 1.5 came out, and Git's other features are too compelling to warrant looking back.
As for rebasing, this is the first I've heard of it. It sounds interesting, but I don't really understand the problem it was meant to solve. [...] Just seems a little superficial to me:\ A single patch is too much, the actual VCS history is too much, so the ideal is offering a doctored up change history? Wouldn't the end result be more interesting? I think good source comments with other documentation would be easier to understand and more proper than reviewing the change history of someone's patch. Since when was how someone's patch was developed more important than what was developed? Isn't diving into the VCS to find reasons for something being just a sign that the code wasn't documented properly? So, yes, we dive into VCS history to solve preexisting documentation problems, but when it comes to accepting someone else's patch, isn't that the time to simply demand good comments and or documentation?
The second bit I bolded answers the question you raised in the first. You would clean up your commit history precisely because the contents are more important than the method. That meaningless history is only going to get in people's way if they have to go through the history, so why not replace it with something nice before sending your changes into the shared repository?
While you develop you want to use branches and commits however you see fit, making throw-away instances of each when you experiment with things, reverting old changes, etc (and if you don't see why that's a big deal, you're missing out). But when you submit you don't want people to see a bunch of "work in progress" commits, you want them to see something that reflects a logical breakdown of what you did so that each component can be considered/used on its own. Most of the history rewriting commands are for this. Rebase is a special case of cherry-picking that grabs your work and reapplies it to the current development head (usually, it can be whatever branch you like) so you get a nice clean patch relative to the current code, rather than to revision whatever-it-was-when-I-branched.
Say I write a complex patch that changes a bunch of existing code and then adds a bunch of new stuff on top of that. If the person who wrote the original code that I changed wants to review my work, it would be nice if he could just look up Changeset X: Refactored system X to add hooks for Y rather than digging through 25 tiny commits, mostly labeled "work, work" (or WIP or "undid crap" or whatever) which correspond more closely to my coffee breaks or the times I had to switch to something else for a second than it does to the code - or worse yet one giant commit that includes my changes to his stuff and a ton of stuff he doesn't care about since it's separate.
Cleaning up the history allows me to collapse many dozens of little WIP commits into "Refactoring system X", "Added module Y", and "Optimized module Z to use new hooks exposed in X". Once I do that the maintainers of X and Z immediately know what they need to look at to find the changes that impact them, without having to dig through Y's changeset for any buried changes of interest. That also makes it much easier to cherry-pick individual components of my work into other branches, or perhaps nuke module Y while keeping the new X and Z code. Rewriting history is a powerful ope
I remember seeing some sort of simple incrementing revision/commit number. It was a while ago and I'm tired now, so maybe I'm just confused or misremembering. Apologies if I've spread misinformation (and someone mod parent up if that's the case).
With subversion, don't you merge a specific range of revisions, such as "C->G" in your example?
Yes, but that gets screwed up all the time. I used to have a system of sticky-notes for tracking what I had/hadn't merged up to a given point and late at night during crunch when you just want the damn thing to work so you can go home you make an off-by-one error, and an i++ gets merged in twice in some ridiculously obscure code that you didn't even write, and you sit there an extra two hours tracking down your error. There are fancy little shell scripts that purport to do the same thing, but they get confused any time the commit graph gets...interesting. And in my experience a team of two people and a single common code file is enough to qualify as interesting with SVN.
Also, while maybe not as nice as git's merging, isn't subversion 1.5's merge-tracking exactly what you're talking about? Now the range of revisions doesn't need to be specified, AFAIK.
SVN 1.5 may have fixed this. I have heard that it's slow (as in "go get some coffee" slow), and I've heard claims that it breaks with complex histories (multiple branches merging in/out of trunk many times over the same period of time), but I've got nothing but word of mouth to back that up.
That aside, and as I've said a few times, the main thing that gives Git its merge power, I find, is its ability to rewrite history. You can literally reorder commits at will, and in many cases I have found that changing the order things are merged in makes a world of difference to how clean the result is, and how easy any conflicts that pop up along the way are going to be to clean up. As an example, we use Git's rebase operation as part of our workflow, which does this:
master: A -> B
git branch hackity git checkout hackity
do some work git commit
hackity: A -> B -> C
git checkout master git pull master//pulls in change set D from the remote source's master branch and updates master to point to it
master: A -> B -> D
git checkout hackity git rebase master
hackity: A -> B -> D -> C'
Where C' is identical to C (it differs only in its parent commit and in any conflicts you may have had to resolve). You can then merge that into master without creating any new commits beyond C'. All it does is move the 'master' pointer down the graph to point to C' as its head commit, which is the definition of a fast-forward (it can do this since C' includes all of master in its ancestors). This gets really useful when you have C -> E -> F ->... -> X to rebase as it will let you resolve conflicts as they come up one commit at a time instead of making you deal with everything in one enormous messy diff (though that option is available to you as well, if you wish) and that makes for a much quicker and easier job when you have to figure out what's going on, at least in my experience. And in the end you get C', E', F', etc, with their useful commit messages, instead of the monolithic H:"Merged hackity".
You can also do completely arbitrary stuff. It's very powerful. But I'm just repeating myself here. It really is one of those things you just have to try, I think - I know I didn't really grasp the power of it until I'd been using it for nearly a month, and I'm sure there's still lots of useful capabilities in there for me to discover.
- This means: no partial checkouts. This is a problem if you're used to versioning large binary files, or have large files which you won't care about for anything other than auditing reasons after a certain time.
Yeah, I agree with this. Git blazes along with the largest of code trees and keeps its history data nice and compact, but it's not so great for binaries. We use git for code and SVN for all our binary data, which is optimal for us as the binaries are unmergeable anyway and we've got workflows in place to deal with that issue.
Having a "common" project shared by several others is not possible.
I'm not sure what the scenario you're thinking of is, submodules have solved this for us.
- Unless you try the "submodule" support, which is a broken hack that can devour changes far too easily to trust it to end-users. And submodule support does NOT allow copies from one "submodule" to another, or to your main project. Not while retaining history, anyway.
Can you elaborate on this? We use submodules at work and we've never had any problem with them (short of the odd time someone forgets to git submodule update, but the lines in the git status output usually clue people in). What do you mean copying from a submodule to another? You mean like copying between repositories in general, which SVN externals couldn't do any better, or something more specific I've simply not run into?
Imagine doing this (half-asleep, bear with incorrect/silly git commands):
git pull master git branch mystuff
Two weeks go by, many, many changes have been made in master, and you do a ton of work in mystuff:
git checkout master git pull master git checkout mystuff git merge master//whatever the git command to forcefully set master to point at mystuff is, I'm barely awake here...
Oh, and in both cases, the merge turns into a single commit without so much as a pointer to the history. You can put that in the commit message yourself, if you like, that's your only option.
That's essentially all you can do with SVN. You don't have the ability to rebase or cherry-pick or otherwise fiddle with your commit history so as to get a clean straight-forward merge in SVN, and because of that merges are slow and usually painful. So while you could regularly merge to keep things sync'd and simple, nobody actually does that in practice. It leads to what many SVN based teams call "merge day" where it literally takes a day to merge in a feature branch and work out all of the conflicts.
The other issue is that branches have to be made on the server and then checked out separately, which makes them expensive. First you're polluting the global history, and second you have to do whatever build environment setup you do once you checkout your branch (you can "switch" your branch over which works in place, but that gets flakey as the things you're switching between diverge - maybe this has been fixed). So for any small-to-mid sized task you're (in practice) going to avoid creating a branch. You'll work right in trunk (master in SVN parlance). You won't make commits as you go, as those go straight to the server where they can never be erased, so your only "oops, undo that" feature you have is the undo buffer in your text editor, or picking and choosing lines from a diff, or sheer memory. And of course you *can't* make that one commit until you've pulled down all the changes that happened since your last update (yes, while your changes are sitting uncommitted in your working files), and those changes get dumped into your working copy as changes, indistinguishable from the code you just typed in diffs (except for conflicts, those get marked in the usual manner)...
All of those problems go away when you can easily merge, because then branches cease to be painful - but then I've found that the best merges Git makes are the ones you get from rebaseing or cherry-picking, which SVN cannot do.
When I was considering migrating from SVN to Git I checked out Hg as well since people were making a big deal bout it having a sane Windows UI and all that jazz (and we do a bunch of work on Windows at work). I admit I didn't do a very deep comparison, so maybe I'm selling Hg waaay short here, but Git impressed me and Hg didn't - Hg fans, correct me if I'm being ignorant. The things that stood out in my mind are:
Git was noticeably faster for almost everything.
Git had more options for rewriting history.
Git's SHA-hash-as-identifier feature is just plain sexy, especially since they can't ever get out of sync as Hg's revision numbers can.
In Hg's favor, Git has no (useful) GUI, but it didn't take long to learn the five or six commands I actually use regularly, and Git's documentation is very good so that was kind of a moot point.
I can't really imagine what I'd do with a distributed version control system
Like I kept repeating in my other post, you can actually use branches and commits as tools to aid your own work without affecting others or polluting the commit logs with junk "Work in progress" commits. That and you get sane merges. Both of those are huge, even if your team is just you and your imaginary friend.
We use it at work and it works much better than SVN did.
Apart from everybody's local copies, we keep a repository sitting on a central server. That repo's "master" branch is our release code and, since I'm responsible for the final product, I'm responsible for this branch. Our workflow is fairly simple:
Developer pulls down a copy of the master branch (this either creates a local copy or brings an existing copy up to date).
Developer hacks away, creating, deleting, and merging local branches as is convenient for them.
Developer finishes task.
Developer pulls down an update, bringing their local master in sync with the central master.
Developer git-rebases their code on the new master. What this does is it takes all of the changes they made since their code diverged from the master and applies them to the new master. Git will apply commits one at a time, pausing if it runs into non-trivial merges or anything else that needs to be dealt with by hand. This has proven to be a massive improvement over the old SVN approach of having the updates in trunk blindly dumped on top of your work as the conflicts tend to be smaller, clearer, and much more manageable. Not to mention that the developer who wrote (and understands) the code is doing the merge.
Developer tests their code.
If the code is bad, goto step 2. Otherwise the dev will collapse their many little "work in progress" commits into a single "feature implemented/bug fixed" commit.
Developer pushes their cleaned up commit as a new branch on the central server and alerts me to its presence.
I review the diff (practically a nop for trusted senior coders, for the rest, well, I'd be reviewing their stuff anyway).
If I don't like it I send it back, else I merge it onto the central master (guaranteed to be a trivial merge since they did the work of rebasing onto the latest code - Git calls these a "fast-forward" and I automatically reject anything that hasn't been properly rebased) and delete their branch from the central server.
Developer pulls down new master, deletes temporary local branches, rebases any other work in progress (or puts this step off, up to them, I don't give a damn as long as I get high quality patches in the end).
goto 1
Note that pushing to master doesn't break anybody else, ever, until they decide they're ready to deal with integrating their patch. Nobody ever does the, "Are you gonna commit first or should I?" thing anymore. Developers that are collaborating on a patch sync via a branch on the central server, or directly to each other's machines, or via emailed patches, whatever they want to do. Git doesn't care and neither do I.
It sounds like a lot of tedious work, but Git is just stupid-fast. In the common case the whole update master, rebase, cleanup commits, push cycle takes about as long as SVN used to take to update and then scan for changes and actually commit anything. In the uncommon case where there's a non-trivial merge, the merges tend to come out a lot cleaner since Git is trying to make your changes to the new master one commit at a time, rather than dumping all of the changes in master on top of your stuff (though it can also do that, if you happen to enjoy pain).
And while I prefer the manual approval approach (which scales by appointing trusted lieutenants to take over some of the work) since it keeps me in the loop and keeps everyone else honest, there's no reason you couldn't automate it. Some projects give everyone push access, but disallow anything but fast-forward (trivial nothing-to-merge) pushes to the central server, others I've heard of have people push to a staging branch and a bot on the server grabs the code, runs the test suite, and merges it if it's good. Access is ssh-based, and there are hooks all over the place, you can set up all sorts of schemes when it comes to control of the canonical central repo.
Yes, but in humans it's unusual and disruptive; thus it is a crime. For a lot of animals it's not only normal, but rather it's the only way to secure a mate.
Even if you were to abide strictly by the 2 quarters definition, I bet you couldn't give me a reason why it's 2 quarters and not 3 or 1.
Of course they know why it's two quarters. It's two quarters because defining it that way means we aren't in a recession yet. Once the two quarters rule is satisfied, the measure will change. Same as when we're measuring inflation or unemployment or the value of the currency or anything else. Economics, as it seems to be popularly understood, is neither science nor common sense. It is merely an extension of politics.
Ever heard of the French revolution? How about the Soviet revolution? Chinese revolution? Cuban?
Did you read the last sentence of my post?
Look at the state of the French government before the revolution, for instance. A weak king of a bankrupt nation who couldn't command the allegiance of his own nobles except with expensive bribes and positions in Versailles. The French Crown had been pissing away its power for decades before the mobs swept in at the very end to deliver the death blow. And then what happened? They immediately turned on each other and the Reign of Terror began. A mere four years after the end of that horror, Napoleon declared himself Emperor.
Lenin's revolution was against a government broken more by an ineffective leader and the strain of WWI. The "revolution" of the 90's was the old Soviet government finally crumbling under the weight of its own bureaucracy (the straw that finally broke that camel's back being buried somewhere in Gorbachev's reforms).
Mao fought against a hugely corrupt government still dealing with the aftermath of WWII. I'm pretty murky on my history here, but if I remember correctly the government was already dying under the weight of an economic meltdown, and the civil war wouldn't have been much of a fight had the US not poured support into the nationalist side (this was perhaps negated by soviet support for the Communists - though I can't imagine post-WWII Russia being able to match the level of support the US could have mustered at the time).
The Cuban revolution, I will admit, I know nearly nothing about, save that Batista's heavy-handed rule was massively disruptive and that he alienated any popular support he might have otherwise enjoyed.
Maybe if IT people weren't so busy turning their noses up at the "liberal arts", you might know a few things about history and how things work on this planet, and maybe, just maybe, you won't become the underpaid lackey of some jackass who went to b-school and believes that the earth was "created" 5000 years ago.
I'm not even sure what you're saying here, save that you mean to insult me, or "IT people", or creationists or something.
The fact is that peasant revolutions have been causing regular upheavals in the social order for millenia.
And my point is that peasant revolutions don't often happen until the government is already breaking under extrordinary external pressures or the simple weight of its own stupidity.
There are certainly countless examples of peasant rebellions being swiftly and decisively crushed by strong, competent (though not necessarily "good") rulers.
They are both recent books, dealing with the invasion of a future human civilization by a hostile alien force. But much much more then that too. Personally its not the excellent mystery, action or space battle parts which captivate me, but the 'positive' and 'real' extrapolations of society that he paints, as opposed to alot of sci-fi which paint a rather dystopia or exotic view of the future.
Not only that but, as you noted, the action, intrigue, sex and special effects are already in the book. They wouldn't even have to butcher it just to meet their silly N action scenes/minute requirements (or whatever the actual metric they have to hit is). I'd be at the front of the line if they made the Commonwealth Saga into movies.
What will happen? I can answer that in one word -- "rebellion"
Oh, please. We'd be too busy stabbing each other in the back, fighting for what little scraps they do leave us, to ever do them much harm. Much as it has always been.
What kills them in the end (because nothing can last forever) will not be a rebellion of the poor. It will be their own stupidity as they will, inevitably, become bored, complacent, decadent and distracted - random misfortune will do the rest. It won't be till the very end, when their power is already good as gone, that angry mobs storm the palace and take credit for the people's great victory.
It's pretty rare to have an account service fee (even one that's waived by keeping a certain dollar amount in the account) in the US.
That's something that's becoming more and more common here in Canada as well, so things may be changing. As for people paying fees on debit/ATM transactions those are usually fairly easy to avoid by simply using a credit card and paying it on time, or by withdrawing larger sums of cash fewer times throughout the month (the first X transactions are almost always free) and avoid using ATMs operated by another bank. Now whether people are generally bright enough to actually read the fine print is another matter entirely...
There are trade-offs, to be sure. But, in my opinion, bank fees I can easily avoid paying are far preferable to wondering whether my bank will be there tomorrow.
An idea that tried to remove the bonding aspect of sexuality was tried in nationalsocialist Germany ("Lebensborn"), but I don't know of any similar communist experiment.
They kinda-sorta tried, but nothing much came of it. My father had to read a book or listen to a lecture or something in school that described the super-happy awesome future world of Communism where people don't marry and children are raised by the state. He was very young at the time and the idea upset him a lot - the very opposite of what they were trying to do (win minds over from an early age). From what I understand, that sort of thing got quietly brushed away when later leaders saw they had to ditch the more ridiculous points of their ideology if they wanted to have any sort of country left to rule over.
The ending "ovo" (spelled "ogo") is used on a class of adjectives (those modifying singular masculine or neuter nouns in I forget which grammatical case). The 'n' comes in as part of converting the noun "svoboda" (freedom) into an adjective.
Gah. This would be easier if I could type Cyrillic characters in Slashdot comments. Anyway.
The first character is a sh-ch sound, where the sh dominates the barely pronounced ch to the point where most westerners wouldn't even hear it as distinct from the 'sh'. The 'e' is going to be pronounced 'yeh', but the 'y' part is very short and the 'eh' bit is short as well. The rest depends on where the stressed syllable is and I'm not sure of that. It's either Shchye-gah-le'-vuh or Shchye-go'-leh-vuh (I'm pretty sure it's the first one). The 'ah' is pronounced like the a in 'far', only shorter. The 'uh' at the end is like u in 'hut', but also shorter. And that's a 'soft' l, which means you pronounce it with your tongue a bit higher in your mouth, sort of like you're making the 'y' sound at the same time (if that makes any sense at all).
Disclaimer: I'm not Russian. I'm just studying it. Hopefully a native speaker will correct me if I've fucked it up. I'll correct myself if I hear it on the radio some time today (internet radio is an awesome way to pick up a language quicker).
Which raises an interesting question that no one seems to be asking: What if the problem is not Wikipedia at all? What if Wikipedia is a symptom of a much larger problem in our culture? What if the solution isn't to berate Wikipedia for that which they cannot fix, but rather to ensure the foundations upon which the system is based are fixed?
Sorry, but I don't even see the problem that needs fixing here. Wikipedia is a collaborative work of many authors, with a long and well documented history of bias and ideological conflicts. This is well known, and it's documented on numerous talk pages. There's no attempt at deception here that I can see, apart from the people who, for whatever reason, deceive themselves into thinking that it's a better source than it is. Consider the source and weigh that consideration against the standards you deem necessary for your intended purpose. You already have to do that with any other source - why should Wikipedia (or the news, or your politicians, or your preacher, or anyone) be treated differently?
The only problem I see is that people go about expect to have the truth (each with their individual notion of what truth is) served to them on a silver platter.
Eh. I'm a professional game developer and XNA is, IMHO, just fine for its intended purpose: XBLA-sized/hobbyist projects.
1) being tied to XBox.
Well, there's PC too, but you have a point about the other consoles. Although this isn't much of an issue for hobbyists, which it's meant for, who can't afford (and wouldn't be allowed to purchase) full dev kits anyway.
2) C#. I now code a web application in VB.NET, and it's great for this kind of task. But if you want to write a game, it's doomed from the beginning if you work in C#. Sure, it's great to use, but how can you trust a garbage collected language during in game ? Slowdowns may appear anywhere during a game, and such bugs are impossible to reproduce.
This one is actually not true. You work around the garbage collector the same way you work around malloc's poor performance. You simply don't allocate any new memory once you're done loading. Do that, and the GC will never run during gameplay, so you don't have to worry about it. There are even decent profilers that will tell you what's calling new (with a complete call stack) so you can track this stuff down fairly easily. All the PC development tricks apply, though some are perhaps more difficult since you don't get to reinterpret memory without doing a fair bit of work.
The thing you can't work around, however, is the miserably poor floating-point performance (the.NET CF JIT is simply garbage, and I doubt they'll ever fix it).
3) XBox: XBox is perhaps a success in US, but in the rest of the world, it's largely unknown.
If you want to make money, think: Wii, PS3 then XBox 360.
Thus far, it's the only one of the three that you can get dev rights to for ~$100. There's certainly some money to be made on it, though you're right, if you can afford to get onto all three consoles you'll make much more money doing that (and probably produce a better game with less effort, too).
It's an excellent hobby/homebrew tool, and a few good games will likely come of it, but you're right, it's never going to be fit for serious AAA game development.
Cartoonish art sells. Plenty of E-rated and E10+-rated games are based on cartoons. Even original franchises can adopt a cartoonish look: Jet {Set|Grind} Radio, The Legend of Zelda: The Wind Waker, and especially the Katamari series. The first three Katamari games use PS1-class models, which allows them to have PS3-class object counts on a PS2-class console.
Yes. And how dull the gaming world would be if all games looked like World of Warcraft/Legend of Zelda clones.
Look at any cross-platform title that has come out on DS and anything else, or one of PS2/PSP/Wii and one of Xbox 360/PS3. Cross-gen titles have to scale their assets, so why can't a PC game include both the PS3-class assets for recent NV/ATI and the PS2-class assets for Intel or older NV/ATI?
Cross-platform titles are budgeted, scheduled, and developed differently. Some of the ports are often done by other companies, and since the publisher owns the game it's not even possible to just take those assets and dump them into a patch for the PC game. You may care to do it to make the game look better, but your publisher would rather have you working on the next shiny title.
There's a solution for this. Make the core of the physics engine work in fixed time quanta (e.g. 60 Hz) on all platforms, and have the front end interpolate over that.
Except when the designers decide to rely on physics working thusly and being able to handle so many objects. Even at a fixed rate, the low end systems can handle fewer objects and game designers have to go around flagging non-essential things as "high end only". That, of course, now means the levels need to be tested twice, in case a designer mis-flagged something.
Console games have to work in both 50 Hz and 60 Hz too.
Again, different budgets and schedules. The publisher gives extra time and money to re-tune to 50Hz for the PAL release. This is why games often release at different times in different regions.
Most PC monitors are either close to 4:3 (e.g. 5:4) or really close to 16:9 (e.g. 16:10), to the point where players won't notice the tiny letterboxes. Or are you talking about running a game in a resizable window?
It's amazing how small a deviation from the standard size can be before fonts and window borders get that slightly-off look to them. Also, some monitors can be rotated, and graphics drivers now give the option to enable all sorts of strange resoultions which get scaled or letterboxed at that level. Yes, there are actually people that do that shit. We've had them scream at us. The different resolutions are also a big deal. On a TV, you have guidelines for what size fonts are visible, and once you know that you scale your font texture resolution to match what you're rendering at (another thing you know). On a PC, you know neither what resolution you'll render at, nor the physical dimensions of a pixel (and the display properties returned by the driver are not to be trusted), so you do a lot more work to A) match the font texture resolution to the screen resolution (often using multiple font textures) and B) test it on as many monitors as you can find to make sure it looks OK. Standard OS text drawing APIs don't work in D3D/GL windows, so you don't get to use all the work your OS vendor did dealing with those issues either.
But is it more work than rewriting the whole game in C# to run on Xbox 360 XNA or rewriting the whole game in Java to work on a phone that implements MIDP?
Why would I rewrite my game in C#? If the publisher wants me to port to the 360 they'll buy me a real dev kit, complete with a C++ compiler. As for handhelds, many of them have C APIs that you can get at with the right permission. And I've yet to see a significant game that isn't Quake 3 (which gets ported to everything more as a benchmark/hobby/bragging right than anything)
Nobody said I don't have a clue. I do openGL programming myself.
Didn't mean to insult you personally. I even acknowledged that I was ranting a bit.
The car you can tune as you want, but you pay for it, you have the most control, and the only thing that remains constant is the road (aka OpenGL).
No. The car you tune as you want. I have to train the driver to deal with a vehicle that's been modified in unknown ways. And if the car is only stocked with maps written in German, and you tell the driver "go there" and he can't figure out the way, you'll come over and yell at me for it.
Also, things such as specular lighting are not tough if that's your expertise.
That is my specialty, actually. And every time we add another graphics option I spend the next month going back and forth with QA and the artists, fixing bugs and explaining what they need to change in their textures (the ones they already spent ages tweaking) to make it look good with $SHINY_OPTION_X enabled. And then when the two can't be balanced they split the textures into "low" and "high" end sets and then I spend another month figuring out who's budget the extra data comes out of.
If it's not, and it's a pain in the ass to you, then GET ANOTHER PROGRAMMER TO DO IT. Jeez. Find specialties and go with it.
Right. Because skilled programmers are A) plentiful and B) don't cost anything. There's a publisher setting budgets and deadlines and expectations of marketable screen shots, remember? And assuming there were a magical free programmer fairy waving her wand around, bestowing me with brilliant coder minions, I'd put them to work making the good stuff look better and run faster, rather than rewriting and retesting the basic rendering pipeline half a dozen times.
Also, see zironics comment. World of warcraft looked like a 3 year old game from the outset; it sure hasn't stopped any sales has it?
See my comment. World of Warcraft has an art design that makes it look like it's supposed to look like a three year old game. And even if it didn't Blizzard is (and even back then, was) huge, and can throw its weight right back at any publisher that demands they change things. And even though, as I mentioned, they are improving the render quality - it took them how many years to add dynamic shadows (added this patch) to the game? Even they with their huge resources can't afford to just throw some programmers and a bit of QA at stuff call it done. They wouldn't be big, successful Blizzard if they did - and the way they handle release dates, pushing them back until "it's done", doesn't fly at any but the very biggest of companies.
That can't work for every game. Many games have different art direction (and games would be pretty dull to look at if they didn't). Many studios are small and are at the whim of a publisher. How do you make a game that doesn't look like a cartoon and requires close-up shots of people's faces look right on low-end hardware, without doing all the work twice, once for the low end and once for the high? You don't. It doesn't work that way.
Or there's that "minimum specs" idea, or using common sense to program for the lowest common denominator in a similar fashion to a console, no?
No. Programming for the lowest common denominator means making a game that looks five years old. Publishers will publish those games, but they will not market and sell them along with all the other big name titles. Blizzard gets away with low (though ever rising) min-specs on WoW because the game's art is cartoonish - it doesn't look like it should be ultra-realistic or anything. Most games, however, won't have art direction that allows similarly low min specs without giving the impression that the game belongs in the $10 bin. The only way to support a low min spec while pleasing publishers is to make content that scales, and that opens a whole new set of problems (unless you're huge and can throw your weight around like Blizzard). Now the physics engine needs to work in "low end" and "high end" mode (tons of testing and hunting for subtle bugs - who remembers the little bugs in Quake3's movement code that only show up when the server runs at certain multiples of some frequency?), and the graphics code ends up with separate code paths for "Intel Integrated", "old NVIDIA", "not-so-old NVIDIA", "recent NVIDIA", "bleeding-edge NVIDIA", "old ATI", the list goes on - all which the artists and designers then have to work around. The fact that all you see is a neat little "Graphics Quality" slider is a testament to some graphics programmer's hard work and his company's amazing QA team.
And it's never as simple as typing if( uber_shadows_supported ) here and there, as most of the "this game doesn't do much, it should run on my machine, this developer sucks for not supporting my machine!" crowd likes to scream. The available set of GL extensions and D3D capability flags varies hugely and in unpredictable ways across hardware, and even driver revisions, leading to many subtle bugs where features are half-implemented (*cough* ATI *cough*) or missing for no good reason (*cough* Apple) or implemented three times in three ways because the vendors couldn't agree on what to call a function (most any recent GL extension), and all sorts of crap like that. The amount of testing and bug-fixing even a single "enable shadows" option adds is massive. Also, once you have a moving target you lose the ability to fine-tune the art for the system. Suddenly you have to add things like low/medium/high-detail texture support (because you don't know what the target resolution is so you have no idea of knowing what resolution the game will ultimately run at), which means the artists have to do tons of extra work, which must be tested and reviewed, etc. Oh yes, resolution and aspect ratio. Because those can now be anything and the HUD has to do something intelligent about it instead of just throwing up the perfectly hand-tweaked 4:3 or the lovingly crafted 16:9 version, as you can do with a console.
And then, on top of that, every now and then the hardware companies will ship a driver that has a bug in it, or some malware will eat a critical file, or some other small catastrophe will befall one of your customers, and you'll have to hire a support department to tell people "upgrade your drivers", or "downgrade your drivers", and the all-time favorite, "You can get the latest drivers from your video card manufacturer's web site. What do you mean, 'What's a video card?'".
Gah. It's late and I'm ranting. I'll stop.
With a console, on the other hand, you know you have X CPU cycles, a GPU that can push Y triangles and shade Z pixels, and a memory buss that will transfer W bytes each frame. You decide what effects you want to see, you tell the artists "you have X triangles and Y MB of texture space - textures should have such and such dimensions per game unit", you tell the designers "X square meters of destructible wall, Y throwable objects, no more than Z players at a time", and then spend the time you used to spend dealing with o
Slashdot Mirror
I suppose the GP should be thankful for the lack of zebra crossings near Amtrak's operations...
When was the last time you used SVN? Everything you just said is very confusing, 1.5 came out over a year ago and seems to have most of the features you say it does not.
Chances are we never upgraded the server at work, or if we did it was after 2+ years of fearing SVN merges so I never noticed the new features. I've heard others that work with SVN say unflattering things about the automatic merge tracking but I have nothing but their word on that. Maybe they're wrong. I'd given up on SVN's merges long before 1.5 came out, and Git's other features are too compelling to warrant looking back.
As for rebasing, this is the first I've heard of it. It sounds interesting, but I don't really understand the problem it was meant to solve. :\ A single patch is too much, the actual VCS history is too much, so the ideal is offering a doctored up change history?
[...]
Just seems a little superficial to me
Wouldn't the end result be more interesting? I think good source comments with other documentation would be easier to understand and more proper than reviewing the change history of someone's patch.
Since when was how someone's patch was developed more important than what was developed? Isn't diving into the VCS to find reasons for something being just a sign that the code wasn't documented properly? So, yes, we dive into VCS history to solve preexisting documentation problems, but when it comes to accepting someone else's patch, isn't that the time to simply demand good comments and or documentation?
The second bit I bolded answers the question you raised in the first. You would clean up your commit history precisely because the contents are more important than the method. That meaningless history is only going to get in people's way if they have to go through the history, so why not replace it with something nice before sending your changes into the shared repository?
While you develop you want to use branches and commits however you see fit, making throw-away instances of each when you experiment with things, reverting old changes, etc (and if you don't see why that's a big deal, you're missing out). But when you submit you don't want people to see a bunch of "work in progress" commits, you want them to see something that reflects a logical breakdown of what you did so that each component can be considered/used on its own. Most of the history rewriting commands are for this. Rebase is a special case of cherry-picking that grabs your work and reapplies it to the current development head (usually, it can be whatever branch you like) so you get a nice clean patch relative to the current code, rather than to revision whatever-it-was-when-I-branched.
Say I write a complex patch that changes a bunch of existing code and then adds a bunch of new stuff on top of that. If the person who wrote the original code that I changed wants to review my work, it would be nice if he could just look up Changeset X: Refactored system X to add hooks for Y rather than digging through 25 tiny commits, mostly labeled "work, work" (or WIP or "undid crap" or whatever) which correspond more closely to my coffee breaks or the times I had to switch to something else for a second than it does to the code - or worse yet one giant commit that includes my changes to his stuff and a ton of stuff he doesn't care about since it's separate.
Cleaning up the history allows me to collapse many dozens of little WIP commits into "Refactoring system X", "Added module Y", and "Optimized module Z to use new hooks exposed in X". Once I do that the maintainers of X and Z immediately know what they need to look at to find the changes that impact them, without having to dig through Y's changeset for any buried changes of interest. That also makes it much easier to cherry-pick individual components of my work into other branches, or perhaps nuke module Y while keeping the new X and Z code. Rewriting history is a powerful ope
I remember seeing some sort of simple incrementing revision/commit number. It was a while ago and I'm tired now, so maybe I'm just confused or misremembering. Apologies if I've spread misinformation (and someone mod parent up if that's the case).
With subversion, don't you merge a specific range of revisions, such as "C->G" in your example?
Yes, but that gets screwed up all the time. I used to have a system of sticky-notes for tracking what I had/hadn't merged up to a given point and late at night during crunch when you just want the damn thing to work so you can go home you make an off-by-one error, and an i++ gets merged in twice in some ridiculously obscure code that you didn't even write, and you sit there an extra two hours tracking down your error. There are fancy little shell scripts that purport to do the same thing, but they get confused any time the commit graph gets...interesting. And in my experience a team of two people and a single common code file is enough to qualify as interesting with SVN.
Also, while maybe not as nice as git's merging, isn't subversion 1.5's merge-tracking exactly what you're talking about? Now the range of revisions doesn't need to be specified, AFAIK.
SVN 1.5 may have fixed this. I have heard that it's slow (as in "go get some coffee" slow), and I've heard claims that it breaks with complex histories (multiple branches merging in/out of trunk many times over the same period of time), but I've got nothing but word of mouth to back that up.
That aside, and as I've said a few times, the main thing that gives Git its merge power, I find, is its ability to rewrite history. You can literally reorder commits at will, and in many cases I have found that changing the order things are merged in makes a world of difference to how clean the result is, and how easy any conflicts that pop up along the way are going to be to clean up. As an example, we use Git's rebase operation as part of our workflow, which does this:
master: A -> B
git branch hackity
git checkout hackity
do some work
git commit
hackity: A -> B -> C
git checkout master
git pull master
master: A -> B -> D
git checkout hackity
git rebase master
hackity: A -> B -> D -> C'
Where C' is identical to C (it differs only in its parent commit and in any conflicts you may have had to resolve). You can then merge that into master without creating any new commits beyond C'. All it does is move the 'master' pointer down the graph to point to C' as its head commit, which is the definition of a fast-forward (it can do this since C' includes all of master in its ancestors). This gets really useful when you have C -> E -> F -> ... -> X to rebase as it will let you resolve conflicts as they come up one commit at a time instead of making you deal with everything in one enormous messy diff (though that option is available to you as well, if you wish) and that makes for a much quicker and easier job when you have to figure out what's going on, at least in my experience. And in the end you get C', E', F', etc, with their useful commit messages, instead of the monolithic H:"Merged hackity".
You can also do completely arbitrary stuff. It's very powerful. But I'm just repeating myself here. It really is one of those things you just have to try, I think - I know I didn't really grasp the power of it until I'd been using it for nearly a month, and I'm sure there's still lots of useful capabilities in there for me to discover.
- This means: no partial checkouts. This is a problem if you're used to versioning large binary files, or have large files which you won't care about for anything other than auditing reasons after a certain time.
Yeah, I agree with this. Git blazes along with the largest of code trees and keeps its history data nice and compact, but it's not so great for binaries. We use git for code and SVN for all our binary data, which is optimal for us as the binaries are unmergeable anyway and we've got workflows in place to deal with that issue.
Having a "common" project shared by several others is not possible.
I'm not sure what the scenario you're thinking of is, submodules have solved this for us.
- Unless you try the "submodule" support, which is a broken hack that can devour changes far too easily to trust it to end-users. And submodule support does NOT allow copies from one "submodule" to another, or to your main project. Not while retaining history, anyway.
Can you elaborate on this? We use submodules at work and we've never had any problem with them (short of the odd time someone forgets to git submodule update, but the lines in the git status output usually clue people in). What do you mean copying from a submodule to another? You mean like copying between repositories in general, which SVN externals couldn't do any better, or something more specific I've simply not run into?
Imagine doing this (half-asleep, bear with incorrect/silly git commands):
git pull master
git branch mystuff
Two weeks go by, many, many changes have been made in master, and you do a ton of work in mystuff:
git checkout master
git pull master
git checkout mystuff
git merge master
Or alternately:
git checkout master
git pull master
git merge mystuff
Oh, and in both cases, the merge turns into a single commit without so much as a pointer to the history. You can put that in the commit message yourself, if you like, that's your only option.
That's essentially all you can do with SVN. You don't have the ability to rebase or cherry-pick or otherwise fiddle with your commit history so as to get a clean straight-forward merge in SVN, and because of that merges are slow and usually painful. So while you could regularly merge to keep things sync'd and simple, nobody actually does that in practice. It leads to what many SVN based teams call "merge day" where it literally takes a day to merge in a feature branch and work out all of the conflicts.
The other issue is that branches have to be made on the server and then checked out separately, which makes them expensive. First you're polluting the global history, and second you have to do whatever build environment setup you do once you checkout your branch (you can "switch" your branch over which works in place, but that gets flakey as the things you're switching between diverge - maybe this has been fixed). So for any small-to-mid sized task you're (in practice) going to avoid creating a branch. You'll work right in trunk (master in SVN parlance). You won't make commits as you go, as those go straight to the server where they can never be erased, so your only "oops, undo that" feature you have is the undo buffer in your text editor, or picking and choosing lines from a diff, or sheer memory. And of course you *can't* make that one commit until you've pulled down all the changes that happened since your last update (yes, while your changes are sitting uncommitted in your working files), and those changes get dumped into your working copy as changes, indistinguishable from the code you just typed in diffs (except for conflicts, those get marked in the usual manner)...
All of those problems go away when you can easily merge, because then branches cease to be painful - but then I've found that the best merges Git makes are the ones you get from rebaseing or cherry-picking, which SVN cannot do.
When I was considering migrating from SVN to Git I checked out Hg as well since people were making a big deal bout it having a sane Windows UI and all that jazz (and we do a bunch of work on Windows at work). I admit I didn't do a very deep comparison, so maybe I'm selling Hg waaay short here, but Git impressed me and Hg didn't - Hg fans, correct me if I'm being ignorant. The things that stood out in my mind are:
In Hg's favor, Git has no (useful) GUI, but it didn't take long to learn the five or six commands I actually use regularly, and Git's documentation is very good so that was kind of a moot point.
I can't really imagine what I'd do with a distributed version control system
Like I kept repeating in my other post, you can actually use branches and commits as tools to aid your own work without affecting others or polluting the commit logs with junk "Work in progress" commits. That and you get sane merges. Both of those are huge, even if your team is just you and your imaginary friend.
We use it at work and it works much better than SVN did.
Apart from everybody's local copies, we keep a repository sitting on a central server. That repo's "master" branch is our release code and, since I'm responsible for the final product, I'm responsible for this branch. Our workflow is fairly simple:
Note that pushing to master doesn't break anybody else, ever, until they decide they're ready to deal with integrating their patch. Nobody ever does the, "Are you gonna commit first or should I?" thing anymore. Developers that are collaborating on a patch sync via a branch on the central server, or directly to each other's machines, or via emailed patches, whatever they want to do. Git doesn't care and neither do I.
It sounds like a lot of tedious work, but Git is just stupid-fast. In the common case the whole update master, rebase, cleanup commits, push cycle takes about as long as SVN used to take to update and then scan for changes and actually commit anything. In the uncommon case where there's a non-trivial merge, the merges tend to come out a lot cleaner since Git is trying to make your changes to the new master one commit at a time, rather than dumping all of the changes in master on top of your stuff (though it can also do that, if you happen to enjoy pain).
And while I prefer the manual approval approach (which scales by appointing trusted lieutenants to take over some of the work) since it keeps me in the loop and keeps everyone else honest, there's no reason you couldn't automate it. Some projects give everyone push access, but disallow anything but fast-forward (trivial nothing-to-merge) pushes to the central server, others I've heard of have people push to a staging branch and a bot on the server grabs the code, runs the test suite, and merges it if it's good. Access is ssh-based, and there are hooks all over the place, you can set up all sorts of schemes when it comes to control of the canonical central repo.
The thing we've found is that because we've all
Yes, but in humans it's unusual and disruptive; thus it is a crime. For a lot of animals it's not only normal, but rather it's the only way to secure a mate.
Because greedy corporate shill organizations are made and run by (some subset of) people, and that's just how (those) people are.
There's a difference between crimes of passion and having to battle your competitors (possibly to the death), don't you think?
Even if you were to abide strictly by the 2 quarters definition, I bet you couldn't give me a reason why it's 2 quarters and not 3 or 1.
Of course they know why it's two quarters. It's two quarters because defining it that way means we aren't in a recession yet. Once the two quarters rule is satisfied, the measure will change. Same as when we're measuring inflation or unemployment or the value of the currency or anything else. Economics, as it seems to be popularly understood, is neither science nor common sense. It is merely an extension of politics.
Ever heard of the French revolution? How about the Soviet revolution? Chinese revolution? Cuban?
Did you read the last sentence of my post?
Look at the state of the French government before the revolution, for instance. A weak king of a bankrupt nation who couldn't command the allegiance of his own nobles except with expensive bribes and positions in Versailles. The French Crown had been pissing away its power for decades before the mobs swept in at the very end to deliver the death blow. And then what happened? They immediately turned on each other and the Reign of Terror began. A mere four years after the end of that horror, Napoleon declared himself Emperor.
Lenin's revolution was against a government broken more by an ineffective leader and the strain of WWI. The "revolution" of the 90's was the old Soviet government finally crumbling under the weight of its own bureaucracy (the straw that finally broke that camel's back being buried somewhere in Gorbachev's reforms).
Mao fought against a hugely corrupt government still dealing with the aftermath of WWII. I'm pretty murky on my history here, but if I remember correctly the government was already dying under the weight of an economic meltdown, and the civil war wouldn't have been much of a fight had the US not poured support into the nationalist side (this was perhaps negated by soviet support for the Communists - though I can't imagine post-WWII Russia being able to match the level of support the US could have mustered at the time).
The Cuban revolution, I will admit, I know nearly nothing about, save that Batista's heavy-handed rule was massively disruptive and that he alienated any popular support he might have otherwise enjoyed.
Maybe if IT people weren't so busy turning their noses up at the "liberal arts", you might know a few things about history and how things work on this planet, and maybe, just maybe, you won't become the underpaid lackey of some jackass who went to b-school and believes that the earth was "created" 5000 years ago.
I'm not even sure what you're saying here, save that you mean to insult me, or "IT people", or creationists or something.
The fact is that peasant revolutions have been causing regular upheavals in the social order for millenia.
And my point is that peasant revolutions don't often happen until the government is already breaking under extrordinary external pressures or the simple weight of its own stupidity.
There are certainly countless examples of peasant rebellions being swiftly and decisively crushed by strong, competent (though not necessarily "good") rulers.
They are both recent books, dealing with the invasion of a future human civilization by a hostile alien force. But much much more then that too. Personally its not the excellent mystery, action or space battle parts which captivate me, but the 'positive' and 'real' extrapolations of society that he paints, as opposed to alot of sci-fi which paint a rather dystopia or exotic view of the future.
Not only that but, as you noted, the action, intrigue, sex and special effects are already in the book. They wouldn't even have to butcher it just to meet their silly N action scenes/minute requirements (or whatever the actual metric they have to hit is). I'd be at the front of the line if they made the Commonwealth Saga into movies.
What will happen? I can answer that in one word -- "rebellion"
Oh, please. We'd be too busy stabbing each other in the back, fighting for what little scraps they do leave us, to ever do them much harm. Much as it has always been.
What kills them in the end (because nothing can last forever) will not be a rebellion of the poor. It will be their own stupidity as they will, inevitably, become bored, complacent, decadent and distracted - random misfortune will do the rest. It won't be till the very end, when their power is already good as gone, that angry mobs storm the palace and take credit for the people's great victory.
It's pretty rare to have an account service fee (even one that's waived by keeping a certain dollar amount in the account) in the US.
That's something that's becoming more and more common here in Canada as well, so things may be changing. As for people paying fees on debit/ATM transactions those are usually fairly easy to avoid by simply using a credit card and paying it on time, or by withdrawing larger sums of cash fewer times throughout the month (the first X transactions are almost always free) and avoid using ATMs operated by another bank. Now whether people are generally bright enough to actually read the fine print is another matter entirely...
There are trade-offs, to be sure. But, in my opinion, bank fees I can easily avoid paying are far preferable to wondering whether my bank will be there tomorrow.
An idea that tried to remove the bonding aspect of sexuality was tried in nationalsocialist Germany ("Lebensborn"), but I don't know of any similar communist experiment.
They kinda-sorta tried, but nothing much came of it. My father had to read a book or listen to a lecture or something in school that described the super-happy awesome future world of Communism where people don't marry and children are raised by the state. He was very young at the time and the idea upset him a lot - the very opposite of what they were trying to do (win minds over from an early age). From what I understand, that sort of thing got quietly brushed away when later leaders saw they had to ditch the more ridiculous points of their ideology if they wanted to have any sort of country left to rule over.
The ending "ovo" (spelled "ogo") is used on a class of adjectives (those modifying singular masculine or neuter nouns in I forget which grammatical case). The 'n' comes in as part of converting the noun "svoboda" (freedom) into an adjective.
Gah. This would be easier if I could type Cyrillic characters in Slashdot comments. Anyway.
The first character is a sh-ch sound, where the sh dominates the barely pronounced ch to the point where most westerners wouldn't even hear it as distinct from the 'sh'. The 'e' is going to be pronounced 'yeh', but the 'y' part is very short and the 'eh' bit is short as well. The rest depends on where the stressed syllable is and I'm not sure of that. It's either Shchye-gah-le'-vuh or Shchye-go'-leh-vuh (I'm pretty sure it's the first one). The 'ah' is pronounced like the a in 'far', only shorter. The 'uh' at the end is like u in 'hut', but also shorter. And that's a 'soft' l, which means you pronounce it with your tongue a bit higher in your mouth, sort of like you're making the 'y' sound at the same time (if that makes any sense at all).
Disclaimer: I'm not Russian. I'm just studying it. Hopefully a native speaker will correct me if I've fucked it up. I'll correct myself if I hear it on the radio some time today (internet radio is an awesome way to pick up a language quicker).
Which raises an interesting question that no one seems to be asking: What if the problem is not Wikipedia at all? What if Wikipedia is a symptom of a much larger problem in our culture? What if the solution isn't to berate Wikipedia for that which they cannot fix, but rather to ensure the foundations upon which the system is based are fixed?
Sorry, but I don't even see the problem that needs fixing here. Wikipedia is a collaborative work of many authors, with a long and well documented history of bias and ideological conflicts. This is well known, and it's documented on numerous talk pages. There's no attempt at deception here that I can see, apart from the people who, for whatever reason, deceive themselves into thinking that it's a better source than it is. Consider the source and weigh that consideration against the standards you deem necessary for your intended purpose. You already have to do that with any other source - why should Wikipedia (or the news, or your politicians, or your preacher, or anyone) be treated differently?
The only problem I see is that people go about expect to have the truth (each with their individual notion of what truth is) served to them on a silver platter.
Eh. I'm a professional game developer and XNA is, IMHO, just fine for its intended purpose: XBLA-sized/hobbyist projects.
1) being tied to XBox.
Well, there's PC too, but you have a point about the other consoles. Although this isn't much of an issue for hobbyists, which it's meant for, who can't afford (and wouldn't be allowed to purchase) full dev kits anyway.
2) C#. I now code a web application in VB.NET, and it's great for this kind of task. But if you want to write a game, it's doomed from the beginning if you work in C#. Sure, it's great to use, but how can you trust a garbage collected language during in game ? Slowdowns may appear anywhere during a game, and such bugs are impossible to reproduce.
This one is actually not true. You work around the garbage collector the same way you work around malloc's poor performance. You simply don't allocate any new memory once you're done loading. Do that, and the GC will never run during gameplay, so you don't have to worry about it. There are even decent profilers that will tell you what's calling new (with a complete call stack) so you can track this stuff down fairly easily. All the PC development tricks apply, though some are perhaps more difficult since you don't get to reinterpret memory without doing a fair bit of work.
The thing you can't work around, however, is the miserably poor floating-point performance (the .NET CF JIT is simply garbage, and I doubt they'll ever fix it).
3) XBox: XBox is perhaps a success in US, but in the rest of the world, it's largely unknown.
If you want to make money, think: Wii, PS3 then XBox 360.
Thus far, it's the only one of the three that you can get dev rights to for ~$100. There's certainly some money to be made on it, though you're right, if you can afford to get onto all three consoles you'll make much more money doing that (and probably produce a better game with less effort, too).
It's an excellent hobby/homebrew tool, and a few good games will likely come of it, but you're right, it's never going to be fit for serious AAA game development.
Cartoonish art sells. Plenty of E-rated and E10+-rated games are based on cartoons. Even original franchises can adopt a cartoonish look: Jet {Set|Grind} Radio, The Legend of Zelda: The Wind Waker, and especially the Katamari series. The first three Katamari games use PS1-class models, which allows them to have PS3-class object counts on a PS2-class console.
Yes. And how dull the gaming world would be if all games looked like World of Warcraft/Legend of Zelda clones.
Look at any cross-platform title that has come out on DS and anything else, or one of PS2/PSP/Wii and one of Xbox 360/PS3. Cross-gen titles have to scale their assets, so why can't a PC game include both the PS3-class assets for recent NV/ATI and the PS2-class assets for Intel or older NV/ATI?
Cross-platform titles are budgeted, scheduled, and developed differently. Some of the ports are often done by other companies, and since the publisher owns the game it's not even possible to just take those assets and dump them into a patch for the PC game. You may care to do it to make the game look better, but your publisher would rather have you working on the next shiny title.
There's a solution for this. Make the core of the physics engine work in fixed time quanta (e.g. 60 Hz) on all platforms, and have the front end interpolate over that.
Except when the designers decide to rely on physics working thusly and being able to handle so many objects. Even at a fixed rate, the low end systems can handle fewer objects and game designers have to go around flagging non-essential things as "high end only". That, of course, now means the levels need to be tested twice, in case a designer mis-flagged something.
Console games have to work in both 50 Hz and 60 Hz too.
Again, different budgets and schedules. The publisher gives extra time and money to re-tune to 50Hz for the PAL release. This is why games often release at different times in different regions.
Most PC monitors are either close to 4:3 (e.g. 5:4) or really close to 16:9 (e.g. 16:10), to the point where players won't notice the tiny letterboxes. Or are you talking about running a game in a resizable window?
It's amazing how small a deviation from the standard size can be before fonts and window borders get that slightly-off look to them. Also, some monitors can be rotated, and graphics drivers now give the option to enable all sorts of strange resoultions which get scaled or letterboxed at that level. Yes, there are actually people that do that shit. We've had them scream at us. The different resolutions are also a big deal. On a TV, you have guidelines for what size fonts are visible, and once you know that you scale your font texture resolution to match what you're rendering at (another thing you know). On a PC, you know neither what resolution you'll render at, nor the physical dimensions of a pixel (and the display properties returned by the driver are not to be trusted), so you do a lot more work to A) match the font texture resolution to the screen resolution (often using multiple font textures) and B) test it on as many monitors as you can find to make sure it looks OK. Standard OS text drawing APIs don't work in D3D/GL windows, so you don't get to use all the work your OS vendor did dealing with those issues either.
But is it more work than rewriting the whole game in C# to run on Xbox 360 XNA or rewriting the whole game in Java to work on a phone that implements MIDP?
Why would I rewrite my game in C#? If the publisher wants me to port to the 360 they'll buy me a real dev kit, complete with a C++ compiler. As for handhelds, many of them have C APIs that you can get at with the right permission. And I've yet to see a significant game that isn't Quake 3 (which gets ported to everything more as a benchmark/hobby/bragging right than anything)
Nobody said I don't have a clue. I do openGL programming myself.
Didn't mean to insult you personally. I even acknowledged that I was ranting a bit.
The car you can tune as you want, but you pay for it, you have the most control, and the only thing that remains constant is the road (aka OpenGL).
No. The car you tune as you want. I have to train the driver to deal with a vehicle that's been modified in unknown ways. And if the car is only stocked with maps written in German, and you tell the driver "go there" and he can't figure out the way, you'll come over and yell at me for it.
Also, things such as specular lighting are not tough if that's your expertise.
That is my specialty, actually. And every time we add another graphics option I spend the next month going back and forth with QA and the artists, fixing bugs and explaining what they need to change in their textures (the ones they already spent ages tweaking) to make it look good with $SHINY_OPTION_X enabled. And then when the two can't be balanced they split the textures into "low" and "high" end sets and then I spend another month figuring out who's budget the extra data comes out of.
If it's not, and it's a pain in the ass to you, then GET ANOTHER PROGRAMMER TO DO IT. Jeez. Find specialties and go with it.
Right. Because skilled programmers are A) plentiful and B) don't cost anything. There's a publisher setting budgets and deadlines and expectations of marketable screen shots, remember? And assuming there were a magical free programmer fairy waving her wand around, bestowing me with brilliant coder minions, I'd put them to work making the good stuff look better and run faster, rather than rewriting and retesting the basic rendering pipeline half a dozen times.
Also, see zironics comment. World of warcraft looked like a 3 year old game from the outset; it sure hasn't stopped any sales has it?
See my comment. World of Warcraft has an art design that makes it look like it's supposed to look like a three year old game. And even if it didn't Blizzard is (and even back then, was) huge, and can throw its weight right back at any publisher that demands they change things. And even though, as I mentioned, they are improving the render quality - it took them how many years to add dynamic shadows (added this patch) to the game? Even they with their huge resources can't afford to just throw some programmers and a bit of QA at stuff call it done. They wouldn't be big, successful Blizzard if they did - and the way they handle release dates, pushing them back until "it's done", doesn't fly at any but the very biggest of companies.
That can't work for every game. Many games have different art direction (and games would be pretty dull to look at if they didn't). Many studios are small and are at the whim of a publisher. How do you make a game that doesn't look like a cartoon and requires close-up shots of people's faces look right on low-end hardware, without doing all the work twice, once for the low end and once for the high? You don't. It doesn't work that way.
Or there's that "minimum specs" idea, or using common sense to program for the lowest common denominator in a similar fashion to a console, no?
No. Programming for the lowest common denominator means making a game that looks five years old. Publishers will publish those games, but they will not market and sell them along with all the other big name titles. Blizzard gets away with low (though ever rising) min-specs on WoW because the game's art is cartoonish - it doesn't look like it should be ultra-realistic or anything. Most games, however, won't have art direction that allows similarly low min specs without giving the impression that the game belongs in the $10 bin. The only way to support a low min spec while pleasing publishers is to make content that scales, and that opens a whole new set of problems (unless you're huge and can throw your weight around like Blizzard). Now the physics engine needs to work in "low end" and "high end" mode (tons of testing and hunting for subtle bugs - who remembers the little bugs in Quake3's movement code that only show up when the server runs at certain multiples of some frequency?), and the graphics code ends up with separate code paths for "Intel Integrated", "old NVIDIA", "not-so-old NVIDIA", "recent NVIDIA", "bleeding-edge NVIDIA", "old ATI", the list goes on - all which the artists and designers then have to work around. The fact that all you see is a neat little "Graphics Quality" slider is a testament to some graphics programmer's hard work and his company's amazing QA team.
And it's never as simple as typing if( uber_shadows_supported ) here and there, as most of the "this game doesn't do much, it should run on my machine, this developer sucks for not supporting my machine!" crowd likes to scream. The available set of GL extensions and D3D capability flags varies hugely and in unpredictable ways across hardware, and even driver revisions, leading to many subtle bugs where features are half-implemented (*cough* ATI *cough*) or missing for no good reason (*cough* Apple) or implemented three times in three ways because the vendors couldn't agree on what to call a function (most any recent GL extension), and all sorts of crap like that. The amount of testing and bug-fixing even a single "enable shadows" option adds is massive. Also, once you have a moving target you lose the ability to fine-tune the art for the system. Suddenly you have to add things like low/medium/high-detail texture support (because you don't know what the target resolution is so you have no idea of knowing what resolution the game will ultimately run at), which means the artists have to do tons of extra work, which must be tested and reviewed, etc. Oh yes, resolution and aspect ratio. Because those can now be anything and the HUD has to do something intelligent about it instead of just throwing up the perfectly hand-tweaked 4:3 or the lovingly crafted 16:9 version, as you can do with a console.
And then, on top of that, every now and then the hardware companies will ship a driver that has a bug in it, or some malware will eat a critical file, or some other small catastrophe will befall one of your customers, and you'll have to hire a support department to tell people "upgrade your drivers", or "downgrade your drivers", and the all-time favorite, "You can get the latest drivers from your video card manufacturer's web site. What do you mean, 'What's a video card?'".
Gah. It's late and I'm ranting. I'll stop.
With a console, on the other hand, you know you have X CPU cycles, a GPU that can push Y triangles and shade Z pixels, and a memory buss that will transfer W bytes each frame. You decide what effects you want to see, you tell the artists "you have X triangles and Y MB of texture space - textures should have such and such dimensions per game unit", you tell the designers "X square meters of destructible wall, Y throwable objects, no more than Z players at a time", and then spend the time you used to spend dealing with o