Which had the most powerful processor, TurboGrafx-16 or SNES?

[kool kitty89]

They were specifically talking about the SNES running a faithful port of Sonic, with the Sonic sprite moving through a stage at top speed while being scaled up to fill the screen.

No, they were changing the context back and forth without proper explanation.

If you read it carefully, they stop talking about playing "like sonic" (fast, etc), when they mention "also" which could mean under different circumstances. (which WOULD apply for boss battles or special cases)

That, and marketing obviously wouldn't properly understand the ins and outs of using the SNES's special capabilities.


Actually, I kind of like that article, amusing and a good mix of real tech info used in a specific context twisted by marketing . . . but nothing excessive in terms of actual false statements (ie like Neo Geo ads . . . or even some of Sega's own statements/editorials like claiming DKC used added hardware on the cart). The list of trade-offs are obviously a pointless comparison (many aren't useful advantages one way or the other -like having more "custom chips" or dual PPUs, etc, etc) and most of the twisting is done through omition of the MD's advantages. (the comments on "true digital audio" or "signal to noise ratio" are also obviously wrong, among other things)
It's a promotional article, obviously, treating it as anything more would be an ignorant mistake. (it is interesting that they actually list the Genesis's aesthetics -ie "black control deck" as being an advantage)

Hmm, maybe I like it a bit more because that's exactly the sort of marketing push that I was thinking of when I said NEC should have cut out the bittness BS with their own marketing showing the "real" source of power/capabilities of an overall system (let alone the CPU itself).
That Nintendo article came particularly close when they started to touch on the CPU's place in a given game console. (expanding on that could mean pointing out how the Atari 2600 has almost the same CPU as the NES at about 2/3 the speed/performance -but the way the rest of the system works is obviously the bigger issue- or how the Colecovision and Master System have the exact same CPUs at the exact same speed; then the actual architectural differences that give different advantages and trade-offs -obviously focusing on the PCE's advantageous cases specifically given the promotional context )
Obviously, NEC wouldn't have named it the TG-16 in that case either. (that name doesn't even have a very good ring to it, but they couldn't really use "PC Engine" either . . . "Turbografx" alone doesn't sound especially good for that matter)




On another note in that article:
The claim about the SNES's memory access is rather loaded. At 3.58 MHz, it does complete a memory access at about 86-88% faster (280 ns vs 522 ns), but that's for an 8-bit read vs a 16-bit read on the MD. (so the MD takes ~1.87x times as long, but can read double the data in that time) And then there's the bigger issue of the SNES actually runs at 2.68 MHz for all games in RAM (and all early games in ROM as well), so that's only 373 ns accesses and the MD only takes 1.39x as long per access then. (but still can do 2 bytes in that time when the SNES is handling 1 byte)
And that's just memory accesses, not actually addressing performance benchmarks for running code. (the SNES executes most instructions much faster, but the simpler instruction set means more instructions needed for some operations the 68k does with fewer, slower/more powerful instructions -to which point it depends on the type of game, but the SNES is so slow that it still will only come close to even in better cases, more so with later 3.58 MHz games)

