Q*bert, why the divided cubes?

[sqoon]

Just what it says, why did VCS Q*bert have a noticeable gap down the middle of the play field? Was this an issue with Parker Bros. programmers being careless? Was it needed, or could Q*bert have been done without the divided play field??

[moycon]

Heh, You know I've always wondered this myself.

[KevinMos3]

Hmm, the divide is because of the reflected playfield, but I'm not sure how the center cubes were done. Nukey or RevEng would be good ones to answer this, since they've both worked with the code. RevEng added a nice title screen in the 2600 hacks forum.

 

Screenshots (Original | Mockup if PF reflected without gap | Mockup with no reflect PF)

 

I wonder if someone could hack it to use a non-reflected playfield and achieve the nice tight cubes...

I'm sure that would be a difficult undertaking.

Edited June 13, 2012 by KevinMos3

[RevEng]

Hmm, the divide is because of the reflected playfield, but I'm not sure how the center cubes were done.

 

Yup, In a nutshell, Q*bert uses a reflected playfield and the gaps to lessen the amount of cycles it would otherwise take to draw a perfect pyramid.

 

The 2600 playfield only has registers to cover the first half of each line, and the second half can either be a repeat or reflection of the first half. To draw something different on the second half, you need to update the registers as the screen is being drawn, which takes up kernel time that could otherwise be spent drawing players, missiles, etc.

 

Consider the Q*bert pyramid with regard to the playfield PF0, PF1, and PF2 registers...

 

 

...with the gaps in place, you can see that PF0 on the left is a perfect reflection of PF0 on the right, and the same is true for PF1. The only playfield pixels that aren't symmetric are those under PF2, so only PF2 needs to be updated as the display is being drawn.

 

To draw a perfect pyramid (by updating all playfield registers on the fly) and maintain the existing single-line resolution, the kernel would likely need to be changed into something more exotic - like adding in support for DPC, DPC+, etc.

 

Certainly it would take a lot more than a simple graphics hack.

[sqoon]

That does not explain why the programmers did not mirror PF2 just as they did with PF0 and PF1. This would have resulted in only one noticeable gap directly down the exact center of the play field, and had the programmers started PF0 zone with the pixels nudged slightly more toward screen center, then a perfect pyramid could have been easily achievable. It definitely points to lazy programming by Parker Bros.

[+SpiceWare]

a perfect pyramid could have been easily achievable. It definitely points to lazy programming by Parker Bros.

easily achievable and Atari VCS programming are mutually exclusive. If you think it can be easily achieved, then prove it - show us your code, we're waiting.

[Pioneer4x4]

What I hated about that game is the 3D effect is blown by wrong shading on ½ the screen, (and the size of the pyramid is different than the arcade by 1 row) Now that I have learned a lot about how limited the 2600 is, I think it is actually a decent port all things considered.

[RevEng]

That does not explain why the programmers did not mirror PF2 just as they did with PF0 and PF1. This would have resulted in only one noticeable gap directly down the exact center of the play field, and had the programmers started PF0 zone with the pixels nudged slightly more toward screen center, then a perfect pyramid could have been easily achievable. It definitely points to lazy programming by Parker Bros.

 

Look at PF2 in my screenshot. If it was mirrored then none of the center blocks would be shaded and they'd be too wide, and we'd have a thread asking why the center blocks are screwed-up in Q*bert.

 

Considering the complex display requirements for Q*bert and the limitations of the 2600, Dave Hampton made some very clever trade-offs for Q*bert 2600. The last thing I'd call him would be lazy.

[KevinMos3]

What I hated about that game is the 3D effect is blown by wrong shading on ½ the screen, (and the size of the pyramid is different than the arcade by 1 row)...

 

I never even noticed this until you pointed it out just now!

 

...Dave Hampton made some very clever trade-offs for Q*bert 2600. The last thing I'd call him would be lazy.

 

Agreed. I always thought Q*bert on the 2600 looked amazing. To me, it was a graphical showcase... and Q*bert moves so smooth! The only thing I always wanted to change was the lift pads. I wanted them to be ovals instead of flat lines. Now that I know more about the 2600 display, I understand why they're like that, (but I'd still like ovals, hehe).

[Rex Dart]

What I hated about that game is the 3D effect is blown by wrong shading on ½ the screen, (and the size of the pyramid is different than the arcade by 1 row) Now that I have learned a lot about how limited the 2600 is, I think it is actually a decent port all things considered.

 

Pretend there's a separate spotlight shining on each side of the tower, lighting both sides. It's a feature!

[Pioneer4x4]

 

Pretend there's a separate spotlight shining on each side of the tower, lighting both sides. It's a feature!

I LIKE IT! Maybe I'll try to hack it so both sides of the cubes are blank, play like a dark level. I guess I need to revisit this, I was such a fan of the arcade, I never got past the 2600 ports differences.

[Crazy Climber]

a perfect pyramid could have been easily achievable. It definitely points to lazy programming by Parker Bros.

