Qix

[+atari2600land]

Correct me if I'm wrong, but I believe Qix is doable on the 2600. Of course, the game will have to look different, but the gameplay I believe could be the same. The playfield will be used as the board, and with 200 free spaces, you could divide the score by 2 to find out the %age of the board you've cleared. I wish I could do this, but I don't have the programming skills to do this, so if anyone else wants Qix on the 2600, maybe someone will actually do this (I'm wishing for a Ballblazer-type scenario here, although that's pretty rare.) I've made a mockup picture using bB. I think the game could be done using bB, and if someone else wants to attempt it using bB, that's fine, but one done in normal assembly code would be cool, too. In this mockup, missile0 is the cursor. Everything else is pretty much self-explanitory.

Edited December 29, 2008 by atari2600land

[ginnidog]

Funny you post this..i was working on a Title Sprite for this game... small world

 

I think its possible... this was a great game for other systems

 

Paulie

 

[ginnidog]

quick Title screen i made

 

 

enjoy

 

[iwan-iwanowitsch-goratschin]

I did love to play Qix on my ancient Game Boy!

[AtariLeaf]

I play the XL version often. Fun game, if a little sluggish.

[Thomas Jentzsch]

IIRC there had been some in depth discussion about Qix at AA a few years ago.

[Robert M]

IIRC there had been some in depth discussion about Qix at AA a few years ago.

Previous Qix discussion thread.

[ZylonBane]

I don't know what you people are going on about. I think the 2600 version of Qix is great!

 

[+Propane13]

Is it April 1 already??

 

Where did you get that? If it's a mockup, it's a helluva mockup!

 

-John

[Kurt_Woloch]

Uhm... yes. The problem about this mockup is that to store that kind of playfield, you'd need more RAM than the 2600 can provide, although the resolution is already considerably reduced compared to the arcade version.

Let's see... We've got 40 horizontal "blocks" of playfield (each of which is 4 scanlines high in that mockup) and 30 vertical ones. And you have 2 possible colors in which the playfield can be filled plus a third color which denotes the lines laid down by the player. So that's 2 bits per block, which actually corresponds nicely to the 4 bytes of playfield you have to fill in each line. So, you'd need at least 30x40x2 bits, that is 2400 bits or 300 bytes to store the playfield. Unfortunately, the 2600 only has got 128 bytes of RAM, so this mockup isn't possible unless you put at least 256 bytes of additional RAM into the cartridge.

Edited January 6, 2009 by Kurt_Woloch

[Retrofan]

Another Mockup (click for animation):

[Kurt_Woloch]

Another Mockup (click for animation):

 

OK... here we have an area of 20x34 blocks... and only colored in 1 color, so we only need 680 bits, which would be 85 bytes... looks more doable to me, except for the digits on bottom... I don't think it's possible to put 3 digits next to each other, and another 4 on the same scanline. Maybe if you could use 3-pixel wide digits, it might work. And then there's the question how you're going to do the green line that marks the line the player has just drawn...

[Retrofan]

OK... here we have an area of 20x34 blocks... and only colored in 1 color, so we only need 680 bits, which would be 85 bytes... looks more doable to me, except for the digits on bottom... I don't think it's possible to put 3 digits next to each other, and another 4 on the same scanline. Maybe if you could use 3-pixel wide digits, it might work.

Or we use the Space Invaders trick with the alternating lines

 

And then there's the question how you're going to do the green line that marks the line the player has just drawn...

I think there must be a possiblity to do this in the way Missile Command or Etch-a-Sketch draw lines. Is it a player sprite? The Idea is, that the area will be filled with PF graphics if you reach the end (and the line disappears). When yo do not draw a line, your player is a dot like the enemies.

[jrok]

And then there's the question how you're going to do the green line that marks the line the player has just drawn...

 

I'm a little unclear why everyone seems to think ithat the "slice" line needs to be a single pixel vector. Wouldn't it be much simpler to just draw this path with the pfpixels, (a la sssnake and "tron light cycles") and call it a day? If we are worried about the detoriorated look, we could make up for it with another visual device, like changing the color of the entire playfield as it gets closer to completion.

 

