Get your Qix?

[+atari2600land]

Don't get all excited just yet. This little program is just an idea and isn't playable, but I think if someone were to expand on my very little beginning, Qix could be do-able with Batari BASIC. By making the playfield 200 squares big, you could just divide the number of squares cleared by 2 to make it part of a 100% total (shown in the score). The thing that makes the lines could be manipulated in a Nibbles-like fashion until it gets to a side, created by the player or not (maybe?) with the player0 sprite leading the way. The Qix (player1) might be moved randomly (I don't know how), and could double in later rounds and even triple with the NUSIZ1 thing. I wish I could do this, but I just started BASIC programming a couple months ago and I don't have the capability yet. Maybe when someone gets done with a project, they could work on this, because I think it would be cool to have Qix be on Batari BASIC. To get past the funky title screen, press reset.

qix.bas.bin

qix.bas

[Atariboy2600]

Don't get all excited just yet. This little program is just an idea and isn't playable, but I think if someone were to expand on my very little beginning, Qix could be do-able with Batari BASIC. By making the playfield 200 squares big, you could just divide the number of squares cleared by 2 to make it part of a 100% total (shown in the score). The thing that makes the lines could be manipulated in a Nibbles-like fashion until it gets to a side, created by the player or not (maybe?) with the player0 sprite leading the way. The Qix (player1) might be moved randomly (I don't know how), and could double in later rounds and even triple with the NUSIZ1 thing. I wish I could do this, but I just started BASIC programming a couple months ago and I don't have the capability yet. Maybe when someone gets done with a project, they could work on this, because I think it would be cool to have Qix be on Batari BASIC. To get past the funky title screen, press reset.

 

Any screenshots?

[+atari2600land]

Any screenshots?

This is all it does, sans title screen.

[+atari2600land]

Sorry to necropost yet again, but I thought I'd give this another try. Unfortunately, my code is a mess. What I want to do is when the line is moving by itself, once it meets a line already there to stop and then fill in the space where the Qix (little green thing) isn't. I think to get the space filled where the Qix isn't is making the computer guess where it is (for example, 1 to m), and if that space is filled, then undo the fill in and fill in the other side, very quickly so the player will barely notice it if it's wrong.

qix.bas.bin

qix.bas

Edited November 12, 2007 by atari2600land

[+atari2600land]

Here's a little-less buggy version. I still need help with the above things mentioned, though.

qix2.bas.bin

qix2.bas

[lucifershalo]

Here's a little-less buggy version. I still need help with the above things mentioned, though.

 

promising

[Fort Apocalypse]

Here's a little-less buggy version. I still need help with the above things mentioned, though.

 

Looks good. I can't think of an easy way to fill in the areas unfortunately.

 

If you had to rate the difficulty of getting something similar enough to Qix to call it Qix implemented in bB, I'd give it a 12 out of 10.

 

The right way to fill in the blocks is to have the application smart enough to determine what the smallest area is to fill the blocks in is after you complete a line.

 

A possible way of filling the blocks if it wasn't that smart is to use the variables to store the last direction the player moved since starting a line. Then as soon as the player hits the playfield, it uses those directions to determine how to retrace the line but move it over +1 x/y coordinate at a time (depending on the last move) and then do pfread to "stop" painting the shape when it hits a line.

 

Another way is to register the starting point of the line (as x,y variables) and then paint straight across when you complete the line, starting with those coordinates and doing pfpixel across (+1 x if x>16 or -1 x if x<=16 for example) until you hit a block then start at the same starting x again and paint across. Or you could track the x coordinate of every dot in the line and draw over from that.

 

But neither of those ways will probably do it.

 

It will be tough, and probably is not what you want to take on (hard games to write can sometimes be demotivating).

Edited November 13, 2007 by Fort Apocalypse

[+Gemintronic]

I got an IDE for Batari installed once.. that's my knowledge of programming in it

 

That being said, why not think of the Qix monster as 2 sprites. Those 2 sprites would stay within a certain distance of each other and each would have its own collision check. A bullet sprite could traverse the distance between them and kinda sorta resemble a line between the 2 main sprites.

 

The only trouble I see is making a good fill algorithm for when you complete a line. I don't even have a clue how to fathom that.

 

EDITED: For spelling and additional description.

Edited November 14, 2007 by theloon

[Fort Apocalypse]

I had another idea on this yesterday. Maybe you could just register the running average of x and y coordinates (each move you recalculate the average by also keeping track of the number of dots drawn) and also keep track of the starting and ending x,y coordinates. With that information you may be able to figure out the "centerpoint" to determine area. An easier way would be to just assume that the greatest x-1 and least y-1 is a fill point and fill by drawing each line left until you run into something. The latter wouldn't work well though. Just guessing. No answer yet.

[A Sprite]

I had another idea on this yesterday. Maybe you could just register the running average of x and y coordinates (each move you recalculate the average by also keeping track of the number of dots drawn) and also keep track of the starting and ending x,y coordinates. With that information you may be able to figure out the "centerpoint" to determine area. An easier way would be to just assume that the greatest x-1 and least y-1 is a fill point and fill by drawing each line left until you run into something. The latter wouldn't work well though. Just guessing. No answer yet.

 

Forgive me if this is retarded, or much, much, worse, but could the lines be filled in, sonar style? Say if there's a block in the way, bounce backwards, and if there's no opening, move down one line, repeat process, until blocked and bounced back upwards. If the scan returns to it's starting coordinates without finding an escape, it marks all squares inside the area as claimed territory, then counts the number of squares as .5 points each, to create the percentage.

[+atari2600land]

If I made the playfield 200 pfblocks, then I could just divide the # of pfblocks filled in by 2 to get a %. This is what I did in this next version. Also, the automatic line stops once you reach a playfield block, whether it be the border or not and adds the %age to the score (the 5th figure should be a '%', I just haven't gotten around to making it yet.

qix6.bas.bin

qix6.bas

[gambler172]

Hi Chris

Keep on the good working on this.

greetings Walter

[+atari2600land]

Necroposting! Oh no!

I've come up with a cross between Qix and Jezzball. This is still buggy, but it gives a good idea of what I want to do with the Qix concept.

qix.bas.bin

qix.bas

[miker]

No new version(s) to get?

[+atari2600land]

I've tried this again, but need some help with math issues. I've commented the part I'm having trouble on (starting at line 101). If I could just get this part figured out, I can continue working on this.

qix2600.bas

qix2600.bas.bin

[+atari2600land]

OK, I've worked on this for a few more hours, but there are some restrictions: you can only make a straight line, no jagged ones. Let me know if you find any bugs or if it's not playable on real hardware.

qixster1.bas.bin

qixster1.bas

[gambler172]

Hi Chris

Looks pretty well

greetings Walter

[+atari2600land]

Here is a version with a moving ball in the center of the screen. If you're making a line and the ball touches it, the game resets. You can also reset the game by pressing the reset button.

qixster2.bas.bin

qixster2.bas

[Nateo]

Just tried this one out - you could really be on to something here! Concerning the inability to turn a corner mid-line, maybe you could make it more like Jezz Ball? It's certainly very Qix-like. Anyway, great work!

[+atari2600land]

Thanks. I've updated the score, and it seems to not be working right. Is there ANY way I can get the value of player0score to help in adding to the score, i.e. bonuses)? Because this is not working:

x=(player0score-$55)+100
score=score+x

qixster5.bas.bin

qixster5.bas

[+atari2600land]

I meant that to be TIMES 100. I may have found a new thing to worry about, though: Try to compile this code. It will spit out an unresolved symbol called "Areg" Anyone have any idea as to what this is?

qixster6.bas

[+RevEng]

Strangely, it compiled just fine for me. I didn't make any changes to the source, but I am using a recent beta of bB.

 

qixster6.bas.bin

[+atari2600land]

I couldn't find the score kernel that gives you two two digit scores. I searched everything imaginable. So I had to settle with one four digit score and one two digit score. The two digit score is the % of the board filled while the four digit score is, well, the score. To start a new round, press fire.

qixster6.bas

qixster6.bas.bin

[+Random Terrain]

I couldn't find the score kernel that gives you two two digit scores. I searched everything imaginable. So I had to settle with one four digit score and one two digit score.

 

Is this what you were looking for?

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#playerscores_minikernel

[+atari2600land]

Yes. Now I have a problem. Suppose I want to add a 100 point bonus when the board is cleared for every point over 85. How would I do that? The bonus code I have done (that doesn't work) starts at line 222.

qixster8.bas