52 replies to this topic

[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.

Attached Images

• 
• 

Attached Files

•  toobin3.bas.bin   8K   85 downloads
•  toobin3.bas   7.33K   69 downloads

[gambler172]

Hi Chris
Looks nice,so far.
greetings Walter

Edited by gambler172, Thu May 8, 2008 1:06 PM.

[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]

Random Terrain, on Thu May 8, 2008 8:23 PM, said:

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.

Attached Files

•  toobin4.bas.bin   8K   65 downloads
•  toobin4.bas   7.43K   55 downloads

[Random Terrain]

atari2600land, on Thu May 8, 2008 11:47 PM, said:

Random Terrain, on Thu May 8, 2008 8:23 PM, said:

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:

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

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.

Attached Files

•  toobin5.bas.bin   8K   63 downloads
•  toobin5.bas   7.52K   52 downloads

[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.

Attached Files

•  toobin6a.bas.bin   8K   67 downloads
•  toobin6a.bas   9.09K   58 downloads

[Shawn Sr.]

atari2600land, on Fri May 9, 2008 9:03 AM, said:

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.

Attached Files

•  toobin7.bas.bin   8K   80 downloads
•  toobin7.bas   9.86K   62 downloads

[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]

SpiceWare, on Sat May 10, 2008 2:33 PM, said:

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

Thanks. That's good to know.

SpiceWare, on Sat May 10, 2008 2:33 PM, said:

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 by Random Terrain, Sat May 10, 2008 1:57 PM.

[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]

Random Terrain, on Sat May 10, 2008 7:33 PM, said:

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]

atari2600land, on Sat May 10, 2008 10:38 PM, said:

Random Terrain, on Sat May 10, 2008 7:33 PM, said:

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

Quote

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]

Random Terrain, on Sat May 10, 2008 1:54 PM, said:

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]

SpiceWare, on Sun May 11, 2008 12:58 AM, said:

Random Terrain, on Sat May 10, 2008 1:54 PM, said:

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 by Random Terrain, Sun May 11, 2008 7:06 AM.

[Random Terrain]

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

Edited by Random Terrain, Sun May 11, 2008 7:12 AM.

[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?

Attached Files

•  toobin9.bas.bin   8K   76 downloads
•  toobin9.bas   9.58K   52 downloads

[Random Terrain]

atari2600land, on Sun May 11, 2008 9:18 AM, said:

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 by Random Terrain, Sun May 11, 2008 7:56 AM.

[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   9.52K   72 downloads

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.