qix

[Thomas Jentzsch]

quote:

---

Originally posted by Channel 2:

I don't know Qix, but I was pretty good at Jezzball at one time. How is Qix different from Jezzball?

---

Qix is a little bit more complex. You don't have a free cursor, but you can move it along the borders.

You draw a border around the area, you want to take. This can be of any shape. While you draw it, you are vulnerable.

The enemies are not partikels but a (what I call it) "Linemonster" (a bunch of lines) that moves around in a more or less unpredictable way. And some dots that follow your paths.

[Cybergoth]

The problem is, that the whole filled areas had to flicker. And that is very annoying.

 

Yes, you could try to reduce that with mixing playfield and player graphics, but that makes the kernel extremely complicated (or impossible) and requires some rather complicated setup code for the kernel too.

 

In the end, I didn't find a solution to do it that way.

 

Now, since we're close to the fifth anniversary of this post, did you find a solution for Qix by now?

[keilbaca]

>_> what's with all the necroposting?

[Thomas Jentzsch]

Now, since we're close to the fifth anniversary of this post, did you find a solution for Qix by now?

Nope.

[Foxsolo2000]

Pity

[Robert M]

Alright, I did some thinking on this problem a year or so ago. I was going to replace Qix with Blocko, as drawn wonderfully for me by Saldsadt.

 

Anywho, I did some rough planning and I think it might work. I will try to descibe my ideas with words.

 

The player is restricted to moving on a grid 4 pixels wide (1 PF pixel) and 8 scanlines high. Only the middle 32 PF pixels are used. The player moves on the lines between these larger pixel blocks. If we assign 160 scanlines for vertical playfield space, we get a rough grid of 32 by 20 squares, or 640 squares total. 640 squares needs 640 bits to store, 640 / 8 = 80 bytes. If we want to have 2 fill colors per pixel we need 2 bits, or 160 bytes, which means a SARA chip is required. OR, we can reduce the play area by removing 8x8 blocks of gameboard pixels to make non-rectanglar play areas. If we remove 4 such blocks of 64 pixels we get 640 - (4*64) = 384 pixels / 8 = 48 bytes * 2 = 96 bytes + a few overhead bytes to indicate which 8x8 blocks are solid, and we fit into 128 bytes with a 4 color PF. The 4 colors are made by mixing 2 PF colors on alternate lines. For example: Black background, plus alternating yellow and blue yields (Black+Black) = Black; Black + Blue = Blue, Black + Yellow = Yellow; Yellow + Blue = Green.

 

The enemies are Blocko and 2 sparx. Blocko is P1 + Ball flickered at 30Hz for the eyes. The sparx are M1 flickered at 30 Hz. The player is P0 and P1. The player and sparx travel on the lines "between" the larger playfield pixels. Say 2 pixels wide with 1 pixel overlapping a PF pixel on each side.

 

The drawing by the player does not make continuous lines, but only leaves marks at the corners where the player changes direction. P0 and M0 can be used to draw little "L" shapes to mark the corners. They are repositioned in the middle of the 8 scanline blocks to get multiple instances in a frame. Flickering is used when more than 2 "L" shapes share a horizontal line.

 

Most likely a SARA chip would be needed to make the game doable and enjoyable.

 

Cheers!

[supercat]

Alright, I did some thinking on this problem a year or so ago. I was going to replace Qix with Blocko, as drawn wonderfully for me by Saldsadt.

 

Sounds like that might be workable. Use an even/odd scan line playfield scheme to get 4 colors.

[Cybergoth]

Sounds really like a good plan. You're a very rare participant in the scene lately Robert, I hope all is well with you?

 

Regarding Qix, I'm currently just toying with the idea of trying the whole game just as lores as the playfield permits, ie. drawing 1 PF pixel wide and 6 scanlines high lines. Have a look at Maze Craze to get an idea of the resolution. Or consider a free-movement version of Amidar

