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

Random Terrain, on Sun May 11, 2008 6:36 AM, said:

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]

SpiceWare, on Sun May 11, 2008 1:21 PM, said:

Random Terrain, on Sun May 11, 2008 6:36 AM, said:

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.

This post has been edited by Random Terrain: Sun May 11, 2008 12:29 PM

[MausGames]

Random Terrain, on Sun May 11, 2008 12:49 PM, said:

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]

MausGames, on Sun May 11, 2008 2:35 PM, said:

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:

Quote

I used that stuff batari mentioned in the manual:

http://www.randomter...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.

This post has been edited by Random Terrain: Sun Nov 2, 2008 2:38 AM

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

Attached File(s)

•  toobin.bas (3.49K)
  Number of downloads: 48

This post has been edited by atari2600land: Sun Nov 2, 2008 2:31 AM

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

Random Terrain, on Sun Nov 2, 2008 1:58 AM, said:

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.

Attached File(s)

•  toobin.bas (3.77K)
  Number of downloads: 41
•  toobin.bas.bin (4K)
  Number of downloads: 57

[atari2600land]

Open Source Pong, on Sun Nov 2, 2008 7:54 AM, said:

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

Attached File(s)

•  toobin.bas.bin (4K)
  Number of downloads: 56
•  toobin.bas (5.91K)
  Number of downloads: 47

[atari2600land]

Watch out for alligators!

Attached File(s)

•  toobin.bas.bin (4K)
  Number of downloads: 80
•  toobin.bas (6.99K)
  Number of downloads: 48

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

Attached File(s)

•  toobin.bas.bin (8K)
  Number of downloads: 70
•  toobin.bas (8.25K)
  Number of downloads: 43

[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.c...h?v=u2HuY-j-lc8
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.

This post has been edited by Random Terrain: Wed Nov 5, 2008 1:59 AM

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

Attached File(s)

•  toobin.bas (8.82K)
  Number of downloads: 45

This post has been edited by atari2600land: Wed Nov 5, 2008 8:17 PM

[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

Attached File(s)

•  toobin.bas.bin (8K)
  Number of downloads: 88
•  toobin.bas (9.11K)
  Number of downloads: 46

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

MausGames, on Sun May 11, 2008 7:59 AM, said:

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]

mos6507, on Fri Nov 14, 2008 12:19 PM, said:

MausGames, on Sun May 11, 2008 7:59 AM, said:

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?