Toxic Code - Please HELP!

[MausBoy]

I'm attaching my Eden demo and the source, I've had some strange problems with it I thought maybe one of you could help me with.

 

Everytime I compile this program now, it gives me a different "bytes left" number for bank1, and it won't let me add anything to bank2 without causing a "source is reverse-indexed" error. It only compiles without errors about 1 out of 6 times that I try, without changing anything. Sometimes when I compile, some of the ships stick in the middle of the screen - this is shown in the attached bin - other times not. About every third time you die it jumps back to the start of the code instead of the game over sequence.

 

I have no idea what is causing any of these problems, but as you'll see if you check the source it's a long mess anyway. I've gone over it a dozen times and found no reason for any of these problems though.

 

Thanks in advance for any help!!

000eden2.bas

edenbug.bin

Edited September 4, 2006 by MausBoy

[SeaGtGruff]

I'm attaching my Eden demo and the source, I've had some strange problems with it I thought maybe one of you could help me with.

 

I get the same results whenever I compile it (25 bytes free in bank 1, and -65 bytes free in bank 2).

 

If you're recompiling the code without making any changes, it may be something in your setup-- the editor or IDE you're using, the compile batch you're using, the compiler you're using, etc. Back when I was using 2600IDE, I sometimes got different results when I compiled. I might compile a program and get weird errors, then immediately recompile it and get no errors! I've also had this happen in Crimson Editor, so I don't think it has anything to do with 2600IDE, but it hasn't happened as much in Crimson Editor. The only semi-likely theory I could ever come up with is that it may have something to do with some temporary bB files that weren't being handled correctly for whatever reason, like the old temporary files (from the previous compile) weren't getting replaced by the new temporary files, or something like that.

 

Anyway, your problem is that you've run out of space in bank 2, so the score characters will overlap your code. To fix this, you can either change to 16K bankswitching and move some code from bank 2 into bank 3 (which would also give you nearly 8K additional ROM for your game), or (if your game is more or less complete and you don't need to add more code to it) try to optimize your code.

 

For example, I see that you have a "clearit" routine to clear all of bB's user variables (a through z), and you could optimize that code so it uses less ROM, like this:

 

clearit
  rem  a = 0 : b = 0 : c = 0 : d = 0 : e = 0 : f = 0
  rem  g = 0 : h = 0 : i = 0 : j = 0 : k = 0 : l = 0
  rem  m = 0 : n = 0 : o = 0 : p = 0 : q = 0 : r = 0
  rem  s = 0 : t = 0 : u = 0 : v = 0 : w = 0 : x = 0
  rem  y = 0 : z = 0

  rem * The following assembly code takes up much less ROM.

  asm
  LDA #0		   ; load the accumulator with 0
  LDX #25		  ; load the X register with 25
clearit_loop
  STA a,X		  ; store 0 in a[X] (i.e., a[25] to a[0], or z to a)
  DEX			  ; decrement the X register
  BPL clearit_loop ; keep repeating until X goes to -1
end

  return

 

This accomplishes the same thing as your code, but you end up with 50 bytes free in bank 2, instead of -65 bytes, so that means you save 115 bytes (50 plus 65).

 

There may be other places where you can optimize your code to save ROM, either by using in-line assembly instead of bB code (as in the preceding case), or by making changes in your bB code.

 

However, if your game isn't finished, and you still have a lot you want to add to it, you might want to go to a 16K game.

 

If you don't think you'll need 16K, or if you're set on using only 8K, then you should try to optimize your code as much as possible, or maybe even take something out of the game so it doesn't end up needing as much ROM.

 

By the way, the intro "movie" is very cool! But after the intro ends and the title is displayed, there seem to be some bugs.

 

MR

000eden2.bas

000eden2.bas.bin

Edited September 5, 2006 by SeaGtGruff

[MausBoy]

MR,

 

Your compile dosn't have the frozen ships issue, but it has the same problem of the game over animation/screen not showing, and it jumping back to the intro instead. there is no code that would even point the game back to the intro, so i can't figure out why this is happening.

 

This is actually a demo thrown together with pieces of the actual game, so some of those problems are slopiness on my part, it's the ones described above that I couldn't figure out and didn't seem to have any solution.

 

When I compile, it tells me i still have something like 1200 bytes left in bank 2, and 25-35 left in bank 1. I'm really confused, there should still be plenty of room in bank 2. Check out the source, there isn't very much in it. The game itself is 16k, but I've been developing the different kernels in seperate files with plans to combine them all when finished - this demo comes from the space shooter levels kernel, by far the most rom-hungry. When I switch it over to 16k, it garbles the crap out of all my playfield graphics - I'm still really confused, but what you've told me so far makes sense and should help, I'll experiment more tonight. Thank you!!

