ToobBin'

[+atari2600land]

In case you don't read my blogs, I decided to take a crack at creating Toobin' for bB. Here's what I have so far. I am having a problem, though. No matter how many different times I try, I can't seem to get an arrow going back and forth as an enemy. There may be no such thing in the actual game, but I thought an arrow (shot from an unseen bow) would cause danger to both you or your raft. So what I want to do is this:

 

+wait for a random time (1-10 seconds)

+once the time comes up, randomly choose what side the arrow comes from (and a random y position) and shoots.

+once the arrow clears the screen, repeat.

 

and I just can't seem to do this for some reason.

The arrow is already in the code as player1. It has to be the same color as the raft because the raft is missile1. The guy in the raft is player0. So help with this would be greatly appreciated. Here are some screenshots.

toobin3.bas.bin

toobin3.bas

[gambler172]

Hi Chris

Looks nice,so far.

greetings Walter

Edited May 8, 2008 by gambler172

[+Random Terrain]

Is it possible for you to place the two playfield pixels at the bottom, out of sight, and then use pfscroll up to scroll them up to the top? And then when the player pushes down, you could use one or more extra pfscroll ups to speed up the scrolling?

[+atari2600land]

Is it possible for you to place the two playfield pixels at the bottom, out of sight, and then use pfscroll up to scroll them up to the top? And then when the player pushes down, you could use one or more extra pfscroll ups to speed up the scrolling?

Your wish is my command. The only problem is that the screen size jitters. I don't know what to do about that.

toobin4.bas.bin

toobin4.bas

[+Random Terrain]

Is it possible for you to place the two playfield pixels at the bottom, out of sight, and then use pfscroll up to scroll them up to the top? And then when the player pushes down, you could use one or more extra pfscroll ups to speed up the scrolling?

 

Your wish is my command. The only problem is that the screen size jitters. I don't know what to do about that.

 

Thanks. To get rid of the jitter/bounce, you need this file:

 

www.atariage.com/forums/topic/118434-score-jitters/#entry1430601

 

I renamed the original file in my includes folder just in case and put this fixed version in there and no more jitter!

 

On another subject, I'm playing with your new code for practice and I might post something here later today. This is fun.

[+atari2600land]

And here is a binary file with no jitters. (and a new score font. I tried to make it like the Toobin font (balloon shaped), but I need someone to do a better job on some of the numbers ) Also, I nicened (is that a word?) the title screen to get rid of the random mess that showed up at the bottom after you lose all your lives.

toobin5.bas.bin

toobin5.bas

[+atari2600land]

Finished the title screen music and made the O's in "TOOBIN'" bounce around. I'm not very good at percussion in Atari 2600 music, so if it's annoying, tell me and I'll try and change it.

toobin6a.bas.bin

toobin6a.bas

[Shawn]

Finished the title screen music and made the O's in "TOOBIN'" bounce around. I'm not very good at percussion in Atari 2600 music, so if it's annoying, tell me and I'll try and change it.

 

 

this is goona be awesome! Gotta get rid of the up control though and I think it should move down on it's own but be able to make it move down faster with the the down direction. Also you gonna add things to grab and or spikes\obsticasls to run into? A finish line would be aces also. Nice work so far! I can see this being a great port!

[+atari2600land]

I'm trying to add deadly arrows that shoot across the screen, but I can't seem to get it working yet. I might have things (being player1) to grab for extra points when the arrows aren't on the screen. They'd have to be red things, though, because missile1 is the red raft.

[+atari2600land]

Arrows added (finally!) They're deadly, so avoid them by either going up or down. Next thing to do: figure out how to end level 1, and have an ending sequence for it.

toobin7.bas.bin

toobin7.bas

[gambler172]

Hi Chris

Nice ......I like it.

greetings Walter

[+Random Terrain]

I have a couple of questions/suggestions. Since pfscroll up takes care of the scrolling, seems like you wouldn't need this in your main loop:

 

	pfpixel g j on : pfpixel h k on

You could put it at the end of get_rock2x instead so it would only be used when needed. I tried it and it works fine.

 

Speaking of that rock section of code, here's what you have now:

 

get_rock1x
 w=0
 z{0}=0
 j=11
 g=rand

 if g<1 then goto get_rock1x
 if g>24 then goto get_rock1x
 
 if g<11 then goto g_0
 if g>10 then goto g_1
 if g>20 then goto g_2

