Sega Mega Drive vs TG-16 Graphics chips

[tomaitheous]

It's just software scrolling a 32x32 pixels image. The colors are to prove it isn't just hardware scrolling (they're tiles with different palettes).

And that bitmap has 6 colors :V

EDIT: please tell me you didn't really think it was real translucency (which would be even more awesome). The MD can't do that on its own.

Ahh, so realtime dynamic tiles (32x32 segment). You're rotating the tile chunk via the cpu. And it takes a total of 21 scanlines of cpu length? That includes DMA time?

I wasn't sure if it was supposed to be something different.

[Sik]

Between 19 and 25 lines (depending on the scroll value, rotating bits is slow), and no, DMA time isn't included (although if you do chaining to do multiple fake layers then you'd do DMA only once but scroll twice).

[Joe Redifer]

Do a demo with 5 overlapping layers. It is OK if two of them are hardware.

[Sik]

Do a demo with 5 overlapping layers. It is OK if two of them are hardware.

Challenge taken, although expect programmer's art. Will come up later with the ROM.

[Tom M.]

I doubt TurbografX uses more than some 50-100 colours at once in its games. Pretty much comparable to Mega Drive, and for sure it looks like Mega Drive. What si more important to me is that TurbografX cannot draw so many sprites as Mega Drive can + the CPU is slower. Another win for Sega at least on graphics parts. The sound is a different story though. That NEC chip has some really nice envelopes combined with PCM. Definitely smarter than damn metalic FM chip.

[Black_Tiger]

I doubt TurbografX uses more than some 50-100 colours at once in its games. Pretty much comparable to Mega Drive, and for sure it looks like Mega Drive. What si more important to me is that TurbografX cannot draw so many sprites as Mega Drive can + the CPU is slower. Another win for Sega at least on graphics parts. The sound is a different story though. That NEC chip has some really nice envelopes combined with PCM. Definitely smarter than damn metalic FM chip.

Technical specs are much more complicated than that, but it's the end result matters. Most TG-16 & SNES games using 50 - 100 colors don't look so comparable to Genesis games using half as many colors, at least not by the kind of standard that says that the TG-16 cpu is slower. It doesn't matter how "smart" a sound chip is, both the TG-16 & Genesis have games with great audio that can sound nicer than the "smarter" SNES sound chip.

[tomaitheous]

I doubt TurbografX uses more than some 50-100 colours at once in its games.

That's about the range, yeah. But you don't simply count color like that on these consoles. Color relative to detail, range, and specific areas. It's about the subpalettes. These have a larger influence than simple color count per screen. A 40-50 color MD game won't look the same as a 40-50 color PCE game. The Genesis has 4 subpalettes and the TG has 32 subpalettes. The Genesis second BG layer can help alleviate the limited 4 subpalettes in some situations. And the TG16 uses some more subpalettes than normal since it only has a single BG layer. But with the massive amount the TG16 has, it definitely has the edge even when required to use more for BG detail.

TG16 has the edge in graphics, while Genesis has the edge in graphic FX. Depending on the requirement of the game, one will be more desirable than the other.

What si more important to me is that TurbografX cannot draw so many sprites as Mega Drive can + the CPU is slower.

MD is great for sprite optimization, no doubt about that. But we've already discussed the 'prowess' of these two CPUs. They relatively the same performance level. If one is slower or faster in a specific task or area to the other, it's not a very big difference.

[awack]

The average is between 50 and 90 colors but there are dozens of pcengine games that use more than 100 colors.

[tomaitheous]

Here's an example of color count and subpalette differences:





Top is Genesis original pic and has 34 colors. Bottom is the arcade pic, reduced to Genesis 9bit palette, then quickly reduced to 34 colors. Both have the same amount of colors. But for the Genesis to represent the arcade conversion pic I did, you need quite a bit of subpalettes to do it. So while the color count is exactly the same between them... the range of color, detail via colors, and color in condensed areas is not the same. That is how a subpalette type system can put restrictions on graphics, regardless of simple color counts.