The PCE's CPU accesses ROM and RAM at 140 ns, so 273% faster than the MD (MD takes 3.73x as long to complete an access), but still 8 vs 16 bit meaning the PCE has a nominal ~87% bandwidth advantage over the MD's 68k. (double that for 8-bit specific operations -the same cases where the SNES would have a moderate advantage over MD bandwidth)
Then there's the actual computational performance again, still cases where the 68k could be preferable, but a much wider margin for the PCE's CPU to match to beat the 68k in other cases. (any case where the SNES would be closer to even with the MD, the PCE should beat both by a fair margin -some of the biggest exceptions where the MD would be better could be for 3D games, though the MD has a bigger advantage there with packed pixels vs planar on the PCE, so it wouldn't be an even comparison in any case)

[Joe Redifer]

They could not scale Sonic up to see individual hedgehog hairs. Individual pixels, maybe. Mode 7's scaling was very rudimentary. And Sonic would have to be his own BG layer, kind of a waste.

I think the underlying question here is: Could the SNES at least appear to do anything that the Turbo can do? Could it run any game the Turbo does without any noticeable differences or compromises?

[sheath]

I thought Valis IV ran pretty poorly on the SNES. Also, while I like Rondo of Blood better on PCE CD, it can't be argued that the graphics are more colorful on the SNES. I think the PCE was better at line scroll racers than the SNES was. But I would have to really dig in and compare shooters between the two systems. Would slowdown and fewer sprites on screen be a good indication of worse CPU performance?

[awack]

I like Rondo of Blood better on PCE CD

Its pretty good example of the faster cpu, for example, Dracxx is limited to about three mermen where Rondo has about eight.


Death has more blood plus more cyths, all while everything moves faster, it feels like the game is moving in slow motion if you play them back to back.

I dont know if Joe is asking for something more abvious, and animation doesnt count, since thats just the fact that its on CD.

[sheath]

I think we have established that animation in a single scene is well within what should have been possible on other platforms, it's just the total game's number of boss fights with all of their animations that would probably not have been possible on a sub 2 Megabyte cartridge.

[Black_Tiger]

They could not scale Sonic up to see individual hedgehog hairs. Individual pixels, maybe. Mode 7's scaling was very rudimentary. And Sonic would have to be his own BG layer, kind of a waste.

I think the underlying question here is: Could the SNES at least appear to do anything that the Turbo can do? Could it run any game the Turbo does without any noticeable differences or compromises?

I think that the sprite limitations that the SNES has are more limiting in practice than they are an advantage in theory. Judging from games that were released, it seems like the SNES can't put up as many sprites or as big overall.


















All but the Bonk pics and Drac XX pic are awack's.

[awack]

I think we have established that animation in a single scene is well within what should have been possible on other platforms, it's just the total game's number of boss fights with all of their animations that would probably not have been possible on a sub 2 Megabyte cartridge.

Dracxx is a 2Meg game, and even though it has fewer levels, a single player and half the character sprites, almost everything is missing frames, plus some of the largest sprites(more memory) from Rondo are the ones that are missing.

rondo=2900 frames
dracxx=1080 frames
SCIV=700 frames plus the characters in this game are very small(its only 8Megs)

On top of that, Rondo has far,far more soundfx than XX...in order for Dracxx to be an excact port(not counting music or cutscenes), it would have had to be the largest game of its type released for the snes.

But your right in that if they wanted, they could have made Dracxx even smaller and matched Rondo scene for scene.

[Black_Tiger]

Rondo was only huge because of excess. A cart/card version could've been made with only 6 stages and had superfluous animation and samples dropped. Most people don't even notice all the extra animation. I think that 16 megs could've made a great playing and still great looking port.

If each stage was still roughly 2 megs and bosses 1 meg each, that's 18 megs right there.

[awack]

No doubt, dropping three levels and adding 2 megs would have gone a long way.

Most people don't even notice all the extra animation

Very true, there have been three people who think that the boxy midboss in Gunstar heroes has better animation than anything in sapphire, a whole messege board agreed that zelda for the nes aged better than rondo because of better animation....so, like you say, it doesnt need to be perfect.

[kool kitty89]

I think that the sprite limitations that the SNES has are more limiting in practice than they are an advantage in theory. Judging from games that were released, it seems like the SNES can't put up as many sprites or as big overall.

No, there's nothing limiting that technically on the SNES. (comparing some MD games to PCE will also show a bias for smaller sprites, though perhaps less so than the SNES)

The limits come from lesser flexibility, and that's only an issue when you need a lot of sprites of different sizes. (you have to make careful compromises with the 2 sprite sizes used on-screen vs the PCE -or specially MD- with the ability to use any sprite size for any sprite on-screen -of the available sizes)

OTOH, the SNES is better in every way than the x68000's sprite engine, same per-line and on-screen max limits, but without being limited to ONLY using 16x16 sprites.


Pulling off many sprites on-screen is a bigger issue on the SNES due to CPU overhead for collision detection, but a few, very large sprites should be no problem at all. (that's where the per-line sprite bandwidth and larger max sprite sizes come in handy)


Of course, there's also the memory issue. Larger sprites take more ROM space, so you have to take that into account. (dropping animation in favor of larger sprites is one possible trade-off)
The SNES also has more work RAM to decomress/buffer graphics into, so graphics that compress well in ROM can be used rather flexibly on the SNES.

No doubt, dropping three levels and adding 2 megs would have gone a long way.


Very true, there have been three people who think that the boxy midboss in Gunstar heroes has better animation than anything in sapphire, a whole messege board agreed that zelda for the nes aged better than rondo because of better animation....so, like you say, it doesnt need to be perfect.

Yes, animation seems to be a funny thing . . . most people seem to pick out certain things a lot more than others. (for most people, the added BG animation in SFII SCE compared to the 2 MB/16 Mb Turbo Beta is probably barely noticeable -Turbo beta also stylized graphics around careful use of color without dithering while SCE optimzed around dithering -the undithered approach may also have been to optimize for compression in ROM)

For that matter, most people probably noticed the sound issues on the MD version of SCE than the added graphics/animation afforded by that added MB over (or 512k over CE/Turbo), or the added MD with Super SFII on MD over SNES. (albeit the SNES and MD versions all have some pretty weak voice/FX samples, very low quality and cut-down and actually worse in SSFII -with all percussion samples removed from the MD game, so Capcom obviously thought graphics/animation were more important than balancing that with good audio quality -be it use of more ROM and/or investing in tight sound programming on the MD to allow clean sample playback and perhaps even realtime software ADPCM decompression)

They could not scale Sonic up to see individual hedgehog hairs. Individual pixels, maybe. Mode 7's scaling was very rudimentary. And Sonic would have to be his own BG layer, kind of a waste.

Yes, if you take that statement literally, they'd have needed a LOT of animation to pull that off . . . or a single, very high-res texture that was downscaled in mode 7. (mode 7 is limited to a miximum of 16k pixels though, or 256 8x8 tiles, rather . . . so at most, you could have a 128x128 "sprite" texture or other size within the 256 tile limit, unless you had redundant tiles in some areas -like most BGs do, but sprites usually don't)
Not to mention how much VRAM space that would use. (I think maxing out the full 256 tiles ends up using a full 32k in VRAM, 16k for the tiles and 16k for the tilemap/tables)

And, technically speaking, the SNES's sprite capabilities actually would allow an entire 256x224 BG layer to be built out of sprites alone (albeit just 1 plane, like the PCE) and still have as much sprite bandwdith per scanline as the MD in 256 wide mode (or the PCE), albeit still with the general sprite flexibiltiy disadvantages over the MD (and to lesser extent PCE). Actual number of sprites on screen left over (of the 128 limit) would depend on how large the sprites were that build the BG. (if you used 64x64 cells, that would only use 16 sprites, or 12 if you cut to 256x192, but smaller sprites would give much more flexibility for color and VRAM space -more ability to re-use graphics)
Of course, doing a solid BG plane like that would be rather ineffient for the sprites. Best case would probably doing a more Neo-Geo-like approach using segments of BG at various sizes composed of sprites (except with far fewer sprites to work with overall -on screen and per line), probably with some careful use of palette swap raster effects on the single-color far BG layer. (including Atari/amiga-style sky gradients)

Very few SNES games try to use sprites (or mode 7) in that way AFIK, but it's an interesting possibility.

I think the underlying question here is: Could the SNES at least appear to do anything that the Turbo can do? Could it run any game the Turbo does without any noticeable differences or compromises?

No, it's not good enough to be able to do everything the PCE does and then some. (so not like the MD or PCE over NES or SMS . . . though there's arguably a few specific things the NES can do that the others can't, at least without using more memory -then again, the NES also needs 2 cartridge buses to do all of its games, so a cost trade-off right there)

A lot of PCE games could probably be done on the SNES with little difference in graphics (the fewer SNES palettes would be limited, but it wouldn't be too bad -porting PCE to SNES with no special color enhancements would limit the SNES to a disadvantage though -not taking advantage of the SNES's 15-bit RGB palette).
Sprite optimization on the SNES could be more difficult, but (from what Tomaitheous mentioned) a lot of PCE games aren't especially well optimized in that area either and the SNES has 2x the sprites on-screen and per line (double the pixels per line too) to make up for the limit of 2 sprite sizes on-screen at a time. (one of which would usually be 16x16 pixels, the other varying more)
On the Sprite end of things, it would be better than trying to port PCE games to the x68000. (only has 16x16 sprites of the same limits as the SNES)
There's probably a fair number of cases where such PCE to SNES ports would have less (or no) sprite drop-out or flicker where the PCE version does.

You definitely would NOT want to try pushing PCE dynamic tile effects on the SNES. (aside from limiting color use further and using more memory, you've got the SNES's tight VRAM bandwidth bottleneck limiting that, let alone CPU speed limits for cases of realtime drawing/tile shifting/etc; so re-doing any such effects with hardware BG layers would be extremely preferable)

Ignoring the 344 wide PCE games (or very few 512 wide examples), the other issues would be sound, animation, and CPU resource.
On the sound end, the SNES can technically match the PCE's sound system, though the compression, interpolation, and filtering (the latter more an analog issue iirc) will tend to make some things sound worse (others possibly better), the simple sample sound chip in the Sega CD would be a much more direct match for simulating PCE sound.

Animation is limited heavily on the SNES by VRAM badnwdith, though I think the DMA block transfer is actually somewhat faster than the PCE's CPU block transfers (on a peak bandwidth basis), but not nearly as wide as the MD's advantage in that area. (still, you might have some cases where limited burst of updates are useful and thus not a disadvantage for the SNES, other cases could favor the PCE more, either due to overall bandwidth -without clipping the screen- or due to flexibility of updating at any time rather than only vblank)
Comparing the unexpanded PCE, the SNES also has more RAM to decompress graphics into, so it can get more out of the same amount of ROM. (to some extent)

As for CPU resource, the PCE wins by a wide margin, but there are some mitigating factors, like CPU time spent on PCM playback (generally not a huge chunk, depending on the sample rate, sample format, and efficiency of code), and then there's CPU overhead for VRAM updates and dynamic tile effects. (but the SNES CPU has to be halted for DMA anyway, so that's not a big loss for the PCE -and the flexibility of VRAM updates on the PCE can give net advantages depending on the case)
So overall, even with added overhead (which varies by game), the PCE will still tend to have a lot more CPU resource than the SNES, especially compared to the large chunk of SNES games running at 2.68 MHz in ROM (all run at that in RAM, unfortunately), so any game that ends up CPU intensive would be more problematic on the PCE. (most commonly, that's seen in sprite-intensive games like SHMUPS where collision detection calculation is an issue)

Any PCE game that starts to run into slowdown issues at any point (due to CPU limits, usually for animation bandwidth too) will be significantly worse on the SNES under the same circumstances. (there would be exceptions of PCE games doing really heavy CPU drawing or sound tasks on the fly, but AFIK no PCE games pushed that sort of thing -most dynamic tiling is pure animation or limited redrawing of very few tiles on the fly, and few games really push a lot of PCM in music/FX at all, let alone something intensive like a software mixed MOD player or software ADPCM decoding)

Some PCE games may be CPU-light enough to not have any problems on the SNES at all.

[Black_Tiger]

The limits come from lesser flexibility, and that's only an issue when you need a lot of sprites of different sizes. (you have to make careful compromises with the 2 sprite sizes used on-screen vs the PCE -or specially MD- with the ability to use any sprite size for any sprite on-screen -of the available sizes)

That's what I meant. On paper the SNES has crazy sprite capability. But if you look at how the games turned out, they typically have fewer sprites on screen and they usually don't get very big or there isn't as much variety as PCE and MD games, whether carts or CDs.

Whether it has to do with sprite restrictions, various resources or whatever, the end result for a system that was pushed much further than the PCE is less sprite handling ability in typical game circumstances.

[roundwars]

On paper the SNES has crazy sprite capability.

Eh, I don't know. Sure, it's nice to have 128 total sprites, and allowing 32 sprites per line instead of 16 or 20 gives you some nice breathing room. But the most important capability is total sprite pixels per scanline, and by that metric the SNES is in pretty much the same class as the other two systems (it can draw 272 sprite pixels on a 256 pixel row, compared with 320/320 or 256/256 on the other systems). It only seems crazy on paper because this last limitation usually isn't mentioned; if all you know is that it has 128 sprites and they can be up to 64x64, the SNES sounds pretty damn good.

The SNES does have some sprite flexibility limitations that the PCE doesn't have, but on the other hand the PCE uses 16 pixel cells, making it arguably worse in that respect overall. I think if SNES games really do have fewer sprites than PCE games it's probably due to other factors (CPU maybe). The Genesis, of course, has the most flexible sprite sizes out of all of them, and the 320 pixel format might be an advantage in some ways as well.

I should mention though, in some cases the various sprite limitations can be worked around; the NES/FC only has 8 sprites per scanline and can only draw 1/4 of a screen width's worth of sprites per line, but it does have 64 total sprites. And Summer Carnival '92 Recca seems to use every one of them. It's got as much action as any 16-bit game. Of course, in genres other than vertical shooters, it's harder to orchestrate your sprites so that they rarely fall on the same scanline.

[evilevoix]

The SNES CPU is weaker no doubt, the clock speed is just too low. If it was like 5-6MHz it would be on par with the M68000 on the Genesis.
The PCE CPU is pretty efficient, it might be 8bit but running at 7MHz it's a scary beast. If you use as much 8bit operations as possible it can exceed the M68000 in performance, but this takes quite a bit of planning.

You're not getting RESQ out of it.

"Real life" performance will be worse since there's no auxiliary soundchip, and the need for dynamic tiles takes quite a bit of extra processing (either for realtime computation or to send them to the screen).

I believe it was stated last time this was discussed that comparing clock speeds to two entirely different CPU’s is highly dubious. Wasn’t it stated that the SNES CPU while having almost half the clock speed of the Sega Genesis M68 but almost twice the efficiency? People are also stating that the SNES has helper chips; don’t all the systems have them? MD with the Z80 for sound, the TG16 has two 16 Bit coprocessors filtered through an 8-bit bus.

At this point it is really hard to assert dominance. The SNES really has amazing grafx IMHO but I prefer the style of the MD, even the sound. The SNES seems by far the most polished, I am taking a run through Yoshi’s Island right now and the game is perfection. How can you argue hardware dominance at this point? The TG16 does TG16 games very well, I doubt it would do SNES games very well like say, Jim Powers or so on. Each hardware specification is just that, for itself and developers. The best way to end the argument is to post a Video of what people agree to be the best game for each system, Cart vs hucard hell even CD, the best representation.

Also, I am not sure if I am being biased or not but IMHO I feel that the MD controls are far superior to all three systems and makes it the most fun to play. The SNES I feel is a bit slower in response, games just do not control as well.

Finally I am now reading more in this thread about “Bit-ness”. From what I remember last time, you can’t judge the TG16 as an 8-bit machine only or you could argue that the MD was 32bit and the SNES was only 8-bit but it didn’t matter. Then I read that the TG16 does 8-bit games better then all machines yet the MD does 16-32BIT the best and 8-bit read vs a 16-bit read on the MD…. When does bit-nes count? Also it is argued that the PCE is superior to the MD/SNES in processing speed/power but only does a single plane, if the MD/SNES were limited to a single plane would they be comparable?

[sheath]

In regard to the TG16 the comments about it being faster at 8-bit processes means that it outperforms the other systems at code that only depends on 8-bit wide instructions, how that affects the graphics or overall performance is up to the developer. The graphics chip determines how the graphics look and what kinds of details can be displayed simultaneously on screen. That's why people keep bringing up the SuperGrafx and its added sprites and background layer, same 8-bit processes with "more" graphics detail. I am not sure that the Genesis or SNES having more background layers is a significant load on their CPUs, it's mainly a feature of the VDP and PPUs that allows for the extra layers, and parallax scrolling in the Genesis' case.

Similarly, the Genesis and SNES CPUs being able to calculate or send data in 16-bit wide chunks versus 8-bit chunks has little to do with how much they can calculate per cycle. Think of the "bitness" as a highway, 8-bit is a four lane highway and 16-bit is an 8 lane highway, now consider how much traffic can move over these roads in a day when both highways have different speed limits. They both move a ton of traffic, but the 8-bit highway could move more if the speed limit was higher.

[evilevoix]

In that regard, what makes the PCE dominate with its 8-bit bus Vs. the MD or SNES. Is it because it has two 16-bit GPU’s to enhance its colors and Grafx processor? I understand the width and processing capability explanation between 8-bit and 16-bit (I asked my dad the same question when I was a lil’ kid and deep into the bit-wars.) and your stating that the PCE 8-Bit CPU is so fast that it surpasses the 16Bit MD or SNES like an 8-bit highway with a speed limit of 120MPH vs. a 16-bit highway with a 55MPH speed limit? How well does this triple chip architecture work (8-bit CPU and two GPU’s) and is it harder to program for then say the MD?