g_0 
if g=1 then l=20
 if g=2 then l=24
 if g=3 then l=28
 if g=4 then l=32
 if g=5 then l=36
 if g=6 then l=40
 if g=7 then l=44
 if g=8 then l=48
 if g=9 then l=52
 if g=10 then l=56
 goto get_rock2x
 
g_1 
 if g=11 then l=60
 if g=12 then l=64
 if g=13 then l=68
 if g=14 then l=72
 if g=15 then l=76
 if g=16 then l=80
 if g=17 then l=84
 if g=18 then l=88
 if g=19 then l=92
 if g=20 then l=96
 goto get_rock2x
 
g_2 
 if g=21 then l=100
 if g=22 then l=104
 if g=23 then l=108
 if g=24 then l=112

get_rock2x
 k=11
 h=g+5
 pfclear
 m=l+20
 pfpixel g j on : pfpixel h k on
 goto main

Does that save more cycles than just doing this:

 

get_rock1x
 w=0
 z{0}=0
 j=11
 g=(rand&24)+1

 if g=1 then l=20
 if g=2 then l=24
 if g=3 then l=28
 if g=4 then l=32
 if g=5 then l=36
 if g=6 then l=40
 if g=7 then l=44
 if g=8 then l=48
 if g=9 then l=52
 if g=10 then l=56 
 if g=11 then l=60
 if g=12 then l=64
 if g=13 then l=68
 if g=14 then l=72
 if g=15 then l=76
 if g=16 then l=80
 if g=17 then l=84
 if g=18 then l=88
 if g=19 then l=92
 if g=20 then l=96 
 if g=21 then l=100
 if g=22 then l=104
 if g=23 then l=108
 if g=24 then l=112

 k=11
 h=g+5
 pfclear
 m=l+20
 pfpixel g j on : pfpixel h k on
 goto main

I'm still pretty new at this, so I don't know how many cycles are used for various things like if-then statements. Is it best to chop it up like you did? If it saves time, do you know how many if-then statements in a row is the limit before things start to slow down too much?

 

 

I think the following two if-then statements could be trimmed:

 

  if a>b && q<7 then a=0 : q=q+1 : pfpixel g j off : pfpixel h k off : pfscroll up
 if a>b && q=7 then q=0 : pfpixel g j off : pfpixel h k off : j=j-1 : k=k-1 : pfscroll up

Instead of that, I think you could just use this:

 

  if a>b && q<7 then a=0 : q=q+1 : pfscroll up
 if a>b && q=7 then q=0 : j=j-1 : k=k-1

I tried that and it seems to work without a problem. That pfpixel stuff didn't seem to be necessary and the extra pfscroll up didn't seem to be needed either.

 

Another thing I wandered is if you could test to see which side the guy is on and make sure the arrow comes from the opposite side. I've been on one side and had the arrow hit me without even a fraction of a second to react. If the arrow always comes from the opposite side, the player will have a chance to move.

 

That's all I have for now.

 

 

Thanks.

[+SpiceWare]

Yes that would save cycles. In your version, 24 IFs are run every time. In his only 14 IFs are run if g<11 and 15 IFs are run if g>10. There is a logic error on g>20:

 if g<11 then goto g_0
 if g>10 then goto g_1
 if g>20 then goto g_2

