Gosub

[+stephena]

Here's the latest ROM and bBasic file. Setting the right difficulty switch to A is PAL and right difficulty switch setting B is NTSC. I've noticed the NTSC to PAL conversion chart is a bit off. It told me that a light green setting in NTSC is actually a light blue setting in PAL. I don't know what's up with that. Anyway, this is probably just the emulator I'm using (Stella), but if I set the TV type to PAL, a big huge black space appears at the bottom, like it's missing something. Would this black space be there if it was on an actual PAL TV?

When using PAL/60 (which is what you're doing), you need to choose "PAL60" in the Stella emulator, which I think was only just added in version 2.3.5, or maybe 2.3 (I forget). The "PAL60" mode in Stella does indeed show a large black area at the bottom of the screen, which is not how it should be displayed.

Yes, this was the problem I mentioned earlier in the thread (should PAL60 be in a larger window with borders, in a larger window and stretched, or just in a smaller window). It's now obvious I've done it incorrectly in Stella.

As Eckhard said, the actual appearance on a PAL TV would depend on how the set handles a 262-line display, and the game screen ought to be "stretched" a bit vertically to get a display that fills the entire screen (like an NTSC picture), or else the game screen ought to be centered. I don't have a PAL TV or PAL Atari, so I can't verify that, but there should be plenty of AtariAgers in Europe, the United Kingdom, or other areas of the world where PAL is used, who can verify that-- and maybe even take photographs of their TVs to show the rest of us how a PAL/60 game looks!

Yes, absolutely, this is what I need. I have no experience whatsoever with PAL systems and its idiosyncracies. If I could see a picture of how a PAL50 (vs. PAL60) ROM would look on a real TV, I think it would be pretty trivial to emulate the behaviour.

[Rom Hunter]

It plays very well.

 

 

IMO the octopus can be more deadly.

 

A little bit less touch-time would be great.

 

Try to make the colours darker each level.

 

[+atari2600land]

Once I get the newest batari basic code back from Mike, those are the two things I'll work on.

[+atari2600land]

How are things going, Mike? And has anyone played this on a Kroko cart yet?

[SeaGtGruff]

How are things going, Mike? And has anyone played this on a Kroko cart yet?

I'm working on the color handling right now. Changing the TV TYPE switch and/or RIGHT DIFFICULTY switch at any time will set the color palette to NTSC, PAL, or black-and-white colors. (I think the way it was before, you could only make that selection at the title screen?) There aren't a lot of changes, but there are a few places where the colors are being set from variables, which makes things a little trickier. (Actually, with the changes I'm making, the colors will *always* be set from variables!) I'll post the code as soon as I can this afternoon, because I know you want to work on it this weekend. I'll also try it on a Krokodile Cartridge.

 

Michael

[SeaGtGruff]

Here's the updated code with the color changes. I think I must have broken the octopus's movement somehow, because it barely moves unless it's aggressive (red), so maybe you can find where it has to be fixed. Since the colors for the title and game are set in a subroutine now (which is called before each drawscreen), I put the checks for switchbw and switchrightb in the subroutine, and took out the use of c{0} and c{7}. But then I had to use c{0} to store whether or not the octopus is aggressive, so c{0} is being checked before moving the octopus. I don't have time to change anymore right now because I have to get ready for my meeting, and I haven't checked it on a Krokodile Cartridge yet, either. You can work on the other things, and I'll work on the colors some more later tonight to see about making the screen darker as the levels increase.

 

Michael

gosub020307.bas

gosub020307.bas.bin

[+atari2600land]

I seem to be a little sick for some reason. I think I might have a cold, but I'll look at the code tomorrow and see what I can do with c{0}. before the Super Bowl, of course. I don't want to miss the funny commercials.

[SeaGtGruff]

I seem to be a little sick for some reason. I think I might have a cold, but I'll look at the code tomorrow and see what I can do with c{0}. before the Super Bowl, of course. I don't want to miss the funny commercials.

Oh, is there some kind of super bowl tomorrow? (I haven't been following football, but I do know that da bears are playing, so I'm not totally under a rock!)

 

If you aren't going to work on it until tomorrow, then I'll see if I can fix anything and post the code again before tomorrow morning.

 

Michael

[+atari2600land]

I solved a little problem with how to begin the game. I noticed that it was really hard to start the game. All I had to do to fix this problem was this:

in the line in "display_title," I changed this line:

if switchreset && j=1 then goto 490 to

if switchreset then goto 490.

I think the variable j was left over from the time I had the second Ants-type minigame programmed in, and we forgot to delete it!

[SeaGtGruff]

I solved a little problem with how to begin the game. I noticed that it was really hard to start the game. All I had to do to fix this problem was this:

in the line in "display_title," I changed this line:

if switchreset && j=1 then goto 490 to

if switchreset then goto 490.

I think the variable j was left over from the time I had the second Ants-type minigame programmed in, and we forgot to delete it!

Okay, that explains that! I also noticed the difficulty in starting the game (response to RESET), but I was in a hurry to post the code for you, so I didn't try to diagnose it. What happened is that I put the code which checks the distance between the octopus and sub into the set_colors subroutine, which is called before every drawscreen-- and that code uses i and j for the difference between the octopus's and sub's x and y coordinates.

 

Michael

[+atari2600land]

I got the octopus moving again, but it's kinda jerky. I added a few lines:

725 
  if s<9 then goto 726 else goto 768

726
  w = w + 1
  if w = 2 then w = 0 : goto 619

[+atari2600land]

I forgot to mention for the program to use these lines, you need to change a line in 678.

678
  if s > 0 && p0x < 35 then s = 1
  if s > 0 && p0y < 15 then s = 3
  if s > 0 && p0x > 150 then s = 2
  if s > 0 && p0y > 87 then s = 4
  m = m + 1
  if m = 60 then m = 0 : s = 0 : goto 619
  if collision(player1,player0) then s = 9
  k = k + 1
  if k = 7 then k = 0 : goto 721
  goto 725 : rem - change this line

[+atari2600land]

I think this game is almost done here, folks. All we have to do is figure out the octopus movement and darker colors as the game progresses. Mike, have you been working on the game? How do you like my octopus movement?

[SeaGtGruff]

I think this game is almost done here, folks. All we have to do is figure out the octopus movement and darker colors as the game progresses. Mike, have you been working on the game? How do you like my octopus movement?

I've added color changes so the water and maze get darker as the levels increase, but I think it still needs some tweaking, especially for the black-and-white version.

 

There are 17 levels, but only 8 possible luminance settings, so if everything starts at the brightest luminance, the luminance needs to decrease every 2 levels:

 

levels 1 and 2 = luminance 14

levels 3 and 4 = luminance 12

levels 5 and 6 = luminance 10

levels 7 and 8 = luminance 8

levels 9 and 10 = luminance 6

levels 11 and 12 = luminance 4

levels 13 and 14 = luminance 2

levels 15, 16, and 17 = luminance 0

 

However, for the black-and-white version there needs to be at least 1 luminance level difference between the colors, otherwise the water and maze walls can't be told apart, and the sub won't be visible at levels 15, 16, and 17. So that works out to a decrease in luminance every 3 levels:

 

levels 1, 2, and 3 = maze luminance 14, water luminance 12, sub luminance 0

levels 4, 5, and 6 = maze luminance 12, water luminance 10, sub luminance 0

levels 7, 8, and 9 = maze luminance 10, water luminance 8, sub luminance 0

levels 10, 11, and 12 = maze luminance 8, water luminance 6, sub luminance 0

levels 13, 14, and 15 = maze luminance 6, water luminance 4, sub luminance 0

levels 16 and 17 = maze luminance 4, water luminance 2, sub luminance 0

 

I'm thinking of flickering between adjacent luminances to get in-between luminances (i.e., 13, 11, 9, 7, 5, 3, and 1), but I'm not sure how well that will work out.

 

There is a problem with the octopus's color in the current version, especially in the black-and-white version, which I need to fix.

 

And the "GOSUB" level maze looks broken, which I need to fix.

 

Michael

gosub021307.bas

gosub021307.bas.bin

[+atari2600land]

Very nice job!

[+atari2600land]

Version for 2/15/07 (even though it's technically 2/16/07 at 12:30 AM). I replaced level 4 with an easier level. I'd like to add a few more levels since there's way more room now in bank 2. Also, I changed the octopus attack from 160 cycles to 100 cycles, so the sub will be quicker to break once the octopus gets a hold of it. What do you think?

gosub021507.bas

gosub021507.bas.bin

[Rom Hunter]

Very nice.

 

What would be great is that the octopus can be avoided by backtracking, but once it entangles you it's very difficult to survive (please play the final level of Ghost Manor to know what I mean).

 

So my suggestion would be:

Once the octopus senses you, it swims towards you less faster than it does now.

Once the octopus entangles you, it is very hard to escape from it (so even less cycles than it has now).

 

IMO the darkening of the levels would be nicer if it goes from blue to black (instead of light blue to dark blue).

 

Keep up the good work!

 

[SeaGtGruff]

Very nice.

 

What would be great is that the octopus can be avoided by backtracking, but once it entangles you it's very difficult to survive (please play the final level of Ghost Manor to know what I mean).

 

So my suggestion would be:

Once the octopus senses you, it swims towards you less faster than it does now.

Once the octopus entangles you, it is very hard to escape from it (so even less cycles than it has now).

 

IMO the darkening of the levels would be nicer if it goes from blue to black (instead of light blue to dark blue).

 

Keep up the good work!

 

I originally wanted to make the deepest, darkest level black, but the sub is also black, so you wouldn't be able to see yourself-- unless I make the sub one shade lighter (i.e., darkest gray instead of black). I thought of doing that, and I also thought of flickering between darkest blue and black for the last level. I'm going to try adding flickering tonight to get in-between luminances, and I'll try to make the last level darker.

 

Michael

[+atari2600land]

I just thought for kicks to try and use the file with the new bB 1.0. Apart from 2 warnings about long lines, I got this.

 

Why is the bottom border incomplete?

[+batari]

I just thought for kicks to try and use the file with the new bB 1.0. Apart from 2 warnings about long lines, I got this.

 

Why is the bottom border incomplete?

There should not be a HMOVE line to the left of the score, as the score positioning was rewritten so it would no longer appear. I think you might have an old std_kernel.asm lingering around in the same directory as your .bas file.

[+batari]

I found a couple of small issues with Gosub and bB 1.0. One of the long lines actually crashed bB for me, and the "lives" variable you are using is currently defined by bB for the life counter, so I changed both.

 

Also, the thin line at the bottom has been removed from bB 1.0, which I think you were relying on for a bottom border. I think I fixed this by scrolling the playfield up one line and moving your ship starting position up to match.

 

I also found that the title music could be optimized for space, so I did that with a data statement, and also found some other savings, freeing up about 1k in the first bank.

gosuba.bas

[+atari2600land]

Here's what I get when I compile the gosuba.bas:

[SeaGtGruff]

I also found that the title music could be optimized for space, so I did that with a data statement, and also found some other savings, freeing up about 1k in the first bank.

I knew the music could be optimized to free up space, but I didn't want to attempt it, because I was afraid I might break something.

 

Michael

[SeaGtGruff]

Here's what I get when I compile the gosuba.bas:

It worked for me, so it might be something in your includes files. I know you're using a custom score graphics file. Did you change the default.inc file to use your custom includes file(s)?

 

Before I installed bB 1.0, I zipped up the contents of each of my subdirectories (to keep anything I'd modified), then deleted everything from my subdirectories except for those zip files, so none of my old files would interfere with bB 1.0. Then I installed bB 1.0. I advise you to do something like that, and then modify the new 1.0 files as needed for your custom score display. Also, bB 1.0 has a new command that lets you compile with custom includes files without changing the default.inc file.

 

Michael

[+batari]

Here's what I get when I compile the gosuba.bas:

It worked for me, so it might be something in your includes files. I know you're using a custom score graphics file. Did you change the default.inc file to use your custom includes file(s)?

 

Before I installed bB 1.0, I zipped up the contents of each of my subdirectories (to keep anything I'd modified), then deleted everything from my subdirectories except for those zip files, so none of my old files would interfere with bB 1.0. Then I installed bB 1.0. I advise you to do something like that, and then modify the new 1.0 files as needed for your custom score display. Also, bB 1.0 has a new command that lets you compile with custom includes files without changing the default.inc file.

 

Michael

In bB 1.0, there is no longer any need to modify the new .asm, .h or .inc files, because the compiler will search two places for the files now - the current directory first (i.e. where your .bas file is) then the includes directory. For instance, this allows for you to keep the existing score_graphics.asm intact so you can modify a copy of it.

 

This is also why it's important to install bB into a new folder and clear out any lingering files from the directory where the .bas file lives, because it will try to use those files first.

 

This is covered in the documentation under Hacking batari Basic's .asm files though it also applies to .h and .inc files.