I have the backwards compatible version with hardware GS and software EE and it's fully up to date with patches and the PS2 compatibility works fine. Just played through Ico and Shadow Of The Colossus (which is perhaps the most demanding PS2 game ever made) last weekend.
NASA records video from the Solid Rocket Boosters on Space Shuttle launches. 6 minutes or so from the pad up to around 200,000ft and then all the way down to the sea. You can see the orbiter fly away, the other SRB as they both tumble, and the sun in the blackness of space although it's often too bright for the camera to cope with.
I ditched TV reception years ago and have never looked back. $600+/yr is a bunch of DVD boxsets and there's no additional DVR costs in order to be watching them on my feast/famine viewing schedule instead of the once per week dripfeed.
I am serious. I make games for a living and the most useful tool overall is written communication with the rest of the team. Nobody can remember how every nuance of a game should work so being able to go to the internal wiki or wherever and re-read the explanation is hugely important.
Also, make games. Lots and lots of games. Board games, card games, dice games, any kind of simple game. Look at other games - start with very simple games - and think about them critically. Examine each part of the game and try to figure out why it is that way. If you can't deconstruct games like this you've no business being a game designer.
Frankly the whole Gerstmann conspiracy is overblown. Whether Eidos complained about him or not, only they and he could comment, but Cnet were slowly in the process of changing the editorial tone of that site. I know that we never had any 'pull' over reviews for any game that I worked on at Midway, whether with Gamespot or IGN or anyone else and whether we were running ad campaigns or not. I'm pretty sure other teams did not either, however much they may have wanted. Certain development people knew reviewers pretty well informally but there was enough professionalism between them that it didn't affect the score or the delivery.
Reviews have very little correlation with sales anyway. There are lots of highly-reviewed games (ie. average over 90%) with under 200,000 sold through (which makes them a serious financial failure) and lots with scores under 75% but over a million sold through.
This is basically what happened to me with PC games. I got tired of paying for the privilege of wrestling with buggy, poorly performing games with quixotic driver needs and which installed DRM that messed with my system. I make games for a living, I know it's not easy, but that doesn't mean I'm going to forgive you when I fork over my money and you respond with an exercise in frustration. With a console I can put the disc in and play.
I hear you on the boardgaming thing though. We've been playing Arkham Horror once a week, that's a pretty great game. I need to buy Caylus so we can play that down here (used to play that with my Chicago friends).
The BBC micro had a number of variants of this, mostly to stop people converting the tape versions of game to run from floppy disc.
For the most part they were trivial, but the best one used the 1MHz timer. The decryptor code was positioned immediately below the encrypted game code and ran in a (nested) loop. It XORed itself (including addresses it used for indirect loads and so on), the timer and to-be-decrypted data along with a few constants. When things magically came right the loop terminated and the very next thing in memory was the first instruction of the now-decrypted game code.
Because the 6502 CPU only ran at 2MHz you had to figure out where in the (usually 2-6 cycles) fetch-execute cycle the, say, LDA instruction would read the hardware timer if you wanted to hand decode this. And of course the length of that instruction varied based on whether it was crossing a 256 byte page boundary or not (doing an indirect load) and so on. You couldn't move the target data because that would change the addresses being used for loads and stores and thus the progress of the decryption, you couldn't copy the code elsewhere and change it to update both copies because that would change the length of the loop and throw the timings off and you couldn't mess with the timer speed because it was fixed in hardware and, well, you get the idea.
I can totally tell it's at a lower resolution than other games. I think they're also not using the antialiasing in the same way as most games, or something else is amiss, because I can definitely see the hard edges of walls and doors and so on. Mind you I have a 1080p Full-HD television.
It's not like it's a big deal, they made their choice so they could run at framerate and get the lighting they wanted, but at least some of us could tell immediately. By the way, the reason they do this reduced framebuffer size (and it has to be horizontal as well as vertical) is so the whole thing fits in the GPU's embedded memory and they don't need to resolve to main memory during the rendering process.
Rubbish. Hironogu Sakaguchi and Nasir Gebelli came up with the name because Square was almost bankrupt and so the game would be the company's final game unless it was a hit.
You are right that it's actually 1440KB but you're totally wrong about everything else. 720KB floppies were double sided and "double density". That means 80 tracks, 18 sectors per track, 256 bytes per sector - with the 2 sides you get 720KB. "high density" or "quad density" floppies were 36 sectors per track, doubling them up to 1440KB. This is equivalent to 1.40625MB.
It's completely believable. When I worked on Blitz 20-02 and we were in crunch time, nearly done (there were about 35 people working on the game all told at that point), I was getting a minimum of 50 emails every day. I was probably sending 5-10 a day. There were more than a few days where I received over 100 emails in a single day. These were all work-related, people asking bug fix questions, people saying the build was broken, people asking what I wanted for dinner, people saying dinner had been delivered and so on.
So someone like Karl Rove who I imagine gets kept in the loop on basically everything and probably has multiple people to read his email for him, 80 emails a day actually seems low.
DS and PSP are not what I would consider OpenGL-like. Wii, yes. PS3, it's one alternative, but the other, higher-performance API, not so much. The most time-consuming issues of porting are not with the rendering API anyway.
I should've previewed. The developer is supposed to be saying "I can't do [high-level game feature] after all." and the publisher, well [other game] does...". My forgetfulness of angle brackets was not sufficiently mitigated by office doughnuts.
You mean VU0 (which is accessible using coprocessor instructions of the EE), not VU1 (which feeds directly into the GIF via PATH1). And I've never heard of anyone doing that, nor of publishers even caring. Publishers care about things they can put on the back of the box. VU0 utilisation is not such a thing. The only way I could see it coming up is if a developer says "I can't do after all." and then publisher says, "Well does, are they using the system better than you?"
For all that, not many people use VU0 that much. Some people do particles on it, some people do part of their character animation on it and some people do some of their skinning on it. Most people have optimised math routines to use it via the coprocessor instructions, but that's not exactly a heavy amount. I've written about a dozen lines of VU0 assembly in my career.
I worked on spinning reel slots for WMS Gaming. To my knowledge all jurisdictions have laws regarding the relative frequency of physical reel positions (in Nevada it's 6:1 for adjacent positions and the labs got antsy if you went beyond 4:1) and as a consequence of these laws all physical reel positions must be hittable.
24 stop reels are very rare (never seen them in the real world in fact) because it makes the 12 symbols have to be pretty narrow. 22 stop is the standard although 18 stop was used from time to time. Virtual reels were commonly 72 stop. 32 stop doesn't extend the odds enough to be very useful and it also doesn't give you enough granularity between positions. You can go higher than 72 of course. I saw a math model for an IGT Five Times Pay that used a 90 stop virtual reel and one for a Triple Triple Diamond that used a 200 stop virtual reel. Those were 92% payout games if I remember rightly. I was told Quartermania used 255 stop virtual reels but I never personally saw math for it.
As a general point for people I'd like to say that there are indeed several techniques the machines use that are not commonly known, but all slot machine behaviour is VERY heavily regulated by law. If you want to know what they can and cannot do, look at the statutes. Ironically basically all the things people think the machines do are illegal and therefore not done.
That internal 3MB is only used for the back-buffer, Z-buffer and textures required for the currently-rendering polygon (ie. often 1 and at most 8). Textures are DMAed from main memory into the internal memory as needed. The system architecture was designed with this in mind so performance is sufficient.
The relative cost of a PS3/Xbox360 game vs a Wii game will depend on many things and the programming model is somewhere down the list. It'll matter to some extent because hardware multiprocessing is more a difficult technology, but compared to the greater quality and quantity of art assets necessary to be competitive (when you have to model, texture and bump map every banana and apple in a bowl of fruit you're burning up artist time) and the greater fidelity of overall simulation (eg. physics-based animation, sophisticated lighting and shadowing) I think it's not a big deal.
Part of the cost will be defrayed by increased use of middleware, especially for physics, animation and rendering, which will be internally parallelised and designed to run on say 2 hardware threads or 3 SPEs and leave the rest of the system resources available for something else.
Wii titles will be distinctly cheaper to make. They won't go toe to toe with Xbox360/PS3 on graphics or depth of simulation but they have other ways to make their mark of course and the lower cost means it'll be easier for publishers to greenlight more experimental titles (assuming the install bases are comparable) because the business risk will be lower.
I've not delved deeply into the early Xbox360 games (I was too busy with my own Xbox/PS2 game) but I would not expect them to have made much use of the multiple CPU cores, not would I expect early PS3 games to be getting much parallel use out of the SPEs. There'll be some advantage taken but there will be significant room for improvement. This is generally a good thing because - as long as the early games are good enough and gamers are impressed by them and have fun playing them (both are important) - it means there is scope to grow and provide new experiences as developers gain experience and confidence with the hardware.
Ohh, the WiiConnect24 stuff is a good question - I have no idea how they'll handle that while playing Gamecube games. Maybe they'll just act as if the console is not connected to the network and cache messages at the server. Interesting point though.
The locked cache existed in the Gamecube, but the bigger point about allowing general improvements to be turned on via a register is a good one that I hadn't thought of. I should've remembered it because I used exactly that feature during Pin2000! MediaGX's built-in video hardware either did VGA emulation via CPU exception (which we did not need) or you could program it yourself at the register level to do hardware blitting (it locked 1K of the 4K level 1 cache as its blit buffer, in another amusing synergy to this discussion). Thanks for pointing that out - it may be that they've done that for some broader features.
The PS2 has pretty much an entire PSone on a chip. It's called the IOP. When it's not doing PSone emulation it's running the I/O subsystem. Even then some games don't work correctly. As they've cost-reduced the PS2 and changed that area of the hardware the list of games that don't work has grown (it includes Tekken 5 on the most recent consumer hardware rev, even). I don't know how PS3 is doing it but Xbox360 uses software emulation and look at the mess of that (because yes cycle emulation is incredibly hard as you rightly say).
I generally consider consoles to be embedded because they do one thing, namely play games, and one piece of software gets complete access to the hardware, down to the metal, while it's fulfilling that role. This perhaps isn't quite a correct use of the term but it feels right to me and console programming is much more akin to the other domains of embedded programming (I used to work for a defense company back in Britain) than PC-style programming. This distinction is becoming blurred on this coming generation of consoles because of the things they do behind your back (network presence and so on).
The highly timing-critical areas of code usually fall into interrupts or low-level parts of rendering where they're moving data from memory through some algorithm on the CPU and then out to the GPU as part of a command packet. Games drop frames when they can't swap video buffers within 1 (or 2 if they run at 30Hz) TV fields because they're trying to do too much overall work. That can be because they couldn't get all their GPU work done (too much geometry processing or drawing) or CPU work (too much setup or general game simulation). It's a much higher-level issue than individual packet flow at the bottom of the pipeline where the time a cache line prefetch takes or a dependent single-precision FP multiple takes may cause you to write something to memory before the GPU has finished reading it (for example).
I fully expect that the rest of the Wii hardware has been clocked up by the same amount to make all this stuff work.
I am well aware that ISA-level compatibility is enough for application level code, where timing and other performance dependencies are weak to nonexistent. This is not the case in embedded systems especially once you start communicating with other devices on the system bus (eg. a GPU via a scatter-gather pipe). Single cycle differences or similar can and do break code in non-trivial ways. I have seen this between revisions of development hardware.
Backwards compatibility means no changes
on
The Wii's Brain Exposed
·
· Score: 2, Insightful
Changing the microarchitecture would have implications for backwards compatibility with Gamecube software. My personal opinion (as someone who has programmed for Gamecube in the past and is working on a next-gen game) is that they will have made no changes. The new part is just a die-shrunk up-clocked Gekko and there's nothing wrong with that.
To back your more general point up, although people seem to have a low opinion of what the Gamecube hardware was capable of it's unwarranted. It's true that many games didn't get much out of it, but look at Starfox Adventures (from 2002 no less) to see what you could achieve. 480p and 16:9, fur shading, bump mapping, refraction and reflection for water (and ice), realtime environment lighting for the day/night cycle and lots of particles. It's a very pretty game indeed.
Even if no new capabilities are added to the hardware, Wii games will look great and the demos I played at E3 were pretty damn fun for the most part.
Full disclosure: I've been platform lead on PS2 and Xbox games and am now working on a next-gen title. You'd be surprised actually at what can be done to uprez art at a much lesser cost than redoing it from scratch. It doesn't come out looking as good as art (and a rendering pipeline) designed from scratch for next-gen but it would've been good enough for a launch title. Assets are often made at better quality than a console can handle and automatically downsampled as part of the art build (lower res and bit depth/compression) or just used as reference to make the low-poly versions or for cutscene/marketing renders (character models). The hardware itself can help somewhat when you enable anisotropic filtering, better antialiasing and a better lighting model. Redoing character heads with more polys helps enormously and doesn't take that long.
The biggest kicker is that you can outsource 90% of this work (either to dedicated companies in the west, or to eastern Europe or to China) so it can be done cheaply and with much less creative risk than creating new elements from scratch.
Lego Star Wars is certainly more commercially viable but I bet it's not that much cheaper to make. It's a bit smaller and of course it has basically no voice acting but it still has 18 levels, most of which are fairly large. It took me 35 hours to get 100% completion on the game.
The big difference is the accessibility of the gameplay and the polish of it. From things like the humour in the cutscenes (Stormtroopers giving each other noogies when you escape Mos Eisley!) to technical matters like supporting 16:9 and 480p on Gamecube (which really show off the art quality) to the game's stability (no crashes and I only found one logic bug - you can activate the 6-switch platform in the Endor bounty hunter level causing you to fall out of the world). These things combine to make the sales difference and when you're talking about millions of dollars to make and sell a game it's hard to gamble very often.
If the LucasArts biz guys were smart they would've greenlit an Xbox360 version of the game as a lunch title with the art uprezzed a bit, the original stuff finished up, the bugs fixed and some new stuff to do (add a hidden planet with some Jedi-only tasks perhaps, or a flying minigame or two). An extra nine months or so of development with a small team plus outsourcing the art tasks would've been cheap and it would've been a great seller (450k+ easily as a big name license plus being the only RPG).
Slashdot Mirror
I have the backwards compatible version with hardware GS and software EE and it's fully up to date with patches and the PS2 compatibility works fine. Just played through Ico and Shadow Of The Colossus (which is perhaps the most demanding PS2 game ever made) last weekend.
Sewing for damages?
Fear the giant quilt of redress!
NASA records video from the Solid Rocket Boosters on Space Shuttle launches. 6 minutes or so from the pad up to around 200,000ft and then all the way down to the sea. You can see the orbiter fly away, the other SRB as they both tumble, and the sun in the blackness of space although it's often too bright for the camera to cope with.
http://www.youtube.com/watch?v=FadV-VwuXWo
I ditched TV reception years ago and have never looked back. $600+/yr is a bunch of DVD boxsets and there's no additional DVR costs in order to be watching them on my feast/famine viewing schedule instead of the once per week dripfeed.
...is English.
I am serious. I make games for a living and the most useful tool overall is written communication with the rest of the team. Nobody can remember how every nuance of a game should work so being able to go to the internal wiki or wherever and re-read the explanation is hugely important.
Also, make games. Lots and lots of games. Board games, card games, dice games, any kind of simple game. Look at other games - start with very simple games - and think about them critically. Examine each part of the game and try to figure out why it is that way. If you can't deconstruct games like this you've no business being a game designer.
Frankly the whole Gerstmann conspiracy is overblown. Whether Eidos complained about him or not, only they and he could comment, but Cnet were slowly in the process of changing the editorial tone of that site. I know that we never had any 'pull' over reviews for any game that I worked on at Midway, whether with Gamespot or IGN or anyone else and whether we were running ad campaigns or not. I'm pretty sure other teams did not either, however much they may have wanted. Certain development people knew reviewers pretty well informally but there was enough professionalism between them that it didn't affect the score or the delivery.
Reviews have very little correlation with sales anyway. There are lots of highly-reviewed games (ie. average over 90%) with under 200,000 sold through (which makes them a serious financial failure) and lots with scores under 75% but over a million sold through.
This is basically what happened to me with PC games. I got tired of paying for the privilege of wrestling with buggy, poorly performing games with quixotic driver needs and which installed DRM that messed with my system. I make games for a living, I know it's not easy, but that doesn't mean I'm going to forgive you when I fork over my money and you respond with an exercise in frustration. With a console I can put the disc in and play.
I hear you on the boardgaming thing though. We've been playing Arkham Horror once a week, that's a pretty great game. I need to buy Caylus so we can play that down here (used to play that with my Chicago friends).
The BBC micro had a number of variants of this, mostly to stop people converting the tape versions of game to run from floppy disc.
For the most part they were trivial, but the best one used the 1MHz timer. The decryptor code was positioned immediately below the encrypted game code and ran in a (nested) loop. It XORed itself (including addresses it used for indirect loads and so on), the timer and to-be-decrypted data along with a few constants. When things magically came right the loop terminated and the very next thing in memory was the first instruction of the now-decrypted game code.
Because the 6502 CPU only ran at 2MHz you had to figure out where in the (usually 2-6 cycles) fetch-execute cycle the, say, LDA instruction would read the hardware timer if you wanted to hand decode this. And of course the length of that instruction varied based on whether it was crossing a 256 byte page boundary or not (doing an indirect load) and so on. You couldn't move the target data because that would change the addresses being used for loads and stores and thus the progress of the decryption, you couldn't copy the code elsewhere and change it to update both copies because that would change the length of the loop and throw the timings off and you couldn't mess with the timer speed because it was fixed in hardware and, well, you get the idea.
Clever fellow who came up with that one!
I can totally tell it's at a lower resolution than other games. I think they're also not using the antialiasing in the same way as most games, or something else is amiss, because I can definitely see the hard edges of walls and doors and so on. Mind you I have a 1080p Full-HD television.
It's not like it's a big deal, they made their choice so they could run at framerate and get the lighting they wanted, but at least some of us could tell immediately. By the way, the reason they do this reduced framebuffer size (and it has to be horizontal as well as vertical) is so the whole thing fits in the GPU's embedded memory and they don't need to resolve to main memory during the rendering process.
Rubbish. Hironogu Sakaguchi and Nasir Gebelli came up with the name because Square was almost bankrupt and so the game would be the company's final game unless it was a hit.
You are right that it's actually 1440KB but you're totally wrong about everything else. 720KB floppies were double sided and "double density". That means 80 tracks, 18 sectors per track, 256 bytes per sector - with the 2 sides you get 720KB. "high density" or "quad density" floppies were 36 sectors per track, doubling them up to 1440KB. This is equivalent to 1.40625MB.
It's completely believable. When I worked on Blitz 20-02 and we were in crunch time, nearly done (there were about 35 people working on the game all told at that point), I was getting a minimum of 50 emails every day. I was probably sending 5-10 a day. There were more than a few days where I received over 100 emails in a single day. These were all work-related, people asking bug fix questions, people saying the build was broken, people asking what I wanted for dinner, people saying dinner had been delivered and so on.
So someone like Karl Rove who I imagine gets kept in the loop on basically everything and probably has multiple people to read his email for him, 80 emails a day actually seems low.
DS and PSP are not what I would consider OpenGL-like. Wii, yes. PS3, it's one alternative, but the other, higher-performance API, not so much. The most time-consuming issues of porting are not with the rendering API anyway.
I should've previewed. The developer is supposed to be saying "I can't do [high-level game feature] after all." and the publisher, well [other game] does...". My forgetfulness of angle brackets was not sufficiently mitigated by office doughnuts.
You mean VU0 (which is accessible using coprocessor instructions of the EE), not VU1 (which feeds directly into the GIF via PATH1). And I've never heard of anyone doing that, nor of publishers even caring. Publishers care about things they can put on the back of the box. VU0 utilisation is not such a thing. The only way I could see it coming up is if a developer says "I can't do after all." and then publisher says, "Well does, are they using the system better than you?"
For all that, not many people use VU0 that much. Some people do particles on it, some people do part of their character animation on it and some people do some of their skinning on it. Most people have optimised math routines to use it via the coprocessor instructions, but that's not exactly a heavy amount. I've written about a dozen lines of VU0 assembly in my career.
I worked on spinning reel slots for WMS Gaming. To my knowledge all jurisdictions have laws regarding the relative frequency of physical reel positions (in Nevada it's 6:1 for adjacent positions and the labs got antsy if you went beyond 4:1) and as a consequence of these laws all physical reel positions must be hittable.
24 stop reels are very rare (never seen them in the real world in fact) because it makes the 12 symbols have to be pretty narrow. 22 stop is the standard although 18 stop was used from time to time. Virtual reels were commonly 72 stop. 32 stop doesn't extend the odds enough to be very useful and it also doesn't give you enough granularity between positions. You can go higher than 72 of course. I saw a math model for an IGT Five Times Pay that used a 90 stop virtual reel and one for a Triple Triple Diamond that used a 200 stop virtual reel. Those were 92% payout games if I remember rightly. I was told Quartermania used 255 stop virtual reels but I never personally saw math for it.
As a general point for people I'd like to say that there are indeed several techniques the machines use that are not commonly known, but all slot machine behaviour is VERY heavily regulated by law. If you want to know what they can and cannot do, look at the statutes. Ironically basically all the things people think the machines do are illegal and therefore not done.
That internal 3MB is only used for the back-buffer, Z-buffer and textures required for the currently-rendering polygon (ie. often 1 and at most 8). Textures are DMAed from main memory into the internal memory as needed. The system architecture was designed with this in mind so performance is sufficient.
The relative cost of a PS3/Xbox360 game vs a Wii game will depend on many things and the programming model is somewhere down the list. It'll matter to some extent because hardware multiprocessing is more a difficult technology, but compared to the greater quality and quantity of art assets necessary to be competitive (when you have to model, texture and bump map every banana and apple in a bowl of fruit you're burning up artist time) and the greater fidelity of overall simulation (eg. physics-based animation, sophisticated lighting and shadowing) I think it's not a big deal.
Part of the cost will be defrayed by increased use of middleware, especially for physics, animation and rendering, which will be internally parallelised and designed to run on say 2 hardware threads or 3 SPEs and leave the rest of the system resources available for something else.
Wii titles will be distinctly cheaper to make. They won't go toe to toe with Xbox360/PS3 on graphics or depth of simulation but they have other ways to make their mark of course and the lower cost means it'll be easier for publishers to greenlight more experimental titles (assuming the install bases are comparable) because the business risk will be lower.
I've not delved deeply into the early Xbox360 games (I was too busy with my own Xbox/PS2 game) but I would not expect them to have made much use of the multiple CPU cores, not would I expect early PS3 games to be getting much parallel use out of the SPEs. There'll be some advantage taken but there will be significant room for improvement. This is generally a good thing because - as long as the early games are good enough and gamers are impressed by them and have fun playing them (both are important) - it means there is scope to grow and provide new experiences as developers gain experience and confidence with the hardware.
Ohh, the WiiConnect24 stuff is a good question - I have no idea how they'll handle that while playing Gamecube games. Maybe they'll just act as if the console is not connected to the network and cache messages at the server. Interesting point though.
The locked cache existed in the Gamecube, but the bigger point about allowing general improvements to be turned on via a register is a good one that I hadn't thought of. I should've remembered it because I used exactly that feature during Pin2000! MediaGX's built-in video hardware either did VGA emulation via CPU exception (which we did not need) or you could program it yourself at the register level to do hardware blitting (it locked 1K of the 4K level 1 cache as its blit buffer, in another amusing synergy to this discussion). Thanks for pointing that out - it may be that they've done that for some broader features.
The PS2 has pretty much an entire PSone on a chip. It's called the IOP. When it's not doing PSone emulation it's running the I/O subsystem. Even then some games don't work correctly. As they've cost-reduced the PS2 and changed that area of the hardware the list of games that don't work has grown (it includes Tekken 5 on the most recent consumer hardware rev, even). I don't know how PS3 is doing it but Xbox360 uses software emulation and look at the mess of that (because yes cycle emulation is incredibly hard as you rightly say).
I generally consider consoles to be embedded because they do one thing, namely play games, and one piece of software gets complete access to the hardware, down to the metal, while it's fulfilling that role. This perhaps isn't quite a correct use of the term but it feels right to me and console programming is much more akin to the other domains of embedded programming (I used to work for a defense company back in Britain) than PC-style programming. This distinction is becoming blurred on this coming generation of consoles because of the things they do behind your back (network presence and so on).
The highly timing-critical areas of code usually fall into interrupts or low-level parts of rendering where they're moving data from memory through some algorithm on the CPU and then out to the GPU as part of a command packet. Games drop frames when they can't swap video buffers within 1 (or 2 if they run at 30Hz) TV fields because they're trying to do too much overall work. That can be because they couldn't get all their GPU work done (too much geometry processing or drawing) or CPU work (too much setup or general game simulation). It's a much higher-level issue than individual packet flow at the bottom of the pipeline where the time a cache line prefetch takes or a dependent single-precision FP multiple takes may cause you to write something to memory before the GPU has finished reading it (for example).
I fully expect that the rest of the Wii hardware has been clocked up by the same amount to make all this stuff work.
I am well aware that ISA-level compatibility is enough for application level code, where timing and other performance dependencies are weak to nonexistent. This is not the case in embedded systems especially once you start communicating with other devices on the system bus (eg. a GPU via a scatter-gather pipe). Single cycle differences or similar can and do break code in non-trivial ways. I have seen this between revisions of development hardware.
Changing the microarchitecture would have implications for backwards compatibility with Gamecube software. My personal opinion (as someone who has programmed for Gamecube in the past and is working on a next-gen game) is that they will have made no changes. The new part is just a die-shrunk up-clocked Gekko and there's nothing wrong with that.
To back your more general point up, although people seem to have a low opinion of what the Gamecube hardware was capable of it's unwarranted. It's true that many games didn't get much out of it, but look at Starfox Adventures (from 2002 no less) to see what you could achieve. 480p and 16:9, fur shading, bump mapping, refraction and reflection for water (and ice), realtime environment lighting for the day/night cycle and lots of particles. It's a very pretty game indeed.
Even if no new capabilities are added to the hardware, Wii games will look great and the demos I played at E3 were pretty damn fun for the most part.
Full disclosure: I've been platform lead on PS2 and Xbox games and am now working on a next-gen title. You'd be surprised actually at what can be done to uprez art at a much lesser cost than redoing it from scratch. It doesn't come out looking as good as art (and a rendering pipeline) designed from scratch for next-gen but it would've been good enough for a launch title. Assets are often made at better quality than a console can handle and automatically downsampled as part of the art build (lower res and bit depth/compression) or just used as reference to make the low-poly versions or for cutscene/marketing renders (character models). The hardware itself can help somewhat when you enable anisotropic filtering, better antialiasing and a better lighting model. Redoing character heads with more polys helps enormously and doesn't take that long.
The biggest kicker is that you can outsource 90% of this work (either to dedicated companies in the west, or to eastern Europe or to China) so it can be done cheaply and with much less creative risk than creating new elements from scratch.
Lego Star Wars is certainly more commercially viable but I bet it's not that much cheaper to make. It's a bit smaller and of course it has basically no voice acting but it still has 18 levels, most of which are fairly large. It took me 35 hours to get 100% completion on the game.
The big difference is the accessibility of the gameplay and the polish of it. From things like the humour in the cutscenes (Stormtroopers giving each other noogies when you escape Mos Eisley!) to technical matters like supporting 16:9 and 480p on Gamecube (which really show off the art quality) to the game's stability (no crashes and I only found one logic bug - you can activate the 6-switch platform in the Endor bounty hunter level causing you to fall out of the world). These things combine to make the sales difference and when you're talking about millions of dollars to make and sell a game it's hard to gamble very often.
If the LucasArts biz guys were smart they would've greenlit an Xbox360 version of the game as a lunch title with the art uprezzed a bit, the original stuff finished up, the bugs fixed and some new stuff to do (add a hidden planet with some Jedi-only tasks perhaps, or a flying minigame or two). An extra nine months or so of development with a small team plus outsourcing the art tasks would've been cheap and it would've been a great seller (450k+ easily as a big name license plus being the only RPG).