[SeaGtGruff]

When I compile, it tells me i still have something like 1200 bytes left in bank 2, and 25-35 left in bank 1. I'm really confused, there should still be plenty of room in bank 2. Check out the source, there isn't very much in it.

Don't forget that bB's own routines will be placed in the last bank, so the number of bytes free in the last bank will depend on which bB include files you include, as well as how large your own code is.

 

The game itself is 16k, but I've been developing the different kernels in seperate files with plans to combine them all when finished - this demo comes from the space shooter levels kernel, by far the most rom-hungry. When I switch it over to 16k, it garbles the crap out of all my playfield graphics - I'm still really confused, but what you've told me so far makes sense and should help, I'll experiment more tonight. Thank you!!

In that case, I would suggest switching to 16K now, instead of later, because if there will be 4 banks instead of only 2, bB's routines will be placed in bank 4, which will free up more ROM in bank 2.

 

Michael Rideout

[Piggles]

I love the intro screen also.

 

The game is a good R-Type / Gradius style side scroller!

[+atari2600land]

Are the bugs we're talking about being the word "project" being screwed up when the word scrolls down?

[MausBoy]

Are the bugs we're talking about being the word "project" being screwed up when the word scrolls down?

 

Nope - That is intentional.

 

 

 

 

MR - I switched to 16k - It didn't fix ANY of the problems I'm having, and it completely garbled all my playfield graphics beyond repair, and made the score graphics fat and distorted. So I tried creating a new 16k file and just putting in one playfield table, it does the same thing. Not sure what to do. And I'd still love to know what's up with these other strange errors, like the ships missiles being stuck at the left side of the screen, some ships being stuck in the middle of the screen and moving left when the player's ship moves left, the game jumping back to the intro instead of the game over screen, etc. And thanksx100 for that replacement code for the clearit routine, I really appreciate you taking the time to give tips like that, things I could never come up with on my own.

 

Piggles - Thanks for the compliments! If you like this demo, hopefully you'll love the full game. It'll never compare to R-Type, but that's one of the inspirations.

 

 

Anyone who hasn't checked out this buggy mess of a replacement demo, the pause screen and death animation were added back into this one. Press Select to see the pause screen - F1 in Stella, F2 in Z26. It shows your target planet, and distance remaining to target.

 

Also added exprimental multidirectional shooting. In the full game you'll be able to select between single and multidirectional from the pause screen.

Edited September 5, 2006 by MausBoy

[SeaGtGruff]

Are the bugs we're talking about being the word "project" being screwed up when the word scrolls down?

 

Nope - That is intentional.

Oops, then I guess they aren't bugs! Truth is, I didn't know to get it to proceed from there.

 

MR - I switched to 16k - It didn't fix ANY of the problems I'm having, and it completely garbled all my playfield graphics beyond repair, and made the score graphics fat and distorted. So I tried creating a new 16k file and just putting in one playfield table, it does the same thing. Not sure what to do. And I'd still love to know what's up with these other strange errors, like the ships missiles being stuck at the left side of the screen, some ships being stuck in the middle of the screen and moving left when the player's ship moves left, the game jumping back to the intro instead of the game over screen, etc. And thanksx100 for that replacement code for the clearit routine, I really appreciate you taking the time to give tips like that, things I could never come up with on my own.

Why don't you post your BAS code so we can look at it? Or if you don't want to post it yet, you're welcome to attach it to a PM to me if you wish. Not that I can promise to figure out what's wrong, but you never know!

 

MR

[MausBoy]

Well the new code is at home, where I am not and won't be tonight. If you could download the source in the first post again, if you just switch it to set romsize 16k, you'll see what I mean.

 

Otherwise, the code is exactly the same still, and all the bugs I'm mentioning are exhibited in the game when you compile the source code above. Sorry I didn't mention that you had to press the joystick button to start the game demo.

[+atari2600land]

Why I asked what I did is, doesn't this look weird? Because it does to me.

[MausBoy]

Yeah it looks wierd but I like it that way. If it did it nonstop, that would be something else. It does it a couple times then quits. If it's really that crazy for the text to be stretched out and roll a couple times, I can always remove that.

[SeaGtGruff]

Well the new code is at home, where I am not and won't be tonight. If you could download the source in the first post again, if you just switch it to set romsize 16k, you'll see what I mean.

 

Otherwise, the code is exactly the same still, and all the bugs I'm mentioning are exhibited in the game when you compile the source code above. Sorry I didn't mention that you had to press the joystick button to start the game demo.

