Q*bert, why the divided cubes?

[Tempest]

I'd quit while you're ahead.

 

I get a warning for that?!

No, I was just giving you some friendly advice because right now you sound like an ass and everyone is calling you on it. By all means continue if you wish, I'm sure I'll enjoy the delicious butt hurt that will ensure.

[moycon]

I'll have to admit. I was always a little disappointed back in the day seeing the Atari 2600 version of games.

The comic books would have ads for Parker Brother games, and show screen shots of all the different versions in the background.

Usually if there was an Obyssey version, it always made me feel better because they really looked terrible, but the Atari 2600 was usually next in line.

This was when the 5200, and the Atari computers were out, as well as the C64. The Atari 2600 didn't have a chance looking as good.

Popeye especially stands out, when I first saw the screen shots. Ugh.

I will say, for it's limitations, the 2600 versions played really well. I actually loved the games when finally got them.

[Nukey Shay]

If you reflected the playfield then you would have to choose between having a huge 2 PF pixel gap or squashed cube. Neither would look better.

To draw the pyramid without any gaps you would need to have an asymmetrical playfield, and the pyramid would be off center left or right by 1 PF pixel. This would look better.

 

There is a third "cycle-thrifty" option that could have been used (one implemented in Mouse Trap...and I'm surprised it wasn't used in more games)...and that is to use the ball sprite for a center "pixel". The ball sprite already shares the playfield color...so you would enable or disable it whenever the screen required. Another advantage is that doing so is that the sprite is not as cycle-sensitive as redrawing PF registers. The main disadvantage is that you lose using the sprite for other things...but I don't recall Q*Bert using it.

 

Tho I agree that the programmer was not "being lazy". The 2600 has it's restrictions, and he had the program bend slightly to accomodate this one.

[high voltage]

Just be glad it doesn't look like the Odyssey² version:

 

Not so bad for a first gen console. It actually has the bottom level and probably plays just fine as far as gameplay is concerned.

 

2nd gen actually

 

1st gen: Magnavox Odyssey, Pong

2nd gen Fairchild, Philips G7000 Videopac, VCS, Intellivision etc

3 gen Atari 5200, Coleco, Hanimex

4 gen NES, SMS, 7800

 

 

And since you're a big Wikipedia fan:

http://de.wikipedia.org/wiki/Philips_G7000

Edited June 15, 2012 by high voltage

[Tempest]

The comic books would have ads for Parker Brother games, and show screen shots of all the different versions in the background.

I loved those ads. It let me see what games on other systems looked like. I wish there was a collection of those somewhere.

 

I grew up with the 8-bit port of Q*Bert which is really quite good, so I never had to complain much. I did get the 2600 port when it was released as an Atari red box and thought it was 'interesting'. I played it a lot even though I already owned a superior version simply because it was different.

[+SpiceWare]

I see the VCS Q*bert port as no less a shortcoming than Pac Man.

I have no problem with this. I have a problem with you talking shit about the programmer when you obviously don't understand the limits of the Atari, even after they're been explained, and the tradeoffs required to make a game within those limits.

 

Lots of people have complained that VCS Pac Man was a poor programming job, and do you tell them to "program" a better version?

I've seen lots of people complain about the quality of the port, but don't recall seeing anybody blame the programmer about it because we know the constraints (time and ROM) he was put under.

Programming was handled by Tod Frye, who completed the task in 6 weeks. The game uses a 4KB ROM cartridge, chosen for its lower manufacturing costs compared to 8KB cartridges, which had just become available at the time. After Atari acquired the rights to produce the game, Frye began work on a prototype version. The company wanted to release the prototype to capitalize on the 1981 holiday season.

 

As DEBRO has shown, a rather nice version of Pac Man can be done in 4K - if you have the time. DEBRO was not under a holiday season constraint like Tod Frye was - DEBRO's initial post was January 14, 2006, the first "final build" was over a year later on March 14, 2007, while the last "final build" was 3 years later on January 27, 2009.

 

Also as Atari itself showed with Ms. Pac Man(8K) and Jr. Pac Man (16K + extra RAM) that more resources can compensate for lack of time.

