ToobBin'

[MausGames]

The complete lack of physics make this more like pushing a piece of paper around on a tabletop than playing a game.

[gambler172]

Hi Chris

After 80 points,the game crashed.And after 30 points no arrows appear.

greetings Walter

[+SpiceWare]

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?

Hmm

 

9 = 00001001 would yield 0, 1, 8, 9

15 = 00001111 would yield any number between 0-15

 

g would up having values from 1-25, not 1-24. Would have to make that g=(rand&+(rand&15)+1.

 

8 = 00001000 would yield 0, 8

 

I don't think calling rand twice would slow things down. Another plus is in the original method who knows how many times you'd have to branch back before you got a number between 1-24. Things like that make it hard to judge how long a routine would take, and thus increase the potential for screen jitter/jump.

 

Only tradeoff I see is the values would probably not be evenly distributed, but the benefit of faster plus consistent run-time would more than offset that.

[+Random Terrain]

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?

Hmm

 

9 = 00001001 would yield 0, 1, 8, 9

15 = 00001111 would yield any number between 0-15

 

g would up having values from 1-25, not 1-24. Would have to make that g=(rand&+(rand&15)+1.

 

8 = 00001000 would yield 0, 8

 

I don't think calling rand twice would slow things down. Another plus is in the original method who knows how many times you'd have to branch back before you got a number between 1-24. Things like that make it hard to judge how long a routine would take, and thus increase the potential for screen jitter/jump.

 

Only tradeoff I see is the values would probably not be evenly distributed, but the benefit of faster plus consistent run-time would more than offset that.

Yeah, I just discovered the 25 after trying a better way of testing numbers. It took me a while to figure out the best way to test using the score. I thought this would give a number between 1 and 24 without a doubt:

 

  g=(rand&1)+(rand&7)+(rand&15)+1

 

But after testing all the numbers in the middle, it was incomplete. I need to find a chart or something to make this easier. I should be able to find the right combination for various numbers I might need in future games.

Edited May 11, 2008 by Random Terrain

[MausGames]

Yeah, I just discovered the 25 after trying a better way of testing numbers. It took me a while to figure out the best way to test using the score. I thought this would give a number between 1 and 24 without a doubt:

 

  g=(rand&1)+(rand&7)+(rand&15)+1

 

But after testing all the numbers in the middle, it was incomplete. I need to find a chart or something to make this easier. I should be able to find the right combination for various numbers I might need in future games.

 

I don't really follow this, how does that work? How did you use the score?

[+Random Terrain]

I don't really follow this, how does that work? How did you use the score?

Update

 

Ignore the crap in my original reply and just use this to discover the value of 2 variables:

 

  score=0 : scorecolor=252 : temp5 = [your first variable goes here]
 if temp5>0 then for temp6=1 to temp5 : score=score+1000 : next

 temp5 = [your second variable goes here]
 if temp5>0 then for temp6=1 to temp5 : score=score+1 : next

 

So here's a working example:

 

  score=0 : scorecolor=252 : temp5 = a
 if temp5>0 then for temp6=1 to temp5 : score=score+1000 : next

 temp5 = b
 if temp5>0 then for temp6=1 to temp5 : score=score+1 : next

 

 

Original reply based on stupidity and a need to create bloated code for no reason:

I used that stuff batari mentioned in the manual:

 

http://www.randomterrain.com/atari-2600-me...ands.html#score

  dim sc1=score
 dim sc2=score+1
 dim sc3=score+2

 

And since the number range was low, I did a quick and dirty if-then conversion:

 

  if r=0 then sc3=$00
 if r=1 then sc3=$01
 if r=2 then sc3=$02
 if r=3 then sc3=$03
 if r=4 then sc3=$04
 if r=5 then sc3=$05
 if r=6 then sc3=$06
 if r=7 then sc3=$07
 if r=8 then sc3=$08
 if r=9 then sc3=$09
 if r=10 then sc3=$10
 if r=11 then sc3=$11
 if r=12 then sc3=$12
 if r=13 then sc3=$13
 if r=14 then sc3=$14
 if r=15 then sc3=$15
 if r=16 then sc3=$16
 if r=17 then sc3=$17
 if r=18 then sc3=$18
 if r=19 then sc3=$19
 if r=20 then sc3=$20
 if r=21 then sc3=$21
 if r=22 then sc3=$22
 if r=23 then sc3=$23
 if r=24 then sc3=$24
 if r=25 then sc3=$25
 if r=26 then sc3=$26
 if r=27 then sc3=$27
 if r=28 then sc3=$28
 if r=29 then sc3=$29
 if r=30 then sc3=$30

There's probably a much better way to do it, but at least that's accurate. I was using a for-next loop before and it was tainting the results.

Edited November 2, 2008 by Random Terrain

[+atari2600land]

I'm back to work on this, and was wondering how to have 1 row of blocks and not two like there is now, and also how to get the previous rock placements erased so there's only two blocks

 

Here's the list of sprites:

* = not implemented yet

player0 - guy

ball - raft

missile0 - guy's missiles *

player1 - enemy *

missile1 - enemy's missiles *

toobin.bas

Edited November 2, 2008 by atari2600land

[+Random Terrain]

Looks like the problem might be similar to the problems in some of your other programs. When scrolling, you only need to plop the rocks down on the hidden row once. You don't have to track, draw, erase, and redraw them. Just plop them down and let pfscroll up do all of the work. The only place you should be pfpixeling the rocks is on the hidden row.

[Primordial Ooze]

Cool game, i really like your game.

 

Sincerely,

 

Open Source Pong

[+atari2600land]

Looks like the problem might be similar to the problems in some of your other programs. When scrolling, you only need to plop the rocks down on the hidden row once. You don't have to track, draw, erase, and redraw them. Just plop them down and let pfscroll up do all of the work. The only place you should be pfpixeling the rocks is on the hidden row.

Yep, that was it. Thank you.

New version with left/right/down movement. If you press down, the playfield will scroll faster, but you won't actually move down.

toobin.bas

toobin.bas.bin

[+atari2600land]

Cool game, i really like your game.

Thank you. I hope you'll like it once i finish it (if i do).

[+atari2600land]

New features:

+Title Screen music

+to fire a missile left, press fire+left

+to fire a missile right, press fire+right

toobin.bas

toobin.bas.bin

[+atari2600land]

Watch out for alligators!

toobin.bas.bin

toobin.bas

[+atari2600land]

There's a little clip on YouTube of the NES version of Toobin' here. If anyone can program something like the title screen/first river music for bB, that'd be totally awesome.

[+atari2600land]

Watch out for spear-throwing aliens! I plan to have a total of 4 different enemies. So far i have 2 (the aliens and the aliigators). The alligators are turned off at the moment. Does anyone have any suggestions?

toobin.bas.bin

toobin.bas

[+Random Terrain]

I never have been that big of a fan of Toobin' and that's with arcade graphics, so I can't be of much help. I liked a different water related arcade game called Swimmer better:

 

http://www.youtube.com/watch?v=u2HuY-j-lc8

 

I just wish someone would remake it with better graphics and either get rid of or let you turn down or turn off the irritating background music. That repetitive high-pitched tune can burn a hole in your brain.

Edited November 5, 2008 by Random Terrain

[+atari2600land]

OK, I need help.

 

In this current build, if you get 200 points (get past 2 enemies), you'll go down to the bottom of the screen as intended. But what wasn't intended is once you get to the bottom of the screen, the scanline count will jump from 262 to 263. Once you're in Stella's debugger, press Frame+1 and you'll see it jump to 291. Press Frame+1 again and it goes way down to 4. press Frame+1 again and it goes back up to 262 and the game resumes normally. WHY DOES THIS HAPPEN?

toobin.bas

Edited November 6, 2008 by atari2600land

[+Random Terrain]

I'll be back to look at your code after I'm done eating to see if I can see the problem. If you read this before I get back, can you tell me where that part is in your code where he moves down?

[+atari2600land]

He goes down at the label get_down in bank 2. Once his y position gets to 86 then the next level starts and that's where the problem is.

[+Random Terrain]

I think I found the problem. Defining the entire playfield by using the playfield: command can almost reach or go over 262 depending on the resolution. Since you're using a normal playfield, you're not going over 262 yet, but there's more. Things like pfvline can use up a lot of cycles too, so put them together and you're screwed. The quick solution would be to add drawsceen. So instead of this:

 

  playfield:
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
end

 if level>1 then pfvline 8 0 11 on : pfvline 9 0 11 on : pfvline 22 0 11 on : pfvline 23 0 11 on : x=57 : y=97

 

You'd use this:

 

  playfield:
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
 XXXXXXXX................XXXXXXXX
end
 drawscreen
 if level>1 then pfvline 8 0 11 on : drawscreen : pfvline 9 0 11 on : drawscreen : pfvline 22 0 11 on : drawscreen : pfvline 23 0 11 on : drawscreen : x=57 : y=97

 

But if you think about it, since it's a scrolling game, you don't have to use playfield: or pfvline. Everything you need to do could be done on the bottom, hidden row.

[+atari2600land]

Thanks for the info. With it, i was able to fix it. I think there will be a total of 6 levels, once you get past level 6, the speed and narrowness will stay the same. Where the levels stand:

 

level 1 = wide / speed low

level 2 = wide / speed medium

level 3 = wide / speed high

level 4 = narrow / speed low

level 5 = narrow / speed medium

level 6 = narrow / speed high

 

next up: programming some sharks that move in circles.

 

what i need to do before the program is done:

+ figure out how to align the Os in the title screen to the rest of the letters (since it's a scrolling game)

+ add some death noise

toobin.bas.bin

toobin.bas

[yuppicide]

Just tried this out (shh.. I'm at work) and it's pretty good. Would be nice if you could have done the sides of the playfield so they aren't always the same length. Make it look more like rocky/sandy shores.

[mos6507]

The complete lack of physics make this more like pushing a piece of paper around on a tabletop than playing a game.

 

I agree. The kernel has a lot of potential but a lot more work has to be done on the physics before it starts to feel like Toobin. The guy has to be made to actually paddle with his hands and rotate around, go down waterfalls, etc...

 

Right now it's more like a glorified Journey Escape.

[+atari2600land]

The complete lack of physics make this more like pushing a piece of paper around on a tabletop than playing a game.

 

I agree. The kernel has a lot of potential but a lot more work has to be done on the physics before it starts to feel like Toobin. The guy has to be made to actually paddle with his hands and rotate around, go down waterfalls, etc...

 

Right now it's more like a glorified Journey Escape.

 

Will someone please help with the physics?

[+atari2600land]

OK, I took matters into my own hands here. The physics are slim if any right now, but once you depress left or right, the guy keeps going left or right really slowly until he comes to a complete stop. I'm starting from scratch here. Right now that's all you can do, just move him left or right. Also, I need a little more tune to the title screen. All I've composed so far is the intro.

toobin_122010.bas

toobin_122010.bas.bin