easily achievable and Atari VCS programming are mutually exclusive. If you think it can be easily achieved, then prove it - show us your code, we're waiting.

I always get a kick out of people saying something is easy when they obviously have no idea what they are talking about...unless sqoon is actually a VCS programmer and in that case I will second your "prove it" notion

[Tempest]

a perfect pyramid could have been easily achievable. It definitely points to lazy programming by Parker Bros.

easily achievable and Atari VCS programming are mutually exclusive. If you think it can be easily achieved, then prove it - show us your code, we're waiting.

I always get a kick out of people saying something is easy when they obviously have no idea what they are talking about...unless sqoon is actually a VCS programmer and in that case I will second your "prove it" notion

Also keep in mind that back then programmers were under deadlines to get things done. Today homebrew authors have the luxury to take as long as they need to program a game, but back then most games had a 3-5 month development cycle. So even if something was 'easy to fix' that doesn't mean they had the time to do it.

[Torr]

a perfect pyramid could have been easily achievable. It definitely points to lazy programming by Parker Bros.

easily achievable and Atari VCS programming are mutually exclusive. If you think it can be easily achieved, then prove it - show us your code, we're waiting.

I always get a kick out of people saying something is easy when they obviously have no idea what they are talking about...unless sqoon is actually a VCS programmer and in that case I will second your "prove it" notion

 

Just like the guy making the Knight Rider game. They think a systems power only controls the resolution of graphics, not how they're controlled, how much can be controlled, where they can be, etc, etc....

[galbyman]

I always wondered about that as a kid.

[sqoon]

For all the 'prove it' and 'let's see you program better" crowd, I see the VCS Q*bert port as no less a shortcoming than Pac Man. Lots of people have complained that VCS Pac Man was a poor programming job, and do you tell them to "program" a better version? To me, the huge gap down the middle of the play field is no less a distraction than the different maze and pale ghosts in VCS Pac Man. It looks like either a rush job (the reason given often for Pac Man), or sloppy programming, along with with the previously mentioned lines for discs and 3d cube shading gone amiss. VCS has many games that use the rainbow effect. If anything, Q*bert could have used two ovals with scrolling rainbow effect to better approximate the spinning discs of the arcade version.

[Tempest]

For all the 'prove it' and 'let's see you program better" crowd, I see the VCS Q*bert port as no less a shortcoming than Pac Man. Lots of people have complained that VCS Pac Man was a poor programming job, and do you tell them to "program" a better version? To me, the huge gap down the middle of the play field is no less a distraction than the different maze and pale ghosts in VCS Pac Man. It looks like either a rush job (the reason given often for Pac Man), or sloppy programming, along with with the previously mentioned lines for discs and 3d cube shading gone amiss. VCS has many games that use the rainbow effect. If anything, Q*bert could have used two ovals with scrolling rainbow effect to better approximate the spinning discs of the arcade version.

I'd quit while you're ahead.

[+atari2600land]

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

[BillyHW]

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.

[R.Cade]

I really like Q*Bert- the gameplay is fun... I would say it would be nicer if there were more of the enemies- it is kind of sparse.

The playfield looked really good to me for the 2600.

Edited June 15, 2012 by R.Cade

[sqoon]

I'd quit while you're ahead.

 

I get a warning for that?!

[Omegamatrix]

That does not explain why the programmers did not mirror PF2 just as they did with PF0 and PF1. This would have resulted in only one noticeable gap directly down the exact center of the play field, and had the programmers started PF0 zone with the pixels nudged slightly more toward screen center, then a perfect pyramid could have been easily achievable. It definitely points to lazy programming by Parker Bros.

 

 

I don't understand this post. 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.

 

 

I would not say the programmer was lazy. I think it is a damn good game for being done back in the day. Sure it could have been done better, but back then it was magnitudes harder to program for the 2600. It's unfair to say the programmer was lazy.

[CPUWIZ]

I'd quit while you're ahead.

 

I get a warning for that?!

 

It probably has to do with the fact that someone put you on mod-preview for a while before. It was lifted, should it be put back?

 

How about you write a kernel that does what you call easy? PUOSU

[Pioneer4x4]

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.

I'd like to try that one, like you said, it has all of the rows. Gameplay could be better, even if the graphics aren't, and isn't that the whole appeal of the 2600? Personally I play Rabbit Transit, even though it barely compares.

[RevEng]

It looks like either a rush job (the reason given often for Pac Man), or sloppy programming, along with with the previously mentioned lines for discs and 3d cube shading gone amiss. VCS has many games that use the rainbow effect. If anything, Q*bert could have used two ovals with scrolling rainbow effect to better approximate the spinning discs of the arcade version.

 

You have no idea what it takes to program that display, and yet you assume the imperfections are due to sloppiness or laziness; that's sheer hubris.

 

Q*bert was made with compromises, just like any other 2600 port. The fact that it looks as good as it does on a pong and tank machine is quite impressive!