Nope, The 360 definately uses an emulator. Each game has an "emulation profile" that enables/tweaks the standard emulator to be able to play that game. Think of it as a sort of patch for the emulator thats specific to the game. These are the files that came on your 360 hard drive, that you download automatically the first time you put a supported game into your 360, or that you install from the downloadable CD ISO they make available for each back-compat update.
This is actually one area in which Nintendo lags behind. Each Virtual Console re-release is a Wii executable containing the system emulator and the ROM in one package. If you've got 3 downloaded NES games, you've got 3 NES emulators. This is really silly when you think about it, These older systems have been emulated stably for many years with a single executable, and for some NES/TG16 ROMS, the emulator alone is several times larger than the ROM itself.
How about you bring ScummVM to the Virtual Console line-up? I know its not really a console, but there's no denying that there's a *ton* of popular games just waiting to be revisited, and you've got the perfect input device to do so.
I drive a '96 cavalier; Its not stylish, its not particulalry fast, no power windows or locks and due to some dings, its not even orthogonal anymore. But it was cheap, relatively fuel-efficient, reliable and it gets me from A to B as fast as I'm otherwise allowed.
We geeks tend to pine over these sleek ISAs like MIPS or Power in much the same way that car enthusiasts wax romantic about the latest sports car. For most of us however, practicality forces us to drive more modest vehicles. Its not practical to drive a vehicle that requires some exotic fuel in the same way that its not practical to run a CPU that digests some exotic instruction set, and for the same reasons: Limited use and availability leads to higher cost-of-ownership overall. Economies of scale and past investment lead to comparatively rock-bottom prices.
The PC is also bogged by something far more sinister than the x86 instruction set, namely, the PC BIOS. This is only just beginning to go away with Apple having adopted Intel's EFI firmware (OpenBIOS on their PPC systems before that) and the growing list of LinuxBIOS supported motherboards (still not ready for personal use, but getting there). Widespread EFI adoption might take place if Microsoft releases a home OS with the capability of using EFI without the BIOS compatability layer.
Another point to watch for in the future is the proliferation of platforms such as the CLR (.NET) and to a lesser extent, the JVM. These sort of platforms serve as an abstraction layer between the instruction set the software is written in, and the instruction set of the hardware on which it runs. With a performance difference of 10% or so now, and that difference shrinking as the technology matures, we'll begin to see that the underlying architecture will loose its hold on being the defining element of the platform. We're already beginning to see x86 technolgy moving towards extensions to make virtualization (such as Xen) more efficient, and I suspect it will not be long before it moves to include features to make the.net platform and similar technologies run more efficently as well. If these sort of technologies eventually become the defacto target for software, we may see a future in which the CPU's sole purpose becomes to efficiently support a higher-level platform that is defined by software.
In the Embedded world, x86 does not reign - in fact, x86 is a very small portion of the embedded market. PowerPC rules, followed by ARM and 68k, this doesn't even mention smaller processing tasks run by Microcontrollers like the 8051 or PIC devices. x86 has all but been ousted where engineers are freed from the concerns of backwards compatibility and high performance is not required.
Nights is the one game I'm gauranteed to play when I pull out my Saturn for some retro gaming (Before anyone challenges my geek points over my definition of "retro" please note that the SNES and NES are perminantly connected to the television.) It's a crying shame that a Nights sequel didn't help launch the dreamcast, let alone that it never appeared on it period -- it was rumored to be in production at the time of the DC's demise. I'm glad to see a remake on the way, and I think the Wii will serve it well from a control standpoint; That said, for a game that was so beautiful on the underpowered Saturn, I wonder how gorgeous it could have been on the 360.
The only thing that sucked about Nights was the draw distance.
Honestly, its not so much that these games were hard back in the day (I recall seeing TMNT beaten many, many times) as it is that most games today are so joke easy that we've lost perspective on what "hard" really is. Add to that the fact that the skillset for most 3D games is vastly different than that of the 2D variety, and its no wonder we bitch and moan about "how hard these old games were."
I've played games recently, for nostalgia, that I remember being no problem for my 3rd-grade self, yet today, at 23 years old and ~15 years more experience in gaming, these same games kick my ass. Perfection and skill are no longer a requirement of today's games and rarely even rewarded with anything more than a higher score. Games today are designed to allow even mediocre players through, the publishers and the marketting folks require it. Games that are "too difficult" are often panned in reviews. This is mostly a function of the mainstreaming of the games industry that began with the Playstation, and of the aging of the original gamer demographic who are now reaching their 20s-30s (and in some cases 40s) who are finding less and less time to master their new games.
Flash. Better yet, removable flash, SD to be exact. This is the key to the DS being able to support a Virtual Console-like feature. And since we've got the memory now. How about an integrated music/video player?
Camera. Integrate it so that it can face front or back so you can use the screen as a view-finder or so your opponents can see you as you play. Great possibility for some innovation there as well.
Virtual Console. Seriously guys, the DS is more than capable of running the vast majority console games up through the SNES, and any prior handheld as well. I'd love to see some gameboy classics brought back through GB Color emulation, some portable SNES/NES goodness and some GameGear / Master System greats revived as well.
It may be too late for the DS to gain all these things in an official way (Though a special cartridge would be a possibility) but at the very least I hope Nintendo can keep these in mind for their next portable.
While D3D 10 won't be making its way to XP, I don't believe they've ruled out the possibility of an update to D3D 9 adding the new features. Generally, such big features would be a new version number, but numbering schemes don't have to make sense when the marketting folks get involved. D3D 10 and how it works has much more to do with what functionality takes place where (hardware, kernal drivers, or userspace drivers) than what features are exposed. Its simply not possible to take the D3D 10 API and impliment it on the XP driver model without signifigant performance penalties -- If you push all the (Vista) userspace driver functions into a (XP) kernal driver, the overhead of switching from user-space to kernal-space so frequently will kill performance.
Much of the benefit of D3D 10 stems from the new driver model: fast context switching, minimization of the small batch problem, etc. Mind you, D3D 9 would require some signifigant updates to utilize the geometry shader (particularly because it sits between the current vertex and pixel shader stages. It can't just be tacked onto either end.) but there's nothing, technically, which would proclude the GS stage to be exposed.
If we don't see the new hardware features exposed in a D3D 9 update, it'll simply be because Microsoft didn't see any benefit in performing the extra work it would require of them.
As for spurring OpenGL on XP, I think it will. However, until the ARB (now Khronos) adopt an official extension, developers will have to provide seperate paths for each vendor's specific geometry shader extensions - Presuming AMD/ATI expose it in their GL drivers for their next gen cards.
Honeslty, I've been waiting for an HDMI 360 with built-in HD-DVD drive. The latter doesn't seem to be the case though; but I'd buy a second 360, the elite, if it had and keep the "old" model in my room next to the PC to test my XNA projects. I'd love to have the HD-DVD functionality in my living room, but the add-on drive, like all add-ons, is clunky and ugly.
Without built-in HD-DVD its worthless to me.
For about a hundred bucks I can pick up a 120gig drive and a copy of Norton Ghost, clone my data over to the new drive and slap it into the 360 (yes, this actually works.) For a few bucks more I can pick up any color of RIT vinyl/plastics dye in any color I want - just waiting on my warranty to expire before I crack it open to dye it, and While I'm at it I can swap out the LEDs for some nice blue ones.
While pirating games on the PC is much more attainable than on the console (no modding required,) there is more to it than simple piracy.
Probably the largest factor is that, today, console games are where the sales are at. A "hit" game on the PC might sell 250k copies, where on the console it would be at least a million. Of course, there are examples like WOW, that have become massive enterprises unto themselves, but for the run-of-the-mill AAA PC title those kinds of numbers are only a dream. The PC simply does not touch the consoles in terms of sales potential. Sure there are more PCs in the world, but how many of those are used primarily for gaming, or even gaming at all (excluding casual games, which we're not talking about.)
As budgets for triple-A titles grow larger, you can only respond in so many ways without raising prices on the game itself: Opt to keep the budget small (lower development costs), increase your potential consumer base (more platforms), or charge for "extras" (expansions, subscriptions, micro-transactions.)
In the end it's all business and a simple investment-benefit calculation: They believe that targeting consoles will bring in more money than what the additional work will cost them. As game budgets continue to grow, while simultaneously tipping more and more towards the cost of developing the artistic assets and the code behind the game makes up less and less, it only makes sense to hit as many targets as possible if the art assets can be shared with minimal or no tweaking, even to the point that it will make sense even if little of the code is shared between platforms -- which we'll see more and more of with the architectural differences between the 360, PS3, Wii and PC.
I live in Washington state and also had a non-compete agreement for my job as a software developer. However, the terms in my contract were much narrower. Working for what was essentially a software-for-hire, services-based company, my contract stated that for the period of 6 months after my employment I could not perform a competing service for any clients of my previous employer.
Essentially I could work for a competing company so long as I didn't work for any of my previous company's clients, and I could work for those clients as long as I was working on a different problem. I think that was very fair.
Your clause saounds much more draconian than that. It sounds more like it's meant to punish you for leaving, rather than to protect your employer's client and IP assets.
Maybe you could get them to accept similar terms to mine in leu of their "standard" clause, and maybe get them to adopt it instead?
The tone is a bit too strong and the sensationalist title is too much, but their underlying premise is certainly not without reason. There are a few facts to go on:
A lot of children have relatively unmonitored access to the Wii, perhaps in their own bedroom or play room.
A lot of parents *don't* know about the Wii's internet capabilities. Many of those that *are* aware, assume that the content is somehow filtered.
A lot of parents *don't* know about the Wii's child protection features, account controls, etc. - I'm not sure what's required to download the browser, but if no credit card is required and no admin-like privileges are required or set up, then its possible for them to download the browser themselves.
While the tone of the press release is too strong as I said above, I think we can all see that, yes, the Wii can be used to access porn, chat rooms, etc that may be innapropriate for young people. I think we can all agree that, yes, all parents should be aware of this reality and take steps they deem appropriate, but many are simply not aware at this point.
This isn't another "Video games are the devil!" argument, no one's calling for a boycott of the Wii, or for Nintendo to be held responsible for the content some children might access... beyond the slightly sensational tone all I see is information that is usefull and pertinent for parents.
No one here would turn their kid loose on the web without proper protection/monitoring in place, or at the very least recognize the risk in doing so. We forum-goers are always calling for parental and personal responsibility, for good reason, and I don't see this press release as doing much else.
Sony has done absolutely *nothing* right this generation. They're too late, with technology to match their intended launch date of last year. They threw in a GPU too late to the game because they thought their wonderfull cell processor would make a powerfull enough GPU. The cell is nice in theory, but there's too many restrictions and memory-wrangling in practice. They're up against the 360, with a 10+ million installed base, second-gen games, and a lower price point - Oh and Halo 3 is due out this holiday season or there about. They're up against the Wii at less than half the price, and cheaper games they can't match on innovation. The launch catalog was anemic with no real stand-outs, and there's nothing big on the radar except MGS4. They're losing exclusive third-party titles left and right to the 360.
Devs are comfortable on their competitors' machines - The Wii is just a faster gamecube (literally) with a neat controller, and while the 360 is relatively complex they've got wonderful top-notch tools to support development and an architecture thats doesn't have a split memory model or hobbled assymetric CPU.
Despite the high price, they're loosing about $175 - $225 per unit (depending on the model) while their competotors' machines are already profitable hardware. Nintendo has never sold an unprofitable machine, and right now, Microsoft could give consumers a $50 price drop and take each new owner out to lunch before they would go back into the red.
Mark my words -- If the earth doesn't shake for Sony real soon they'll be a distant third this time around, and may be foreced to drop from the race early or even for good, and if Sony's game division fails its going to make a huge hit on the entire company's bottom line.
They're arrogant over an overpriced architecture that hurts more than it helps, all in the name of pushing their BluRay format.
Don't plasma tubes fail after some 3-5 years? Not only do they cost 2-3 grand to begin with, but when the tube goes there's no practical point in replacing it since it costs nearly as much as a new plasma screen to do so.
But maybe I've heard wrong, anyone know?
I just got a 46" samsung DLP a couple months ago and I couldn't be happier with it.
There are a few things that are possible besides simply rescaling the final output. One thing they can possibly do is trap the call to set the Matrix for output to a standard def screen and instead set it for a high-def resolution. Some PC emulators which map the 3D emulation onto OpenGL/D3D do this. The textures themselves are not more detailed (unless they applied techniques to solve this as well) but because each polygon would cover more pixels, the texture sampling is more fine-grained, resulting in somewhat clearer visuals. Though, this technique may not apply to PS2 games since the original graphics chip is included. The PS3 isn't so much an emulator in the traditional sense, it just includes the important bits of PS2 hardware. The software portion of the "emulator" basically maps the PS3 IO hardware onto an interface that the PS2-on-a-chip uses, and appearantly, also does some post-processing/scaling of the framebuffer.
Old 3D games do look pretty crappy on new TVs, particularly the N64 which had a bug in its silicon that resulted in overly blurry visuals (it was supposed to be a form of anti-aliasing.) Sprite games still look great however, particularly the colorful ones. Super Mario World (from a SNES over S-Video, not emu or wii ware) on my 48" DLP looks amazing.
Microsoft is actually doing all these things and a little more to boot.
As a game developer, DX10 really is moving in the right direction.
In D3D10 for instance, much work has gone into solving the "small batch" problem - a condition caused by the fact that state-changes (binding different textures, shaders, etc) are so expensive on today's 3D accelerators that processing many small batches can severly impact performace. Developers end up jumping through a lot of hoops in an attempt to optimally batch their triangles. This and other improvements to D3D10 have cut overhead by approximately one-half. They've also removed the capability-bits mechanism in favor of the more-defined feature compliance you mentioned. Cap bits were terrible because they only told you if a feature was supported, nothing about performance - Intel's Integrated graphics only support software vertex shaders (in the driver) for instance. Other accelerators make similar claims, or outright don't support a feature their caps bits claim to.
Microsoft is also pushing the play-from disc technology as well, though its slow to be embraced. For some reason, game devs are reluctant to do things differently than the way they've always done things, even if it is better - See all the bitching about migrating to the LUA profile model in Vista. The groundwork to do this is there now, its simply a matter of developers starting to make use of it.
PC joypads are also starting to come together now that Microsoft is pushing XInput over DirectInput. XInput not only provides a clean API to xbox-style gamepads, but also defines certain layout constraints. Things like the primary axis being the left thumb-stick, or button 1 is the 6'oclock face button. You'd be amazed at the amount of difference in non-XInput PC gamepads have in this area, "button 1" might be the 6'oclock face button on one pad, or the left trigger on another. This amount of variance is the primary reason that gamepad support is almost non-existant on most PC games, realisticly you'd have had to impliment a completely configurable control scheme, or not bother with it at all. Given the lack of a standard layout and the fact that it had to support every input device under the sun (gamepads, throttles, flicktsicks, peddals, etc) DirectInput became a unnecesarily large and comlex API. XInput pretty much solves everything from a developer standpoint, and its nice be able to take your Xbox 360 controllers to your PC when you need a gamepad; One (or more) fewer controllers to own and keep charged up.
The final big thing MS is doing to make the PC a more console-like experience is to bring XBox Live to the PC. Hopefully this will bring the days of everyone having different, half-finished or buggy multi-player lobbies to an end. A lot of companies have developed solid and featureful in-house implimentations over the years, aleviating the second two problems, but having a more unified experience is quite nice and will allow games companies to spend less time developing and maintaining their proprietary lobby systems. On top of that, there's now the possibility of playing PC vs Xbox 360.
In short, Microsoft is doing a lot to make the PC a more console-like experience, both from the developer's side and the user's side, but I still disagree with the grandparent that the PC will ever subsume the role of the console. People use consoles because they are stupidly easy to use. There's no worry about minimum specs or the quality of system components having a negative impact on performance. There's no worry about spyware or trojans. There's no worry that the input device you just picked up won't work well. Some of these problems are simply not solvable on the PC without pandering the a least-common denominator.
Linux and other FOSS Operating Systems will be able to ride the wave this will bring as well. Khronos is already working on OpenGL 3 specs which will streamline the API and bring it inline with D3D10 features, much in the same way that D3D10 is a streamled evolu
Its bad enough to post dupes, but this one is terrible. Its basically twice-chewed information, an article about an article about an interview. Not only that, but this article seems to carefully choose which parts of the original article to leave out, presenting a biased, if not untruthful, view of the original information. Then they go one further, in traditional slashdot fashion, and give it some alarmist title to grab attention.
At least the title doesn't twist the article, but the context is more that he's happy as-is with XP, believes that they could back-port DX10 to XP, and that Vista isn't yet widely distributed enough to make business-sense to migrate development to it exclusively. DX10 isn't worth porting to for a game thats based on the Doom 3 engine and has probably been in development for 1-2 years? Big suprise there.
Dispite some bad dealings with Nintendo in the past, he's actually interested in doing some DS/Wii stuff, acording to the original article.
My understanding is that slashdot has editors, perhaps they should make some editorial decisions on what (not) to post.
As an independant games developer, I'm honestly not all that concerned. Here are a few reasons why:
1) Most people probably won't even turn the protection system on. 2) You can make specified games exempt, or enable them per user. 3) If it becomes that big of an issue, the system is able to support other ratings boards. An Indie-focused organization could be set up to rate games using volunteers and accept donations from indie devs and individuals.
Yes, its a minor hassle. So is the migration to the LUA model. I think we can all agree that both moves are good.
Do we really want a company now owned, unfortunately, by MTV in charge of a game about music?
I'd hate to see our precious Guitar Hero slowly transformed from "All Music, All the Time" into a reality-TV-like Sims starring drunk and likely bi-polar college age kids with little or no personality.
Its best this game stay as far away from MTV as possible.
Actually, You've got it wrong. The PPC core in the PS3 is the exact same as the 3 in the Xbox 360. With the exception of different interconnects to the rest of the stuff in the CPU and the rest of the system, the feature set is identical, even including the extended VMX128 instruction set which removes some standard VMX instructions while adding 96 registers (128 total) and some new instructions (such as a dot product.) Both cores feature dual-threaded in-order exectution, a feature derived from an earlier IBM prototype designed to make a highly cost-effective, but performant, PPC CPU. The Cache system on the 360 does allow portions of the cache to be locked down, or bypassed, but thats a feature of the cache rather than the CPU core itself.
You're wrong again on the Wii CPU, which is not at all related to the Cell/360 PPC cores or their common ancestor. The Wii CPU impliments the same exact instruction set as the CPU in the Gamecube, albeit die-shrunk thanks to a smaller process and that its clocked 1.5x faster in Wii mode. Aside from the process-shrink, IBM applied more modern materials and gating techniques to reduce power consumption and there may be some differences in the actual silicon implimentation of the various instructions (though implimenting the same function.)
The Wii and Gamecube CPUs are derived from a G3-class PPC processor, which Nintendo contracted IBM to extend to their specifications. One change is that the 64bit FPU was extended to include instructions which operate on pairs of 32bit floats, SIMD style (which I believe are mapped to normal VMX instructions, though I'm not sure) which was cheaper than implimenting a stand-alone VMX unit (which would have been a full 128 bits wide and doubled the die-size.)
As a side-note -- We can probably look forward to an even smaller and cheaper gamecube next year that will utilize reject Wii parts: Processors which don't quite make the Wii speed-grade along with the Wii's combined GPU/SRAM chip which contains a faster (again, 1.5x) GPU and the gamecube's 24MB of 1-T SRAM. The new revision will probably be half-height and passively cooled. It might even fit in a large pants pocket.
While I believe your comments to be a little extreme (and I'd probably accuse you of tin-foil-hat-ery if I wasn't so sure I'd only be the last in a very long line:) ) I just thought I'd drop some relevent information.
For a burgioning DirecX competitor, check out The Khronos Group's OpenKode specification. Basically, it's a suite of Multimedia APIs including Graphics, Sound and Multimedia technologies based on open APIs such as OpenGL, OpenGL|ES, OpenVG, OpenSL, OpenML, and Collada. It also defines some level of abstraction for hardware and OS interaction: input and display surfaces for instance. Khronos and OpenKode (or portions thereof) are backed by several industry heavyweights including Nvidia, ATI/AMD, Intel, Sony, Creative Labs and others.
Sony has already adopted a version of OpenGL|ES and collada for the PS3, and likely the best way to foster a cross platform DirectX is to urge Sony, Nintendo, Apple, PC hardware vendors, and even [Gasp!] Microsoft to participate in its development by joining with Khronos to further define the APIs and by adopting, or at least supporting, them in their products.
Live on the PC is not a clone of XBox Live in the strict sense. For example, the article clearly demonstrates that they don't expect that gamers will suddenly pony up $50 bucks a year to simply play PC games online and that they intend to provide other value to make the subscription service more attractive (but ultimately optional it would appear.) As far as Mods (in the sense of Counter Strike) I see no reason why they would be effected since they run on top of their base game. As for Mods in the sense of cheats, anything that limits their use and can be used to identify, and potentially ban, problem players is a good thing, IMHO.
An important bit of information that's not widely known yet, is that Microsoft is opening up Live to Developers so that they can run their own game servers connected to the Live network. There's a paper they published awhile back that I've read (I believe it was a GameFest paper) that specifies the requirements as set forth by Microsoft (one requirement is that there is a seperate, security proxy between the game server and Microsoft's central Live servers) and how to go about implimenting Live in your title. The gist is that the game goes through live to find the server, There's some securities checking, player profile stuff, and then the game is connected to the Company's own server. For a company running their own server, I don't see any reason why it couldn't support Cross-platform (Linux, Mac, etc.) play, though other platforms would have to connect through the normal means.
And of course, the Graphics API has nothing to do with network play.
In addition to Osty's very good points, I'll give you another one: Standardization.
The largest headache with DirectInput was that it supported every device under the sun and there was absolutely no standard as to which Buttons/D-pads/Sticks/Triggers on the physical device mapped to which logical button/axis. Which is to say that "button 1" might very well be the 6 o'clock face button on one device, and it might be the secondary left shoulder button on another. Even ignoring that, the sheer breadth of devices was a nightmare. Things ranged from very simple digital D-pad + 4 buttons, to full flight-sim gear with 4+ axis and many tens of buttons. All of this through a single interface. It was overly complex for 99% of everything it was ever used for and for the 1% that benefitted from such a bewildering array of options, was still increadibly obtuse.
Ignoring the API (Which is joke-easy by the way; I implimented an Xinput interface through my own abstract control interface in 30 minutes, never having seen a single line of XInput code before.) what XInput does is provide a standard for the controler's physical layout. In XInput, "Button 1" is always the six o'clock face button, and the primary X/Y axis is always mapped to the left thumbstick for example. Other manufacturers are free to make XInput devices of there own (and many already do in the form of 3rd party 360 controllers) and its the biggest god-send to PC input since the industry adoption of the computer mouse.
Besides all that, I've never met a PC gamepad that I liked better than the 360 gamepads.
Sorry to break it to you, but you're dead wrong buddy.
The RSX does have Vertex Processing Units, 8 to be specific, which are the primary Sources for geometry calculations. Its true that the Cell *can* do these calculations, and can actually do them quite well, but it can not do even half of what the RSX is capable of, even discounting all the other tasks the Cell would typically be handling.
It's again true that the Cell *can* do Pixel calculations, and again it actually does the calculations quite well, however the memory read bandwidth from GPU ram into the Cell CPU is excruciatingly slow, at under 20 MB/s. There's a VRAM to SPU DMA transfer mode thats much faster, however if you tried that you would end up with coherency problems between the GPU's buffers (color, depth, stencil, etc.) because the Cell memory would not recieve updated info from the GPU when it goes on drawing more stuff.
Bottom line: To call the Cell/RSX combo a "hybrid design" capable of "load balancing" is either wishful thinking or gross misunderstanding. Graphically, the Cell can only be usefull to Suppliment Vertex calculations, but its far outstripped by the GPU's capability (and besides that, few if any games have been geometry-limited since the GeForce4.) What it's actually quite useful for is do as much graphical pre-calculation (various forms of culling) as possible so that the GPU can focus as much as possible on stuff that will end up in the final scene.
To the grandparent poster -
The Xenon CPU is actually nothing like the ATI X1900 series. Its a completely different architecture that was originally designed as the successor the 9800 series (which itself has evolved into the X900 and X1900 series due to its success.) ATI's (AMD's now, I suppose) next chip, R600, is based on the same design from which the Xenon GPU is derived, but lacks the embedded framebuffer memory from what I've heard.
Somewhat ironically, while both designs perform well, its the ATI Xenon chip that is actually "next gen" from an architectural standpoint (dispite the fact that the 360 has been in production a full year,) while the RSX is, relatively speaking, old-hat -- having a design that has been available on the desktop for more than a year (and which itself is basically and evolution of the 6800 series, making it even more old-hat.)
In many ways, the 7900/RSX (as well as the X1900) architectures represent the pinacle of modern-day graphics, while the Xenon/R600 (as well as the 8800) architectures represent the first steps towards the future of graphic card technology.
Slashdot Mirror
Nope, The 360 definately uses an emulator. Each game has an "emulation profile" that enables/tweaks the standard emulator to be able to play that game. Think of it as a sort of patch for the emulator thats specific to the game. These are the files that came on your 360 hard drive, that you download automatically the first time you put a supported game into your 360, or that you install from the downloadable CD ISO they make available for each back-compat update.
This is actually one area in which Nintendo lags behind. Each Virtual Console re-release is a Wii executable containing the system emulator and the ROM in one package. If you've got 3 downloaded NES games, you've got 3 NES emulators. This is really silly when you think about it, These older systems have been emulated stably for many years with a single executable, and for some NES/TG16 ROMS, the emulator alone is several times larger than the ROM itself.
How about you bring ScummVM to the Virtual Console line-up? I know its not really a console, but there's no denying that there's a *ton* of popular games just waiting to be revisited, and you've got the perfect input device to do so.
I drive a '96 cavalier; Its not stylish, its not particulalry fast, no power windows or locks and due to some dings, its not even orthogonal anymore. But it was cheap, relatively fuel-efficient, reliable and it gets me from A to B as fast as I'm otherwise allowed. We geeks tend to pine over these sleek ISAs like MIPS or Power in much the same way that car enthusiasts wax romantic about the latest sports car. For most of us however, practicality forces us to drive more modest vehicles. Its not practical to drive a vehicle that requires some exotic fuel in the same way that its not practical to run a CPU that digests some exotic instruction set, and for the same reasons: Limited use and availability leads to higher cost-of-ownership overall. Economies of scale and past investment lead to comparatively rock-bottom prices. The PC is also bogged by something far more sinister than the x86 instruction set, namely, the PC BIOS. This is only just beginning to go away with Apple having adopted Intel's EFI firmware (OpenBIOS on their PPC systems before that) and the growing list of LinuxBIOS supported motherboards (still not ready for personal use, but getting there). Widespread EFI adoption might take place if Microsoft releases a home OS with the capability of using EFI without the BIOS compatability layer. Another point to watch for in the future is the proliferation of platforms such as the CLR (.NET) and to a lesser extent, the JVM. These sort of platforms serve as an abstraction layer between the instruction set the software is written in, and the instruction set of the hardware on which it runs. With a performance difference of 10% or so now, and that difference shrinking as the technology matures, we'll begin to see that the underlying architecture will loose its hold on being the defining element of the platform. We're already beginning to see x86 technolgy moving towards extensions to make virtualization (such as Xen) more efficient, and I suspect it will not be long before it moves to include features to make the .net platform and similar technologies run more efficently as well. If these sort of technologies eventually become the defacto target for software, we may see a future in which the CPU's sole purpose becomes to efficiently support a higher-level platform that is defined by software.
In the Embedded world, x86 does not reign - in fact, x86 is a very small portion of the embedded market. PowerPC rules, followed by ARM and 68k, this doesn't even mention smaller processing tasks run by Microcontrollers like the 8051 or PIC devices. x86 has all but been ousted where engineers are freed from the concerns of backwards compatibility and high performance is not required.
Nights is the one game I'm gauranteed to play when I pull out my Saturn for some retro gaming (Before anyone challenges my geek points over my definition of "retro" please note that the SNES and NES are perminantly connected to the television.) It's a crying shame that a Nights sequel didn't help launch the dreamcast, let alone that it never appeared on it period -- it was rumored to be in production at the time of the DC's demise. I'm glad to see a remake on the way, and I think the Wii will serve it well from a control standpoint; That said, for a game that was so beautiful on the underpowered Saturn, I wonder how gorgeous it could have been on the 360. The only thing that sucked about Nights was the draw distance.
Honestly, its not so much that these games were hard back in the day (I recall seeing TMNT beaten many, many times) as it is that most games today are so joke easy that we've lost perspective on what "hard" really is. Add to that the fact that the skillset for most 3D games is vastly different than that of the 2D variety, and its no wonder we bitch and moan about "how hard these old games were."
I've played games recently, for nostalgia, that I remember being no problem for my 3rd-grade self, yet today, at 23 years old and ~15 years more experience in gaming, these same games kick my ass. Perfection and skill are no longer a requirement of today's games and rarely even rewarded with anything more than a higher score. Games today are designed to allow even mediocre players through, the publishers and the marketting folks require it. Games that are "too difficult" are often panned in reviews. This is mostly a function of the mainstreaming of the games industry that began with the Playstation, and of the aging of the original gamer demographic who are now reaching their 20s-30s (and in some cases 40s) who are finding less and less time to master their new games.
If they're artificially choking supply at ~6million units sold worldwide already, I'd hate to hear those numbers if they weren't.
It may be too late for the DS to gain all these things in an official way (Though a special cartridge would be a possibility) but at the very least I hope Nintendo can keep these in mind for their next portable.
While D3D 10 won't be making its way to XP, I don't believe they've ruled out the possibility of an update to D3D 9 adding the new features. Generally, such big features would be a new version number, but numbering schemes don't have to make sense when the marketting folks get involved. D3D 10 and how it works has much more to do with what functionality takes place where (hardware, kernal drivers, or userspace drivers) than what features are exposed. Its simply not possible to take the D3D 10 API and impliment it on the XP driver model without signifigant performance penalties -- If you push all the (Vista) userspace driver functions into a (XP) kernal driver, the overhead of switching from user-space to kernal-space so frequently will kill performance.
Much of the benefit of D3D 10 stems from the new driver model: fast context switching, minimization of the small batch problem, etc. Mind you, D3D 9 would require some signifigant updates to utilize the geometry shader (particularly because it sits between the current vertex and pixel shader stages. It can't just be tacked onto either end.) but there's nothing, technically, which would proclude the GS stage to be exposed.
If we don't see the new hardware features exposed in a D3D 9 update, it'll simply be because Microsoft didn't see any benefit in performing the extra work it would require of them.
As for spurring OpenGL on XP, I think it will. However, until the ARB (now Khronos) adopt an official extension, developers will have to provide seperate paths for each vendor's specific geometry shader extensions - Presuming AMD/ATI expose it in their GL drivers for their next gen cards.
Honeslty, I've been waiting for an HDMI 360 with built-in HD-DVD drive. The latter doesn't seem to be the case though; but I'd buy a second 360, the elite, if it had and keep the "old" model in my room next to the PC to test my XNA projects. I'd love to have the HD-DVD functionality in my living room, but the add-on drive, like all add-ons, is clunky and ugly.
Without built-in HD-DVD its worthless to me.
For about a hundred bucks I can pick up a 120gig drive and a copy of Norton Ghost, clone my data over to the new drive and slap it into the 360 (yes, this actually works.) For a few bucks more I can pick up any color of RIT vinyl/plastics dye in any color I want - just waiting on my warranty to expire before I crack it open to dye it, and While I'm at it I can swap out the LEDs for some nice blue ones.
While pirating games on the PC is much more attainable than on the console (no modding required,) there is more to it than simple piracy.
Probably the largest factor is that, today, console games are where the sales are at. A "hit" game on the PC might sell 250k copies, where on the console it would be at least a million. Of course, there are examples like WOW, that have become massive enterprises unto themselves, but for the run-of-the-mill AAA PC title those kinds of numbers are only a dream. The PC simply does not touch the consoles in terms of sales potential. Sure there are more PCs in the world, but how many of those are used primarily for gaming, or even gaming at all (excluding casual games, which we're not talking about.)
As budgets for triple-A titles grow larger, you can only respond in so many ways without raising prices on the game itself: Opt to keep the budget small (lower development costs), increase your potential consumer base (more platforms), or charge for "extras" (expansions, subscriptions, micro-transactions.)
In the end it's all business and a simple investment-benefit calculation: They believe that targeting consoles will bring in more money than what the additional work will cost them. As game budgets continue to grow, while simultaneously tipping more and more towards the cost of developing the artistic assets and the code behind the game makes up less and less, it only makes sense to hit as many targets as possible if the art assets can be shared with minimal or no tweaking, even to the point that it will make sense even if little of the code is shared between platforms -- which we'll see more and more of with the architectural differences between the 360, PS3, Wii and PC.
I live in Washington state and also had a non-compete agreement for my job as a software developer. However, the terms in my contract were much narrower. Working for what was essentially a software-for-hire, services-based company, my contract stated that for the period of 6 months after my employment I could not perform a competing service for any clients of my previous employer.
Essentially I could work for a competing company so long as I didn't work for any of my previous company's clients, and I could work for those clients as long as I was working on a different problem. I think that was very fair.
Your clause saounds much more draconian than that. It sounds more like it's meant to punish you for leaving, rather than to protect your employer's client and IP assets.
Maybe you could get them to accept similar terms to mine in leu of their "standard" clause, and maybe get them to adopt it instead?
- A lot of children have relatively unmonitored access to the Wii, perhaps in their own bedroom or play room.
- A lot of parents *don't* know about the Wii's internet capabilities. Many of those that *are* aware, assume that the content is somehow filtered.
- A lot of parents *don't* know about the Wii's child protection features, account controls, etc. - I'm not sure what's required to download the browser, but if no credit card is required and no admin-like privileges are required or set up, then its possible for them to download the browser themselves.
While the tone of the press release is too strong as I said above, I think we can all see that, yes, the Wii can be used to access porn, chat rooms, etc that may be innapropriate for young people. I think we can all agree that, yes, all parents should be aware of this reality and take steps they deem appropriate, but many are simply not aware at this point.This isn't another "Video games are the devil!" argument, no one's calling for a boycott of the Wii, or for Nintendo to be held responsible for the content some children might access... beyond the slightly sensational tone all I see is information that is usefull and pertinent for parents.
No one here would turn their kid loose on the web without proper protection/monitoring in place, or at the very least recognize the risk in doing so. We forum-goers are always calling for parental and personal responsibility, for good reason, and I don't see this press release as doing much else.
Sony has done absolutely *nothing* right this generation. They're too late, with technology to match their intended launch date of last year. They threw in a GPU too late to the game because they thought their wonderfull cell processor would make a powerfull enough GPU. The cell is nice in theory, but there's too many restrictions and memory-wrangling in practice. They're up against the 360, with a 10+ million installed base, second-gen games, and a lower price point - Oh and Halo 3 is due out this holiday season or there about. They're up against the Wii at less than half the price, and cheaper games they can't match on innovation. The launch catalog was anemic with no real stand-outs, and there's nothing big on the radar except MGS4. They're losing exclusive third-party titles left and right to the 360.
Devs are comfortable on their competitors' machines - The Wii is just a faster gamecube (literally) with a neat controller, and while the 360 is relatively complex they've got wonderful top-notch tools to support development and an architecture thats doesn't have a split memory model or hobbled assymetric CPU.
Despite the high price, they're loosing about $175 - $225 per unit (depending on the model) while their competotors' machines are already profitable hardware. Nintendo has never sold an unprofitable machine, and right now, Microsoft could give consumers a $50 price drop and take each new owner out to lunch before they would go back into the red.
Mark my words -- If the earth doesn't shake for Sony real soon they'll be a distant third this time around, and may be foreced to drop from the race early or even for good, and if Sony's game division fails its going to make a huge hit on the entire company's bottom line.
They're arrogant over an overpriced architecture that hurts more than it helps, all in the name of pushing their BluRay format.
Don't plasma tubes fail after some 3-5 years? Not only do they cost 2-3 grand to begin with, but when the tube goes there's no practical point in replacing it since it costs nearly as much as a new plasma screen to do so.
But maybe I've heard wrong, anyone know?
I just got a 46" samsung DLP a couple months ago and I couldn't be happier with it.
There are a few things that are possible besides simply rescaling the final output. One thing they can possibly do is trap the call to set the Matrix for output to a standard def screen and instead set it for a high-def resolution. Some PC emulators which map the 3D emulation onto OpenGL/D3D do this. The textures themselves are not more detailed (unless they applied techniques to solve this as well) but because each polygon would cover more pixels, the texture sampling is more fine-grained, resulting in somewhat clearer visuals. Though, this technique may not apply to PS2 games since the original graphics chip is included. The PS3 isn't so much an emulator in the traditional sense, it just includes the important bits of PS2 hardware. The software portion of the "emulator" basically maps the PS3 IO hardware onto an interface that the PS2-on-a-chip uses, and appearantly, also does some post-processing/scaling of the framebuffer.
Old 3D games do look pretty crappy on new TVs, particularly the N64 which had a bug in its silicon that resulted in overly blurry visuals (it was supposed to be a form of anti-aliasing.) Sprite games still look great however, particularly the colorful ones. Super Mario World (from a SNES over S-Video, not emu or wii ware) on my 48" DLP looks amazing.
Microsoft is actually doing all these things and a little more to boot.
As a game developer, DX10 really is moving in the right direction.
In D3D10 for instance, much work has gone into solving the "small batch" problem - a condition caused by the fact that state-changes (binding different textures, shaders, etc) are so expensive on today's 3D accelerators that processing many small batches can severly impact performace. Developers end up jumping through a lot of hoops in an attempt to optimally batch their triangles. This and other improvements to D3D10 have cut overhead by approximately one-half. They've also removed the capability-bits mechanism in favor of the more-defined feature compliance you mentioned. Cap bits were terrible because they only told you if a feature was supported, nothing about performance - Intel's Integrated graphics only support software vertex shaders (in the driver) for instance. Other accelerators make similar claims, or outright don't support a feature their caps bits claim to.
Microsoft is also pushing the play-from disc technology as well, though its slow to be embraced. For some reason, game devs are reluctant to do things differently than the way they've always done things, even if it is better - See all the bitching about migrating to the LUA profile model in Vista. The groundwork to do this is there now, its simply a matter of developers starting to make use of it.
PC joypads are also starting to come together now that Microsoft is pushing XInput over DirectInput. XInput not only provides a clean API to xbox-style gamepads, but also defines certain layout constraints. Things like the primary axis being the left thumb-stick, or button 1 is the 6'oclock face button. You'd be amazed at the amount of difference in non-XInput PC gamepads have in this area, "button 1" might be the 6'oclock face button on one pad, or the left trigger on another. This amount of variance is the primary reason that gamepad support is almost non-existant on most PC games, realisticly you'd have had to impliment a completely configurable control scheme, or not bother with it at all. Given the lack of a standard layout and the fact that it had to support every input device under the sun (gamepads, throttles, flicktsicks, peddals, etc) DirectInput became a unnecesarily large and comlex API. XInput pretty much solves everything from a developer standpoint, and its nice be able to take your Xbox 360 controllers to your PC when you need a gamepad; One (or more) fewer controllers to own and keep charged up.
The final big thing MS is doing to make the PC a more console-like experience is to bring XBox Live to the PC. Hopefully this will bring the days of everyone having different, half-finished or buggy multi-player lobbies to an end. A lot of companies have developed solid and featureful in-house implimentations over the years, aleviating the second two problems, but having a more unified experience is quite nice and will allow games companies to spend less time developing and maintaining their proprietary lobby systems. On top of that, there's now the possibility of playing PC vs Xbox 360.
In short, Microsoft is doing a lot to make the PC a more console-like experience, both from the developer's side and the user's side, but I still disagree with the grandparent that the PC will ever subsume the role of the console. People use consoles because they are stupidly easy to use. There's no worry about minimum specs or the quality of system components having a negative impact on performance. There's no worry about spyware or trojans. There's no worry that the input device you just picked up won't work well. Some of these problems are simply not solvable on the PC without pandering the a least-common denominator.
Linux and other FOSS Operating Systems will be able to ride the wave this will bring as well. Khronos is already working on OpenGL 3 specs which will streamline the API and bring it inline with D3D10 features, much in the same way that D3D10 is a streamled evolu
Its bad enough to post dupes, but this one is terrible. Its basically twice-chewed information, an article about an article about an interview. Not only that, but this article seems to carefully choose which parts of the original article to leave out, presenting a biased, if not untruthful, view of the original information. Then they go one further, in traditional slashdot fashion, and give it some alarmist title to grab attention.
At least the title doesn't twist the article, but the context is more that he's happy as-is with XP, believes that they could back-port DX10 to XP, and that Vista isn't yet widely distributed enough to make business-sense to migrate development to it exclusively. DX10 isn't worth porting to for a game thats based on the Doom 3 engine and has probably been in development for 1-2 years? Big suprise there.
Dispite some bad dealings with Nintendo in the past, he's actually interested in doing some DS/Wii stuff, acording to the original article.
My understanding is that slashdot has editors, perhaps they should make some editorial decisions on what (not) to post.
As an independant games developer, I'm honestly not all that concerned. Here are a few reasons why:
1) Most people probably won't even turn the protection system on.
2) You can make specified games exempt, or enable them per user.
3) If it becomes that big of an issue, the system is able to support other ratings boards. An Indie-focused organization could be set up to rate games using volunteers and accept donations from indie devs and individuals.
Yes, its a minor hassle. So is the migration to the LUA model. I think we can all agree that both moves are good.
Do we really want a company now owned, unfortunately, by MTV in charge of a game about music?
I'd hate to see our precious Guitar Hero slowly transformed from "All Music, All the Time" into a reality-TV-like Sims starring drunk and likely bi-polar college age kids with little or no personality.
Its best this game stay as far away from MTV as possible.
Actually, You've got it wrong. The PPC core in the PS3 is the exact same as the 3 in the Xbox 360. With the exception of different interconnects to the rest of the stuff in the CPU and the rest of the system, the feature set is identical, even including the extended VMX128 instruction set which removes some standard VMX instructions while adding 96 registers (128 total) and some new instructions (such as a dot product.) Both cores feature dual-threaded in-order exectution, a feature derived from an earlier IBM prototype designed to make a highly cost-effective, but performant, PPC CPU. The Cache system on the 360 does allow portions of the cache to be locked down, or bypassed, but thats a feature of the cache rather than the CPU core itself.
You're wrong again on the Wii CPU, which is not at all related to the Cell/360 PPC cores or their common ancestor. The Wii CPU impliments the same exact instruction set as the CPU in the Gamecube, albeit die-shrunk thanks to a smaller process and that its clocked 1.5x faster in Wii mode. Aside from the process-shrink, IBM applied more modern materials and gating techniques to reduce power consumption and there may be some differences in the actual silicon implimentation of the various instructions (though implimenting the same function.)
The Wii and Gamecube CPUs are derived from a G3-class PPC processor, which Nintendo contracted IBM to extend to their specifications. One change is that the 64bit FPU was extended to include instructions which operate on pairs of 32bit floats, SIMD style (which I believe are mapped to normal VMX instructions, though I'm not sure) which was cheaper than implimenting a stand-alone VMX unit (which would have been a full 128 bits wide and doubled the die-size.)
As a side-note -- We can probably look forward to an even smaller and cheaper gamecube next year that will utilize reject Wii parts: Processors which don't quite make the Wii speed-grade along with the Wii's combined GPU/SRAM chip which contains a faster (again, 1.5x) GPU and the gamecube's 24MB of 1-T SRAM. The new revision will probably be half-height and passively cooled. It might even fit in a large pants pocket.
While I believe your comments to be a little extreme (and I'd probably accuse you of tin-foil-hat-ery if I wasn't so sure I'd only be the last in a very long line :) ) I just thought I'd drop some relevent information.
For a burgioning DirecX competitor, check out The Khronos Group's OpenKode specification. Basically, it's a suite of Multimedia APIs including Graphics, Sound and Multimedia technologies based on open APIs such as OpenGL, OpenGL|ES, OpenVG, OpenSL, OpenML, and Collada. It also defines some level of abstraction for hardware and OS interaction: input and display surfaces for instance. Khronos and OpenKode (or portions thereof) are backed by several industry heavyweights including Nvidia, ATI/AMD, Intel, Sony, Creative Labs and others.
Sony has already adopted a version of OpenGL|ES and collada for the PS3, and likely the best way to foster a cross platform DirectX is to urge Sony, Nintendo, Apple, PC hardware vendors, and even [Gasp!] Microsoft to participate in its development by joining with Khronos to further define the APIs and by adopting, or at least supporting, them in their products.
Live on the PC is not a clone of XBox Live in the strict sense. For example, the article clearly demonstrates that they don't expect that gamers will suddenly pony up $50 bucks a year to simply play PC games online and that they intend to provide other value to make the subscription service more attractive (but ultimately optional it would appear.) As far as Mods (in the sense of Counter Strike) I see no reason why they would be effected since they run on top of their base game. As for Mods in the sense of cheats, anything that limits their use and can be used to identify, and potentially ban, problem players is a good thing, IMHO.
An important bit of information that's not widely known yet, is that Microsoft is opening up Live to Developers so that they can run their own game servers connected to the Live network. There's a paper they published awhile back that I've read (I believe it was a GameFest paper) that specifies the requirements as set forth by Microsoft (one requirement is that there is a seperate, security proxy between the game server and Microsoft's central Live servers) and how to go about implimenting Live in your title. The gist is that the game goes through live to find the server, There's some securities checking, player profile stuff, and then the game is connected to the Company's own server. For a company running their own server, I don't see any reason why it couldn't support Cross-platform (Linux, Mac, etc.) play, though other platforms would have to connect through the normal means.
And of course, the Graphics API has nothing to do with network play.
Quick! Somebody call Jack Thompson!
In addition to Osty's very good points, I'll give you another one: Standardization.
The largest headache with DirectInput was that it supported every device under the sun and there was absolutely no standard as to which Buttons/D-pads/Sticks/Triggers on the physical device mapped to which logical button/axis. Which is to say that "button 1" might very well be the 6 o'clock face button on one device, and it might be the secondary left shoulder button on another. Even ignoring that, the sheer breadth of devices was a nightmare. Things ranged from very simple digital D-pad + 4 buttons, to full flight-sim gear with 4+ axis and many tens of buttons. All of this through a single interface. It was overly complex for 99% of everything it was ever used for and for the 1% that benefitted from such a bewildering array of options, was still increadibly obtuse.
Ignoring the API (Which is joke-easy by the way; I implimented an Xinput interface through my own abstract control interface in 30 minutes, never having seen a single line of XInput code before.) what XInput does is provide a standard for the controler's physical layout. In XInput, "Button 1" is always the six o'clock face button, and the primary X/Y axis is always mapped to the left thumbstick for example. Other manufacturers are free to make XInput devices of there own (and many already do in the form of 3rd party 360 controllers) and its the biggest god-send to PC input since the industry adoption of the computer mouse.
Besides all that, I've never met a PC gamepad that I liked better than the 360 gamepads.
Sorry to break it to you, but you're dead wrong buddy.
The RSX does have Vertex Processing Units, 8 to be specific, which are the primary Sources for geometry calculations. Its true that the Cell *can* do these calculations, and can actually do them quite well, but it can not do even half of what the RSX is capable of, even discounting all the other tasks the Cell would typically be handling.
It's again true that the Cell *can* do Pixel calculations, and again it actually does the calculations quite well, however the memory read bandwidth from GPU ram into the Cell CPU is excruciatingly slow, at under 20 MB/s. There's a VRAM to SPU DMA transfer mode thats much faster, however if you tried that you would end up with coherency problems between the GPU's buffers (color, depth, stencil, etc.) because the Cell memory would not recieve updated info from the GPU when it goes on drawing more stuff.
Bottom line: To call the Cell/RSX combo a "hybrid design" capable of "load balancing" is either wishful thinking or gross misunderstanding. Graphically, the Cell can only be usefull to Suppliment Vertex calculations, but its far outstripped by the GPU's capability (and besides that, few if any games have been geometry-limited since the GeForce4.) What it's actually quite useful for is do as much graphical pre-calculation (various forms of culling) as possible so that the GPU can focus as much as possible on stuff that will end up in the final scene.
To the grandparent poster -
The Xenon CPU is actually nothing like the ATI X1900 series. Its a completely different architecture that was originally designed as the successor the 9800 series (which itself has evolved into the X900 and X1900 series due to its success.) ATI's (AMD's now, I suppose) next chip, R600, is based on the same design from which the Xenon GPU is derived, but lacks the embedded framebuffer memory from what I've heard.
Somewhat ironically, while both designs perform well, its the ATI Xenon chip that is actually "next gen" from an architectural standpoint (dispite the fact that the 360 has been in production a full year,) while the RSX is, relatively speaking, old-hat -- having a design that has been available on the desktop for more than a year (and which itself is basically and evolution of the 6800 series, making it even more old-hat.)
In many ways, the 7900/RSX (as well as the X1900) architectures represent the pinacle of modern-day graphics, while the Xenon/R600 (as well as the 8800) architectures represent the first steps towards the future of graphic card technology.