[Robert M]

Sounds really like a good plan. You're a very rare participant in the scene lately Robert, I hope all is well with you?

 

Regarding Qix, I'm currently just toying with the idea of trying the whole game just as lores as the playfield permits, ie. drawing 1 PF pixel wide and 6 scanlines high lines. Have a look at Maze Craze to get an idea of the resolution. Or consider a free-movement version of Amidar

 

Hi, I am doing alright. I have just been very busy this past year. I visit AA and lurk about nearly every day though, and I have all my projects progressing in slow motion in the background.

 

Cheers!

[bomberpunk]

here's an idea for a 2600 qix development:

http://vgdb.vectrex.com/vec.pl?vgdbcode=VGDB181

 

just go with Christopher Tumber's Vectrex-brewed VIX and erase claimed territory.

[Cybergoth]

Interesting idea! Thanks!

[Thomas Jentzsch]

Another one: http://www.addictinggames.com/pacxon.html

[Cybergoth]

Another one: http://www.addictinggames.com/pacxon.html

 

I figured that doing solid playfield would be the non-SC way to go a while ago, if only because of RAM usage. Remember the mock-up that Zylonbane once posted? It'd require easily 256 bytes just for the playfield alone.

 

But with a solid (& blocky) playfield, you can store a screen in 128 bytes, thus a sara version would be doable. The game in the link you provided would be pretty close to what you'd get then, playfield wise. Of course you could make the whole rest a lot Qixier

 

