Okay, maybe I have an opening to talk about something that's been bothering me for a while.
That reviewer is so innocent and trusting it's just heartbreaking.
The CD-i (recap: famed, beloved home to HERE'S...THE-MAP: THE-GAME, and the "I wonder what Ganon's up to?" improv series hosted by Drew Carey, starring Ryan Stiles and Colin Mochrie) includes as core specifications:
- a OS-9 real-time OS-derived CD-ROM system frontend (and possibly some other internals as well), written in nothing higher-language than C and probably mostly in assembly, which may run entirely out of ROM (aside from a few variables in RAM)
- a 68000 derivative manufactured by Philips, clocked at close to 16MHz. However it lacks a full-featured MMU which may be a real problem in a game like Zelda (as an aside, I like how they name the games after the character you play as, so you really do play as Zelda in Zelda. Philips really paid attention to those focus tests.)
- 1 MB of RAM!
- "Resolution: 384×280 to 768×560"
- on the negative side some nitwits at Sony (I think) managed to fuck up implementation of stereo sound on a certain hardware unit, and some kind of (probably speed-detrimental) fix was required for game code going forward
Sounds a lot like an X68000 (resolutions: 256 x 240 to 1024 x 1024), doesn't it? Even the X68000's software is partially OS-9 derived.
So back to HG101:
If you look at the scrolling in Link or Zelda you'll see that you can only scroll about 2 or 2.5 screens horizontally. This was dictated by the video memory available. [Ed note: That's fine - remember that the backgrounds are all essentially paintings with no tiles. There are sizable animated elements too, which only rarely use color-shifting. This is pretty different from most any X68000 game, but if the CD-i games had used a more traditional tiled format, it seems they should have had far fewer problems than they did.]
Mr DeSharone went on to explain at length all the technical problems with the system, from an inability to properly stream audio, the poorly interfaced infra-red controller, slow 68000 processor, problems with saving and so on. It's a miracle what developers managed to squeeze out of the CDi, and even then AIM (American Interactive Media, Philips' CDi software publishing arm) didn't want games.
Now, I'm sure the lack of an ordinary MMU and some other tasks laid on the Philips 68070 (by contrast, chips in the X68000 were well utilized for multiple functions beyond their original designs) would have hampered the CD-i. And I surely expect that the large, often highly animated backgrounds would soak up most of the system's RAM quickly.
But this doesn't come close to explaining some of the problems with the game. Frankly it seems like the author wasn't interested in defending his own premise, because he had The Word of God. It is nice how some of the issues DeSharone mentions were apparently solved, of course. Infrared controllers: use a wired controller or built-in controls, idiots; the main drawback here was that the games are limited to the usual two-button controller, which means the relatively nice Gravis-derived four-button-pad is not properly utilized - and you'd think that DeSharone and company would have been able to enable an expanded controller configuration option in a menu somewhere, so unless the Gravis-style four-button controllers weren't available during the development phase, or reading two extra inputs completely exhausts the CPU, I think they should have been able to include the option and I'd even say it's more worthy of priority than worrying about people who, for
real, would play a platformer with a fucking teevee remote. Other problems really were sidestepped - the "streaming audio" isn't really a problem except for synchronized sound during the animated cutscenes. It looks like they more or less nailed it (technically I mean, and it's also hard not to notice that the characters make gestures approximately in time with the English script, which is fairly interesting). Sound-wise, though, there's only ever one sound playing at a time, and there's generally not many sounds that can play in a single area (aside from the animated cutscenes which nicely overlay the game world). Nice awareness of the bullet-point this-is-what-corporate-wants-fixed, but what about the gameplay problems?
Why
must you hit rubies (aka rupees) with your sword to collect them? Is having collision detection running on a few extra items that big a drain on CPU time? (The highest sprite count I'd expect for the game is: your life bar, Link, maybe 3-4 rubies onscreen, 3-5 enemies, maybe two weapon shots from Link, and another from an enemy. There could also be a key item somewhere.)
The world may never know why this is so. I don't know if the author meticulously recreated the details of the CD-I's technical issues for the Retro Gamer article he wrote (apparently in tandem with this online content) but apparently the audience is composed of fools who need to be Informed that the games are good, but something technical? Nah, who would care about that? Unfortunately, when the author of this piece set off to change the world, he forgot to make it convincing.