Turbo Duo...What went wrong?

[SamIAm]

So I will agree that, generally speaking, some kind of real-time implementation is going to be ultimately more flexible, but it wasn't really until the Playstation that said implementations were truly trouble-free.

I basically have no disagreement there.

As a big Saturn fan, I've spent a lot of time looking into what the problem was with the system not being able to do transparencies sometimes. Basically, it comes down to the fact that true/real-time transparency effects involve two graphics having their color values averaged, and if the two graphics involved are being drawn by the Saturn's two different GPUs (or VDPs, as they're known), it's inefficient for them to communicate the necessary information.

If all you want is the Saturn's VDP2 to draw a transparent background layer of clouds over another background layer of mountains, then that's no problem at all. NiGHTS shows an interesting case of sprites being transparent over other sprites and polygons, but not backgrounds, because VDP1 was only doing the effect with its own graphics. If you want an effect like though, you've got to allow the system a lot more processing time to pull it off because it involves VDP1 sprites and VDP2 backgrounds. Surprisingly, this feature is also not hard to enable, it's just hard to budget time for.

Speed is the biggest reason why so many Saturn games have fake transparencies.

The bug aspect that you may have heard about is that the Saturn does tend to glitch out when doing polygon-on-polygon transparencies. The only Saturn game to do this in a non-hack fashion is Dead or Alive, and it does it only for the explosion that happens when someone goes outside the ring. The effect is so fast that it doesn't matter if it glitches.

Finally, there are hacks and shortcuts. VDP2 can make a layer of transparency over ALL graphics on the screen very easily, which is actually a very often-used effect. Also well-known is a hack that lets you make a VDP1 sprite transparent over a VDP2 background very efficiently, but with one compromise: any sprite that gets in between those two will simply disappear. Guardian Heroes did this with one character's red cape. Eventually, this hack was even implemented into Sega's later dev kits.

There, all you ever wanted to know about Saturn transparencies.

[Arkhan]

did people piss and moan this much about transparency when SNES and shit were current?  I know I didn't give a f*ck.

[spenoza]

The bug aspect that you may have heard about is that the Saturn does tend to glitch out when doing polygon-on-polygon transparencies.

See, I used to think this, too. Now I'm not so sure of it. In fact, I bought into the whole "the Saturn is a true 2D machine" and "the PSX only used flat polys". It turns out I was wrong (partially). The only classic 2D stuff the Saturn does involves backgrounds. Saturn sprites ARE flat polys, or very nearly are, as far as I can tell. It has no separate 2D engine or blitter outside of its texturing capabilities. 2D sprites are basically a function of the texturing engine. Now, the Saturn does 3D differently than many systems in that it uses quads, and quads are better suited to 2D implementations than triangles. I don't know the full scope of the system's handling of transparent textures, but if it can do transparent sprites, it can do transparent textures. It may be that it can't do transparent solid-color or garoud-shaded polys, but it shouldn't have any problems with textured ones.

[SamIAm]

My TV was too shit to make out most of those effects anyway.

[kazekirifx]

The average person trying to decide which system to buy in the early 90's didn't give a shit whether or not true transparency could be achieved or not. As Zeta (I think) also pointed out earlier, Did the Turbo have Mortal Kombat, NBA Jam, or Ninja Turtles? No, no, and no. That along with the price, and the fact that most people didn't know anyone else who had one, and hadn't even heard of it doomed it to hardcore obscurity.

Obviously, the reason I liked Pac Man and E.T. on 2600 is because the Internets had told me how bad they were beforehand, and I was fully prepared for the worst. Then, being able to actually force some enjoyment out of them I was pleasantly surprised. Learning how to actually play and succeed at "the worst game of all time" was indescribably satisfying... (And for the record, the "How to Play" video on Youtube I believe was actually made in the 80's.... though I don't know how it was distributed back then. (Probably two boxtops from E.T. serial plus $10.95 S&H  )) This is the same as the 'Waterworld effect' I experienced when I saw the movie Waterworld for the first time ever in about 2007 or 2008. Being prepared for an infamously bad movie made it pleasantly surprising to find some positive aspects in the experience.

I imagine people who got their first Turbo after 2000 or so probably also experienced the 'Waterworld effect' to some extent. They probably have a pretty good idea of what to expect from the system and certain games beforehand, thanks to Al Gore's Internets. But back in the day, it was so different. I wanted every game I bought for the Turbo to be the next Mario-killing blockbuster that would prove to all my friends how awesome the system was once and for all. Expectations that high tend to set one up for disappointment.

[SamIAm]

The bug aspect that you may have heard about is that the Saturn does tend to glitch out when doing polygon-on-polygon transparencies.

See, I used to think this, too. Now I'm not so sure of it. In fact, I bought into the whole "the Saturn is a true 2D machine" and "the PSX only used flat polys". It turns out I was wrong (partially). The only classic 2D stuff the Saturn does involves backgrounds. Saturn sprites ARE flat polys, or very nearly are, as far as I can tell. It has no separate 2D engine or blitter outside of its texturing capabilities. 2D sprites are basically a function of the texturing engine. Now, the Saturn does 3D differently than many systems in that it uses quads, and quads are better suited to 2D implementations than triangles. I don't know the full scope of the system's handling of transparent textures, but if it can do transparent sprites, it can do transparent textures. It may be that it can't do transparent solid-color or garoud-shaded polys, but it shouldn't have any problems with textured ones.

Oh hey, I missed this. I was responding to Arkhan last time.

I'm not qualified to go into great depth on the subject, but I remember it was the conclusion of a bunch of homebrew guys on the board where I hung out. I also have personally seen the glitch in Dead or Alive - some polygons simply disappear when the effect is happening. AFAIK, it's exclusively a problem with polygon-on-polygon transparencies, and not a problem at all with polygon-sprite and polygon-background transparencies at all.

Who knows for sure, though. Anyway, yeah, the Duo. It was too expensive.

[jeffhlewis]

and yes, the Atari 2600 version of Pac Man was a goddamn mess.   It's not like Defender where its like "ok, this isn't as good as the arcade but it's still pretty good."

If you guys haven't already, you should really read the book "Racing the Beam" - it's a history and in-depth study of the VCS/2600 platform. They use popular games like Combat, Pac-Man and Pitfall as case studies, including studying the assembly code used in the games and the creative thinking that had to be used to make the 2600 do anything beyond very basic Combat-type games.

I knew very little about the 2600 going into the book (I was born in 81 so I missed most of the Atari age) but I found the talks about the architecture really interesting - basically the 2600 hardware was specifically designed to run a series of VERY basic games like Pong, combat and a BASIC editor, and that was it. Atari had planned to have that hardware around for a year or two. The guys who designed it never dreamed of being able to do anything approaching games like Pitfall and others - those games were really the product of a lot of creative thinking by the programmers and the fact that the 2600 didn't have a screen buffer, so game logic had to be performed while the screen was being redrawn (hence the book title). Programmers had to be fully aware of the registers keeping track of the current scanline and how many CPU clock cycles they had to run code between scanlines. really interesting stuff.

The book also goes over the absolute corporate insanity that brought about Pac-Man - the suits basically gave the programmer like 5 weeks to create the game. It's kind of amazing he was able to do it at all.

Link to the book:
http://www.amazon.com/Racing-Beam-Computer-Platform-Studies/dp/026201257X/ref=sr_1_1?ie=UTF8&qid=1334075025&sr=8-1

[geise]

As probably already stated by others:

Next to no advertisement (except small sections in game mags)

Anime and RPG's weren't mainstream yet

Next to no fighting games unless you imported

Shooting games were starting to die out in popularity

Next to no 3rd party support or Big Budget titles/Arcade hits

Already struggling for market share against Sega and Nintendo

Stores weren't promoting it and had it placed in small obscure parts of the store.

[Arkhan]

and yes, the Atari 2600 version of Pac Man was a goddamn mess.   It's not like Defender where its like "ok, this isn't as good as the arcade but it's still pretty good."

If you guys haven't already, you should really read the book "Racing the Beam" - it's a history and in-depth study of the VCS/2600 platform. They use popular games like Combat, Pac-Man and Pitfall as case studies, including studying the assembly code used in the games and the creative thinking that had to be used to make the 2600 do anything beyond very basic Combat-type games.

I knew very little about the 2600 going into the book (I was born in 81 so I missed most of the Atari age) but I found the talks about the architecture really interesting - basically the 2600 hardware was specifically designed to run a series of VERY basic games like Pong, combat and a BASIC editor, and that was it. Atari had planned to have that hardware around for a year or two. The guys who designed it never dreamed of being able to do anything approaching games like Pitfall and others - those games were really the product of a lot of creative thinking by the programmers and the fact that the 2600 didn't have a screen buffer, so game logic had to be performed while the screen was being redrawn (hence the book title). Programmers had to be fully aware of the registers keeping track of the current scanline and how many CPU clock cycles they had to run code between scanlines. really interesting stuff.

The book also goes over the absolute corporate insanity that brought about Pac-Man - the suits basically gave the programmer like 5 weeks to create the game. It's kind of amazing he was able to do it at all.

Link to the book:
http://www.amazon.com/Racing-Beam-Computer-Platform-Studies/dp/026201257X/ref=sr_1_1?ie=UTF8&qid=1334075025&sr=8-1

yeah.  Activision had some good drugs back in the 80s.  It is the only way I can explain that shit.

[spenoza]

It is rather amusing to find out that the creator of E.T., considered one of the worst games ever, not just on the 2600, was also the creator of Yar's Revenge and Raiders of the Lost Ark, two of the better games on the 2600. The latter two games took a year or so to develop and for E.T. he was given 5 weeks, so that pretty much covers things, I think.

[Arkhan]

It's no great surprise that Yars Revenge and Raiders took a year, where ET took 5 weeks.

In order to develop for Atari 2600, you first have to basically create your own library to access the video hardware. Seeing as Yar's Revenge was an early title, I'm sure Warshaw had to sit and dick around to figure everything out.

Raiders was more advanced than this, again requiring dicking around.

You can see reuse of some stuff he learned in those two games when you look at ET. 

The programming isn't the actual problem with ET.   The problem is the game concept itself leaves a lot to be desired.  It's too ambitious.  Most of those adventurey games are hit/miss.   Raiders of the Lost Ark barely worked as it is. 

ET Should have just been an arcade-like game.   It should have been a few mini-games broken up into segments where you earn a piece of the phone.

Maybe have one that's like a mini pacman, grabbing reese pieces while avoiding the FBI/NASA people
Then one where you're like running from left to right, like moon patrol, avoiding the FBI/NASA while you run thru the woods
Then one where you are elliot steering the bike like Night Drivin' or some shit

bunch of crap like that, all ending with a space-ship flying "get ET's ship into space!" portion.

It would have worked better.   Atari 2600's strong point is basic arcade games.

[NightWolve]

like moon patrol

!!!! Moon Patrol! Hey, we used to pass that game around on 5.25" floppies back in my High School days and when Radioshack's Tandy 1000 PC's were still in style!!! I just thought of something, too, Moon Patrol was actually my first "hack!" Eheh! If you could figure out how to use a hex editor on the DOS platform and edit a binary executable to change "Game Over" into "You Suck!" -- which was my chosen goal at the time -- well, then by God, that earned you your hacker credentials! That was my baptism right there! I didn't know dick about programming, but I sure could do a thing or two with a hex editor!! I don't get it though, you're like ~10 years younger than me and frighteningly far more retro than I am...

[Arkhan]

I'm defective.

I hopped generation gaps, and threw up gang signs while doing it.

[geise]

Arkhan rhymes with Retro "Can"

[Arkhan]

youre a retro can.