Edited June 15, 2012 by SpiceWare

[Crazy Climber]

Lots of people have complained that VCS Pac Man was a poor programming job, and do you tell them to "program" a better version?

That would be rather pointless since several have been made, why tell someone to re-invent the wheel..

AFAIK a better Q*bert has not been made, and since you think it is so easy to do and the PB release was just "lazy programming" we say "Prove it"

[Dauber]

FWIW, I got the VCS Q*Bert the first Christmas after it came out...and I NEVER noticed a gap until this thread pointed it out. Ergo, was never distracted.

[Joe Musashi]

One thing that is being underestimated about the Q*Bert kernel is that it needs to perform mid-line color changes. Admittedly, only for the colored tops of the cubes, but the symmetry problem applies here as well.

 

In the last row of cube tops, the kernel does six writes to the playfield color register, three writes to PF0,PF1,PF2, plus one to GRP1 for the player sprite. These are 10 (!) TIA updates per line. To do this, a "cyclic" sub-kernel is used that takes 76 cycles without using WSYNC. There are a few spare cycles left, but definitely not enough to do a full asymmetric playfield.

 

The whole display kernel is composed of many sub-kernels that draw the different parts of the pyramid. To me this looks like a very advanced kernel, and by no means the programmers were lazy.

[BillyHW]

One thing that is being underestimated about the Q*Bert kernel is that it needs to perform mid-line color changes. Admittedly, only for the colored tops of the cubes, but the symmetry problem applies here as well.

 

In the last row of cube tops, the kernel does six writes to the playfield color register, three writes to PF0,PF1,PF2, plus one to GRP1 for the player sprite. These are 10 (!) TIA updates per line. To do this, a "cyclic" sub-kernel is used that takes 76 cycles without using WSYNC. There are a few spare cycles left, but definitely not enough to do a full asymmetric playfield.

 

The whole display kernel is composed of many sub-kernels that draw the different parts of the pyramid. To me this looks like a very advanced kernel, and by no means the programmers were lazy.

 

It sounds like the programmers were trying to get the most that they could out of this 1st gen system.

[WSGEXE]

I love the title of this thread for some reason. It's like a Zen kōan or something. Q*bert, why the divided cubes?

[+SpiceWare]

In the last row of cube tops, the kernel does six writes to the playfield color register, three writes to PF0,PF1,PF2, plus one to GRP1 for the player sprite. These are 10 (!) TIA updates per line. To do this, a "cyclic" sub-kernel is used that takes 76 cycles without using WSYNC. There are a few spare cycles left, but definitely not enough to do a full asymmetric playfield.

 

Impressive

 

Kernel loops w/out WSYNC are definitely not signs of "a lazy programmer" - it's the sign of a programmer who's pushing the 2600 to its limits.

 

That would also partially explain why they dropped the bottom row of 7 blocks from the 2600 version, as why as well the enemy "hover" above the blocks instead of standing on them like Q*bert does.

 

The other reason there's not 7 blocks is they wouldn't fit. Each block is 5 PF pixels wide(so it can be drawn with a "point" at the bottom), with 1 PF pixel spacing between each block (and that gap is required in order to change the PF color - I'm familiar with that from how I did the kings in Medieval Mayhem). So 7 blocks with 6 spaces = 7 * 5 + 6 = 41, 1 PF pixel too many. The blocks wouldn't look like blocks if drawn with 4, so the next smallest would have to be 3, which would result in a game using only 2/3 of the screen width - I can just imagine the complaints we'd see about that

Edited June 16, 2012 by SpiceWare

[SeaGtGruff]

This thread got me playing Q*bert again for the first time in years (decades?). It's definitely one of those games that's easy yet deceptively hard at the same time, which makes a game more addictive-- whenever you get killed (lose your last life) you just *have* to play it again because you just *know* you can do better.

 

Two things I noticed while playing it are that the score rolls over at 99999, and it looks like the non-player sprites always follow the same patterns (at least in Stella)-- except of course for Coily when he's chasing Q*bert. I may have known this when I played Q*bert back in the day, but if so I'd forgotten about it.