Edited January 6, 2009 by jrok

[jrok]

And then there's the question how you're going to do the green line that marks the line the player has just drawn...

I think there must be a possiblity to do this in the way Missile Command or Etch-a-Sketch draw lines. Is it a player sprite? The Idea is, that the area will be filled with PF graphics if you reach the end (and the line disappears). When yo do not draw a line, your player is a dot like the enemies.

 

If I'm not mistaken, aren't the lines in missile command only possible because they have vertical trajectories - ie. they are limited in the number that can be drawn on the same horizontal line (to three per line, I think)?

Edited January 6, 2009 by jrok

[jrok]

Actually, maybe we could even spare the use of a missile in that setup. Instead of using a graphic to represent the player, we could simply flip the pixel behind the "lead" pixel. That way, when the player is slicing or tracing the edge of a completed shape, he could gauge his position with a black pfpixel.

 

[Thomas Jentzsch]

If I'm not mistaken, aren't the lines in missile command only possible because they have vertical trajectories - ie. they are limited in the number that can be drawn on the same horizontal line (to three per line, I think)?

Yup.

 

You can draw one pixel/object/line without problems (5 objects in total). For more pixel it becomes more complicated and less flexible.

[jrok]

If I'm not mistaken, aren't the lines in missile command only possible because they have vertical trajectories - ie. they are limited in the number that can be drawn on the same horizontal line (to three per line, I think)?

Yup.

 

You can draw one pixel/object/line without problems (5 objects in total). For more pixel it becomes more complicated and less flexible.

 

That said, what do you think would be a good way to approach drawing a seamless "dynamic" horizontal line without using the playfield pixels? What about a sprite shape that incremented from $00000000 to $11111111 while alternating between NUSIZx = $5 and NUSIZx = $7 until it reached 32px wide? With 20hz flicker, could you then get something approaching a transversal, single-pixel line?

[Thomas Jentzsch]

That said, what do you think would be a good way to approach drawing a seamless "dynamic" horizontal line without using the playfield pixels? What about a sprite shape that incremented from $00000000 to $11111111 while alternating between NUSIZx = $5 and NUSIZx = $7 until it reached 32px wide? With 20hz flicker, could you then get something approaching a transversal, single-pixel line?

All that flicker just for a line which is only virtual for gameplay?

[jrok]

That said, what do you think would be a good way to approach drawing a seamless "dynamic" horizontal line without using the playfield pixels? What about a sprite shape that incremented from $00000000 to $11111111 while alternating between NUSIZx = $5 and NUSIZx = $7 until it reached 32px wide? With 20hz flicker, could you then get something approaching a transversal, single-pixel line?

All that flicker just for a line which is only virtual for gameplay?

 

 

Well, no, I was just suggesting it as a thought experiment. As I said above, using the playfield pixels for drawing both lines and completed shapes seems to me like the most efficient way to get the job done. Qix was a pretty game to watch in the arcade thanks to the minimalist vector display, but its got to be the gameplay we are hunting here.

[Retrofan]

Updated Mockup. Less lines for the Qix so it looks a little bit more like the original. Stripes for the PF graphics so it looks more vectorized.

(click for animation)

[CV Gus]

Funny about this post- I was just wondering what a CV version of Qix would look like.

 

Since no more than two colors can be shown on a single 8-pixel line/space, I would assume that the little marker would have to move at 1/2 space at a time (horizontally). Since you'd want to keep the extreme edges clear (they disappear off the sides on many older televisions), your marker would move about 60 times from the left to the right, although vertically could be more liberal.

Edited January 6, 2009 by CV Gus

[ZylonBane]

so this mockup isn't possible unless you put at least 256 bytes of additional RAM into the cartridge.

Well darn, if only it weren't impossible to add RAM to the cartridge.

[Godzilla]

so where can we download the rom for that awesome 2600 qix zylon posted? That is a great looking mockup, btw.

[Jess Ragan]

I say screw the RAM limit... that's why they invented the SuperCharger!