Here's another one:




These color reductions were done pretty fast too (no hand optimizations). The top is the arcade version scaled to the Genesis 320 res, reduced to 9bit palette, then color reduced to 45 colors. 45 color count is reasonable by most Genesis games. Final Fight CD probably gets up into the low 40's when two player mode and more enemies onscreen - at times. So gong by color count only, it's a valid comparison. At 45 colors, it still looks pretty good compared to the arcade original IMO.

The second one I masked out the two characters so I can get the colors down to 36 with less hassle. The last pic is of the SegaCD game and is 34 colors. The middle and last are for direct comparison.

Only 2 more colors over the SegaCD one, and yet the range of color, where it is, relation to detail is much more pronounced. Again, the SegaCD version is the result of limited number of subpalette and trying to spreed the color across it too far.

[kool kitty89]

I think it was a bad analogy because of the typical 2600 game expectation. Memory was a key factor in the complexity of a game more so than the processor. That hardware collision (I can only assume the usefulness of it, if it's anything like the A8 computers) is applicable to other type of genres. Giving just as much benefit to them as a typical and extremely simplistic 'shooter' would on the 2600. And given the hardware arch, there's just soo many other influencing factors that need to be taken into consideration. You can't compare the 2600 strengths and weaknesses relative to the shooter in comparison to another type of genre, in the context of these three systems from the 16bit era. There's just waaaaay to many variables.

If you had made the analogy of C64, then that would a little better. C64 in simplistic terms is more like the consoles we're talking about now. It's not exact, but it's closer than trying to use the 2600 as an comparison. And I'll definitely give you that Shmups often have directly exploitable areas in higher level game logic that extend down into lower level optimization. But then again, if you really look past all the fluff of the C64 'FX' and dynamic tiles and sprite register reloads mid frame - these games themselves are rather simplistic in design. Heh - we had a similar discussion on spriteminds in the context of 'pushing around sprites' and the perception that it took cpu 'muscle' to do this. It was in the context that the Genesis could push around more sprites or scrolls because it had a faster cpu. Anything can be scripted or compiled, with just simple relative transforms to screen positions. And I took the counter argument that such 'fluff', while impressive looking, didn't take up much at all in the relative to real game logic attached to sprites or objects. There was no collision detection to other objects or background maps.

Hmm, I was gonna bring this around back into point... but now I forget were I was going with this I'll just sit here and drink some coffee. Maybe it'll come back to me >_>

Anyway, come on Chilly Willy. We can't have this conversation without you I've never done sport type titles or games that require AI (without cheating or 'real' AI). I have the feeling you do, though. Spill the beans!

A game like Vanguard on the VCS or 5200 would be among the closest examples to compare with more modern shooters. (the VCS game scrolls too, even diagonal, though choppy -though choppy for vertical scrolling too unlike RiverRaid and such)

http://www.youtube.com/watch?v=epWjexDMznY

http://www.youtube.com/watch?v=qworChFnK2Q

Like a lot of VCS and many A8/5200 games, the sprites are carefully organized to avoid putting too many on the same scanline (to avoid flicker), though there's a bit of flicker in the A8/5200 version of Vanguard.



Vanguard on the 5200/A8 also shows off the hardware scrolling capabilities rather well. (Zaxxon is another of the few games to really show it off in the early 80s -especially compared to the choppy CV version, let alone the even slower/choppier MSX/SG-1000 version that avoided forcing faster gameplay like the CV game -the CoCo has some nice software scrolling on Zaxxon too)















[QUOTE=tomaitheous;350469]That's about the range, yeah. But you don't simply count color like that on these consoles. Color relative to detail, range, and specific areas. It's about the subpalettes. These have a larger influence than simple color count per screen. A 40-50 color MD game won't look the same as a 40-50 color PCE game. The Genesis has 4 subpalettes and the TG has 32 subpalettes. The Genesis second BG layer can help alleviate the limited 4 subpalettes in some situations. And the TG16 uses some more subpalettes than normal since it only has a single BG layer. But with the massive amount the TG16 has, it definitely has the edge even when required to use more for BG detail.

TG16 has the edge in graphics, while Genesis has the edge in graphic FX. Depending on the requirement of the game, one will be more desirable than the other.
That's also why the Amiga (in the 31 color 5bpp set-up -let alone EHB) tends to be much more flexible color-wise than the Genesis, even with 1/2 the number of total color entries (without reloading with COPPER).

Of course, if you want to use dual playfields (ie much less blitter intensive to manage), that knocks it down to an 8 color layer, 7 color layer, and 15 colors for sprites (or 3+3+3+3 colors if you leave them as 2-bpp), and using 4bpp on 1 plane would be less blitter bandwidth hungry than 5 or 6bpp as well. (depending how you optimized things at least)

And of course, the Amiga has a 12-bit RGB palette, but that's a separate issue from on-screen color count.

Same thing with why the SMS looks a lot better than the NES in many cases due to the 15 color tiles/sprites even though there's only 2 palettes and only 1 allowed for sprites. (or why ST games tend to look a lot better than NES games for that matter)

[Tom M.]

Funny that people mention Atari 2600 in this thread. It is the only console out of them that allows the CPU to fully render the display on the fly rather than being limited by those DMAs, I/Os and other complications... and as far as its hardware sprites collision detection goes, most 2600 games rely on their own software detection (Activision games and many others) because I believe that allows for more precise control of the rendering. So in the end, the winner is (as always) a system that allows for biggest flexibility from software rendering point of view...

[tomaitheous]

Funny that people mention Atari 2600 in this thread. It is the only console out of them that allows the CPU to fully render the display on the fly rather than being limited by those DMAs, I/Os and other complications... and as far as its hardware sprites collision detection goes, most 2600 games rely on their own software detection (Activision games and many others) because I believe that allows for more precise control of the rendering. So in the end, the winner is (as always) a system that allows for biggest flexibility from software rendering point of view...

Yeah, but that's not saying much. Just look at the res of the 2600 games.

[Chilly Willy]

That's about the range, yeah. But you don't simply count color like that on these consoles. Color relative to detail, range, and specific areas. It's about the subpalettes. These have a larger influence than simple color count per screen. A 40-50 color MD game won't look the same as a 40-50 color PCE game. The Genesis has 4 subpalettes and the TG has 32 subpalettes. The Genesis second BG layer can help alleviate the limited 4 subpalettes in some situations. And the TG16 uses some more subpalettes than normal since it only has a single BG layer. But with the massive amount the TG16 has, it definitely has the edge even when required to use more for BG detail.

TG16 has the edge in graphics, while Genesis has the edge in graphic FX. Depending on the requirement of the game, one will be more desirable than the other.

Yeah, I'd go with this. Each has something they do better than the other, so certain games are better on one than the other. Anywho, the TG16 having the edge in graphics is part of the reason I picked up a SGX - it not only has that edge in graphics, but now also has twice the background layers and sprites. It should have been a really kick-ass console, but was a little late to catch on.

MD is great for sprite optimization, no doubt about that. But we've already discussed the 'prowess' of these two CPUs. They relatively the same performance level. If one is slower or faster in a specific task or area to the other, it's not a very big difference.

IF you can keep your game to bytes for everything, the 6502 can be quite a bit faster. Bytes are the fundamental unit of the 6502 and use the least cycles. On the 68000, bytes are there to make certain things easier, but aren't the fundamental unit (words are); you can see this by the fact that byte and word operations on the 68000 take the same number of cycles. I think that's why the SNES kept the resolution to 256 wide, and why 256 wide is more popular on the TG16 than 320 even though the TG16 can do 320 wide no problem. Couple keeping the program to bytes as much as possible with the VERY high clock rate on the TG16 and you COULD do some things MUCH faster than the 68000 could do the same thing. By the same token, go beyond bytes and you lose that particular edge and speeds look more equivalent.