Okay! As it happens, I think I may have figured out the problem with the playfield, anyway-- without even looking at your code!

 

In the "multicart" thread, s0c7 mentioned that bB stores all of the player graphics data in the last bank, which I hadn't realized-- but it makes sense, since the last bank is where bB's own routines go, including the display kernel, and it's a lot easier to have the graphics data be in the same bank as the display kernel, otherwise bB would end up having to switch back and forth between banks in the middle of drawing the scan lines! But s0c7 said he didn't think bB put the playfield in the last bank (unless I read his post incorrectly), so I decided to do a simple test to see how it all works.

 

I wrote a simple little 2-bank 8K program that displays a man doing... um, something. (I can't figure out if he's dancing, doing aerobics, running, powerwalking, or just shaking his booty!) My first test used player graphics only, and I confirmed by looking at the compile listing that bB does store all of the player graphics in the last bank. For my second test, I added the playfield to see if bB stores it in the last bank, too-- and it does, but the playfield that's coded in the first bank doesn't work! Here is my second test:

 

  set romsize 8k : rem * Tell bB to use F8 bankswitching.

  rem * Bank 1 starts here. *************************************

  COLUBK = $02
  COLUPF = $24
  player0x = 90
  player0y = 60
  t = 0

loop_1
  playfield:
  XXX.XXX....X...X...X.XXX.....X..
  X...X..X..X.X..XX.XX.X......XX..
  XXX.XXX..X...X.X.X.X.XXX.....X..
  X...X.X..XXXXX.X...X.X.......X..
  X...X..X.X...X.X...X.XXX....XXX.
  ................................
  ................................
  ................................
  ................................
  ................................
  ................................
end
  player0:
  %00001100
  %11001000
  %01001000
  %01001000
  %10111000
  %10111010
  %10111010
  %01111100
  %00010000
  %00111000
  %00111000
end
loop_1_a
  COLUP0 = $4C
  drawscreen
  t = t + 1
  if t < 15 then goto loop_1_a
  t = 0
  goto loop_2 bank2

  bank 2 : rem * Bank 2 starts here. ****************************

loop_2
  playfield:
  XXX.XXX....X...X...X.XXX....XXX.
  X...X..X..X.X..XX.XX.X.....X...X
  XXX.XXX..X...X.X.X.X.XXX.....XX.
  X...X.X..XXXXX.X...X.X......X...
  X...X..X.X...X.X...X.XXX...XXXXX
  ................................
  ................................
  ................................
  ................................
  ................................
  ................................
end
  player0:
  %01100000
  %00100110
  %00100100
  %00100100
  %00111010
  %10111010
  %10111010
  %01111100
  %00010000
  %00111000
  %00111000
end
loop_2_a
  COLUP0 = $4C
  drawscreen
  t = t + 1
  if t < 15 then goto loop_2_a
  t = 0
  goto loop_1 bank1

 

What I wanted to happen was to flash between "FRAME 1" and "FRAME 2" as the man is... um... doing his thing. But instead of writing "FRAME 1" (which is stored in the first bank), bB just draws a solid playfield. Looking at the compile listing, the playfield data is being stored correctly (in the last bank), and it looks like the playfield data should be getting loaded correctly-- except the load instructions are in bank 1, and the data is in bank 2, so of course the wrong information is being loaded, since bB is using the correct addresses but is pulling the data from the wrong bank. The reason why it works with the players but not with the playfield has to do with the way bB stores the playfield and player data in RAM, since bB stores the actual playfield data in RAM (in the standard kernel), but stores only pointers to the player data in RAM.

 

Anyway, I decided that since bB is going to store all of the graphics data in the last bank anyway, and since the playfield doesn't work correctly (in the standard kernel) if the playfield data is defined in the other banks (i.e., in any other bank besides the last bank), then it makes the most sense to just code all of the graphics data in the last bank, and set the players and playfield to the desired data by calling an appropriate subroutine that's located in the last bank, as in my third test:

 

  set romsize 8k : rem * Tell bB to use F8 bankswitching.

  rem * Bank 1 starts here. *************************************

  COLUBK = $02
  COLUPF = $24
  player0x = 90
  player0y = 60
  t = 0

loop_1
  gosub frame_1_graphics bank2
loop_1_a
  COLUP0 = $4C
  drawscreen
  t = t + 1
  if t < 15 then goto loop_1_a
  t = 0
  goto loop_2 bank2

  bank 2 : rem * Bank 2 starts here. ****************************

loop_2
  gosub frame_2_graphics
