+atari2600land Posted May 8, 2008 Share Posted May 8, 2008 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 1 Quote Link to comment Share on other sites More sharing options...
gambler172 Posted May 8, 2008 Share Posted May 8, 2008 (edited) Hi Chris Looks nice,so far. greetings Walter Edited May 8, 2008 by gambler172 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 9, 2008 Share Posted May 9, 2008 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? Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 9, 2008 Author Share Posted May 9, 2008 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 9, 2008 Share Posted May 9, 2008 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 9, 2008 Author Share Posted May 9, 2008 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 9, 2008 Author Share Posted May 9, 2008 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 Quote Link to comment Share on other sites More sharing options...
Shawn Posted May 9, 2008 Share Posted May 9, 2008 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! Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 10, 2008 Author Share Posted May 10, 2008 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 10, 2008 Author Share Posted May 10, 2008 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 Quote Link to comment Share on other sites More sharing options...
gambler172 Posted May 10, 2008 Share Posted May 10, 2008 Hi Chris Nice ......I like it. greetings Walter Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 10, 2008 Share Posted May 10, 2008 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 10, 2008 Share Posted May 10, 2008 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 10, 2008 Share Posted May 10, 2008 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 11, 2008 Share Posted May 11, 2008 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 11, 2008 Author Share Posted May 11, 2008 Thanks for all these tips on saving space, everyone! I'll utilize them in the next version. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 11, 2008 Share Posted May 11, 2008 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 11, 2008 Author Share Posted May 11, 2008 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 11, 2008 Share Posted May 11, 2008 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 11, 2008 Share Posted May 11, 2008 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 11, 2008 Share Posted May 11, 2008 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 11, 2008 Share Posted May 11, 2008 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted May 11, 2008 Author Share Posted May 11, 2008 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 11, 2008 Share Posted May 11, 2008 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 11, 2008 Share Posted May 11, 2008 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.