Anyone have an opinion wether such a version of Qix 2600 would be acceptable? (Heh, if I don't forget I can make that the Homebrew poll for feb. )

[vdub_bobby]

Another one: http://www.addictinggames.com/pacxon.html

 

I figured that doing solid playfield would be the non-SC way to go a while ago, if only because of RAM usage. Remember the mock-up that Zylonbane once posted? It'd require easily 256 bytes just for the playfield alone.

 

But with a solid (& blocky) playfield, you can store a screen in 128 bytes, thus a sara version would be doable. The game in the link you provided would be pretty close to what you'd get then, playfield wise. Of course you could make the whole rest a lot Qixier

 

Anyone have an opinion wether such a version of Qix 2600 would be acceptable? (Heh, if I don't forget I can make that the Homebrew poll for feb. )

If you have enough squares I think that would be fine, like say 40x30 or so.

[supercat]

If you have enough squares I think that would be fine, like say 40x30 or so.

 

A 32x16 four-color bitmap would require 128 bytes. Increasing that to 32x24 would require 192 bytes. Although it would be possible to fit 192 bytes into RAM using a SuperChip cartridge, that would probably leave everything else rather too tight to do much good. Perhaps 32x20 would be a good compromise (160 bytes).

 

Drawing the QIX using playfield graphics would look just plain horrible--no two ways around it. Using flicker, it might be possible to work out something decent looking, though I don't know if there'd be enough CPU time to pull everything off.

 

Since the Sparx are limited to travelling along the lines, they could use the Ball (set COLUPF to zero and stripe COLUBK cyan and brown; the sparx would be black objects on the white lines). The marker would be one player sprite. The QIX would be the missile corresponding to that player sprite, combined with the other player and its missile; flicker those at 30Hz to show six bouncy lines for the QIX.

 

Hmm.... interesting notion. I wonder if it could work?

[bomberpunk]

i don't know all the technical ball missle sprite player1 stuff, but i would say if anything has to be sacrificed, it should be the look of the playfield rather than any of the bells and whistles that make qix... well, qix.

[supercat]

i don't know all the technical ball missle sprite player1 stuff, but i would say if anything has to be sacrificed, it should be the look of the playfield rather than any of the bells and whistles that make qix... well, qix.

 

Yeah, well I'm not sure how well the qix could be realized on the 2600. As a quick sketch of what needs to happen in a two-line kernel:

-- 7 cycles 8 reps  56 total
 lda bitmap*,x
 sta PF*

-- 32 cycles 3 reps 96 total
 lda slope*
 adc slopetemp
 sta slope*
 bcc slope*b
slope*b:
 lda HM0*b
 sta HM**
 lda NUSIZ*b
 sta NUSIZ*
 lda height*
 dcp vctr*
 
-- 5 cycles 2 reps 10 total
 lda #color
 sta COLUBK

Already up to 152 cycles, and there's still a lot of stuff still left to go in. No way the bouncy lines can be processed real-time by the kernel, at least not without a lot more RAM.

 

Still, if one is willing to have the enemy not look like a Qix, the game may be quite workable. In fact, if one is willing to restrict the player to moving two playfield bricks at a time, the game might even be possible without the SuperChip.

[Robert M]

There is a precedence for using a block sprite for Qix in place of the Qix composed of lines:

 

http://www.klov.com/game_detail.php?letter=&game_id=9933

 

and:

 

http://www.klov.com/game_detail.php?letter...p;game_id=10236

Edited January 25, 2007 by Robert M

[Thomas Jentzsch]

...i would say if anything has to be sacrificed, it should be the look of the playfield rather than any of the bells and whistles that make qix... well, qix.

But then you would have a completely unstructured area and some structure is important to the gameplay.

 

Minimal flicker, like John suggested, seems to be the only option here. A simple checkerboard pattern with limited hue differences would do.

[Lord Helmet]

I just have to say that watching all of you guys collabrate on ideas is really interesting. I learn more about the 2600 and what it can do be reading threads like these. It also encourages me to buy more of your games when they are completed.

[vdub_bobby]

I don't see why you couldn't have a QIX-looking QIX using a sprite.

 

P0 for marker.

P1 for QIX.

Flicker missiles for sparx (like mockup bees for 2600 Killer Bees conversion).

Flicker ball in same way for fuse.

Draw area/lines with playfield blocks like that Pac-Xon game linked above.

 

The tradeoff between getting a four-color bitmap and a larger playfield (40x30) is tough. The two-color play area isn't really necessary for the gameplay, but it sure looks nice. Having a larger play area would really help the game play, especially since the play area resolution is so low (since we're using playfield blocks).

 

I'd lean towards a two-color bitmap (background and foreground) and a bigger play area (40x25 to fit in 128 bytes, preferably bigger).

[Cybergoth]

If you have enough squares I think that would be fine, like say 40x30 or so.

 

A 32x16 four-color bitmap would require 128 bytes. Increasing that to 32x24 would require 192 bytes. Although it would be possible to fit 192 bytes into RAM using a SuperChip cartridge, that would probably leave everything else rather too tight to do much good. Perhaps 32x20 would be a good compromise (160 bytes).

 

I just thought of PF on-off, like in the Pacman demo. Then you get 40*25 into 128 Bytes. With 6 scanline tall blocks, that uses 150 scanlines, leaving 42 lines for state and score information.

 

@TJ: I kinda got sidetracked with the link you posted, but actually the idea from the Vectrex version perfectly solves your stella-sketch flicker problem

[Thomas Jentzsch]

@TJ: I kinda got sidetracked with the link you posted, but actually the idea from the Vectrex version perfectly solves your stella-sketch flicker problem

So you prefer a hi-res Supercharger version?

[Cybergoth]

@TJ: I kinda got sidetracked with the link you posted, but actually the idea from the Vectrex version perfectly solves your stella-sketch flicker problem

So you prefer a hi-res Supercharger version?

 

I neither prefer hi-res nor the SC (Do you think I got brainwashed? ), but was just trying to point out that this was actually the answer to your five year old problem

[Thomas Jentzsch]

Do you think I got brainwashed?

Never, that's why I added the

 

...but was just trying to point out that this was actually the answer to your five year old problem

Yes, indeed. Maybe John will pickup the idea.