loop_2_a
  COLUP0 = $4C
  drawscreen
  t = t + 1
  if t < 15 then goto loop_2_a
  t = 0
  goto loop_1 bank1

frame_1_graphics
  playfield:
  XXX.XXX....X...X...X.XXX.....X..
  X...X..X..X.X..XX.XX.X......XX..
  XXX.XXX..X...X.X.X.X.XXX.....X..
  X...X.X..XXXXX.X...X.X.......X..
  X...X..X.X...X.X...X.XXX....XXX.
  ................................
  ................................
  ................................
  ................................
  ................................
  ................................
end
  player0:
  %00001100
  %11001000
  %01001000
  %01001000
  %10111000
  %10111010
  %10111010
  %01111100
  %00010000
  %00111000
  %00111000
end
  return

frame_2_graphics
  playfield:
  XXX.XXX....X...X...X.XXX....XXX.
  X...X..X..X.X..XX.XX.X.....X...X
  XXX.XXX..X...X.X.X.X.XXX.....XX.
  X...X.X..XXXXX.X...X.X......X...
  X...X..X.X...X.X...X.XXX...XXXXX
  ................................
  ................................
  ................................
  ................................
  ................................
  ................................
end
  player0:
  %01100000
  %00100110
  %00100100
  %00100100
  %00111010
  %10111010
  %10111010
  %01111100
  %00010000
  %00111000
  %00111000
end
  return

 

So I suspect that your problems with the playfield (when you switch to 16K) can probably be solved by moving all of the code for the playfield graphics into the last bank (which would be bank 4 if you're doing a 16K game), and using gosubs to set the playfield to the desired data as needed, the way I did in my third test. You don't need to do that with the player data, but it would make the most sense to do it anyway, because it sort of reminds you that bB is going to put all of your graphics data in the last bank.

 

I'll take the code you've already posted, move all of the code for the graphics data into the last bank, and recompile it to see how it works.

 

MR

[SeaGtGruff]

I'll take the code you've already posted, move all of the code for the graphics data into the last bank, and recompile it to see how it works.

I've barely made a dent in it, but here's what I did so far. You can pick up where I left off; I think you should be able to see where that is.

 

In addition to moving the graphics data into bank 4 (which for the most part has been pretty easy so far, because you were using subroutines anyway), I made a few other minor changes. Most of them were putting three spaces at the beginning of every line, instead of just one space (because I think three spaces helps to better distinguish the line labels from the code lines). But I also added a blank line after the returns, or after a routine that ends with a goto (to help separate the different routines a little better). Also, I separated some statements that were on the same line (unless they were in an if), because I think its easier to read programs if the statements are on separate lines. But in a few cases I moved some statements together, because bB will optimize better if you assign the same value to different variables on the same line (i.e., a = 1 : b = 1 : c = 1 will take fewer bytes, since bB will load 1 into a register and then store it in a, b, and c without reloading 1 into the register each time). And there were a couple of "= 0" statements that I took out of the beginning, because they occur after you've called clearit, so those variables will already be set to 0 anyway!

 

I haven't gotten to bank 2 yet, so all of the playfield graphics in that bank (and any in bank 1) still need to be moved into bank 4. In addition to the graphics shapes, I'm assuming that the color tables need to be in bank 4 as well, but I'm not certain about that yet.

 

MR

000eden2.bas

[MausBoy]

Thanks! I really, really appreciate that! This demo was thrown together in a couple hours so it really was a nasty mess. I still have no explanation or resolution to the wierd errors of frozen ships and incorrect routine jumps, but this helps a lot with knowing what I can and cannot do.

 

So now that I know that I can only have 4k of graphics, this project is more or less bunk. So much for my "I've learned how to work within the systems limits" remark. I don't want to give it up, so maybe I'll just tame it down even more.

 

Maybe if I do some kind of zen exercises like picturing myself smashing my NES and hugging my Atari I'll get into the right mindset for programming games for this particular console.

[MausBoy]

Well, I have to go home now.

I'll work on this some more tonight, so...

To Be Continued Tomorrow.

[MausBoy]

This project upsets me. I badly wanted to finish it and release it. I really just can't seem to wrap my head around a doable 2600 game concept; the nes is too ingrained in my videogame psyche.

 

I'm taking a break to do a rediculously simple game in bB. Something I can't possibly run of resources for or give up on. No, really this time. Then I'll come back to this and see what can be done.

 

Ok so stay tuned for Jelly Baby, my most simple and tiny and not innovative project ever. It even features a giant octopus made out of huge chunky playfield pixels. The whole game looks like something an angry three year old drew on construction paper. Maybe that's more my style anyway...