if g>20 will never happen(because 20>10 so it'll go to g_1) so the ifs for g=21 thru 24 will never occur.

 

The faster way to go would be to use ON GOTO

	if g>24 goto get_rock1x
on g goto get_rock1x, g1, g2, g3, g4, ..., g24

g1  l=20: goto get_rock2x
g2  l=24: goto get_rock2x
g3  l=28: goto get_rock2x
g4  l=32: goto get_rock2x
...
g24  l=112: goto get_rock2x

 

An even faster way would be to realize that this routine is setting l = g*4 + 16.

	if g<1 then goto get_rock1x
if g>24 then goto get_rock1x
l = g*4 + 16

[+Random Terrain]

Yes that would save cycles. In your version, 24 IFs are run every time.

Thanks. That's good to know.

 

 

An even faster way would be to realize that this routine is setting l = g*4 + 16.

	if g<1 then goto get_rock1x
if g>24 then goto get_rock1x
l = g*4 + 16

Do you know if the following would be faster, slower, or the same:

 

	g=(rand&24)+1
l = g*4 + 16

On the surface, it seems like it would be faster since the program would never have to loop back, grab a new random number and look at the same if-thens.

 

Thanks.

Edited May 10, 2008 by Random Terrain

[+Random Terrain]

Here's one more thing. Is the following supposed to fix the playfield so that the title screen can be displayed correctly?

 

down_scrolling
 pfscroll down
 q=q-1
 if q=0 then goto t_s
 goto down_scrolling

If that is the purpose, you can use the following instead to 'reset' the playfield:

 

   playfieldpos=8

[+atari2600land]

Thanks for all these tips on saving space, everyone! I'll utilize them in the next version.

[+Random Terrain]

Here's one more thing before I get back to working on my own game. Have you thought about using the following to make the game more random?

 

   dim rand16=i

[+atari2600land]

Here's one more thing before I get back to working on my own game. Have you thought about using the following to make the game more random?

 

   dim rand16=i

What would that do?

[+Random Terrain]

Here's one more thing before I get back to working on my own game. Have you thought about using the following to make the game more random?

 

   dim rand16=i

What would that do?

I'll just post what it says here:

 

http://www.randomterrain.com/atari-2600-me...l#randomnumbers

The standard random number generator should be random enough for most games. However, if it isn't random enough, you can optionally specify a 16-bit random number generator. This requires that you set aside one variable, and you can't use this variable for other purposes. To use the improved routine, place:

 

   dim rand16=<var>

at the beginning of your program. <var> is one of your 26 variables (a-z.) Then you use rand as you normally would.

Seemed like the scrolling objects weren't random enough and when I added dim rand16=<var> to your program, the randomness improved greatly.

[+SpiceWare]

Do you know if the following would be faster, slower, or the same:

 

	g=(rand&24)+1
l = g*4 + 16

On the surface, it seems like it would be faster since the program would never have to loop back, grab a new random number and look at the same if-thens.

It would be much faster, but you wouldn't get the same results. 24 in binary is 00011000, so you'd get 4 values from (rand&24): 0, 8, 16 and 24.

[+Random Terrain]

Do you know if the following would be faster, slower, or the same:

 

	g=(rand&24)+1
l = g*4 + 16

On the surface, it seems like it would be faster since the program would never have to loop back, grab a new random number and look at the same if-thens.

It would be much faster, but you wouldn't get the same results. 24 in binary is 00011000, so you'd get 4 values from (rand&24): 0, 8, 16 and 24.

Thanks. I keep making that same mistake. That's what I get for not trying it first. OK, I tested this one and it seems to produce a number between 1 and 24 without leaving anything out:

 

	g=(rand&9)+(rand&15)+1
l = g*4 + 16

Do you think that would be faster or does using & and rand twice slow things down?

 

 

Thanks.

Edited May 11, 2008 by Random Terrain

[+Random Terrain]

I had a few more ideas, so I'll post my version of the code in a little bit.

Edited May 11, 2008 by Random Terrain

[+atari2600land]

Version 9, with new variables. p=level # and i=counter for between rocks.

To get to level 2, in level 1 go between 50 rocks. I'd like to make level 2 narrower, but apparently I can't use the pfvline function without it going bonkers. Any ideas on how to make the river narrower?

toobin9.bas

toobin9.bas.bin

[+Random Terrain]

Any ideas on how to make the river narrower?

There's probably a better way to do it, but one way would be to do this:

 

get_rock1x
 if p=1 then temp2=1 : temp3=24
 if p=2 then temp2=6 : temp3=18

 w=0
 z{0}=0
 j=11
 g=rand
 
 if gtemp3 then goto get_rock1x

 
get_rock2x
 l=g*4+16
 k=11
 h=g+5

 playfieldpos=8
 pfclear
 playfield:
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
end  

 m=l+20 

 goto main

That's just a quick example. You wouldn't really want to plop it right there in your code.

Edited May 11, 2008 by Random Terrain

[+Random Terrain]

Here is your latest code with a couple of those changes I mentioned that makes the scrolling smoother:

 

toobin_2008y_05m_11d_1031_smoother_scrolling.bas

 

Also, do you have all of the updated bB files:

 

http://www.atariage.com/forums/index.php?s...t&p=1517363

 

I notice that when I run the code, the red 'raft' is in a different position than when I run the bin file you posted. That might mean that we have different bB include files.