jbs30000
-
Content Count
486 -
Joined
-
Last visited
Posts posted by jbs30000
-
-
I'm 75% complete now. Except for some minor finishing touches I've completed 3 out of the 4 games.
There's the MPC cone game where the cone decends and there's some sound effects, unlike the first release where I raised the player instead and had no sound effects. The player sprite is also better. Also, for each level of difficulty (3 total) the cone drops at faster speeds.
The tank game is done. It's pretty much the same, except that the sprites are slightly better, there's sound effects, and for each level of difficulty an enemy tank is added (level 1, 1 tank, level 3, 3 tanks).
I just completed the light cycle game. I need to work a little more on what happens when you win or lose the game, and I need to add sound effects, but other than that I'm pretty much done. There's a bug where if an enemy light cycle is going upwards, and it's in the upper left hand corner, two spaces away from crashing, it'll crash anyway (hard to explain, but you'll see). I'm not sure if I'll be able to fix that or not. Also, when an enemy cycle crashes, all light traces vanish, not just its own. This isn't a bug, it's just that I don't know how I'd be able to only erase the crashed cycle's light wall given the limited amount of memory to work with.
All I need to do now is finish the grid spiders game. This will be the most difficult, because I'll either need to try and duplicate player1 9 times or player0 4 times and player1 6 times (3 digits for the counter, 3 spiders on the left, 3 on the right, plus the player) or else use playfield blocks as spiders, or.... Well, anyway, I've got my work cut out for me.
Also, this week I've started Spring term in college full time, so I have less time to work on this, but I'll try to be as quick as possible. I'm really hoping my first attempt at an Atari game turns out to be a good one.
-
I like what you've got so far! It's about time there was a proper TRON Arcade game ported to SOME system! (I know it's in the GBA Tron 2.0 game, but it's a hidden game.)
Well, it'll be about as proper as I can do
, but I will release the code when I release the finished program so that others can work with it to make it even more closer to the origional. -
OK, minor update, I now have 50% of the game done. The Tank and MPC Cone games. I have sound effects for them, although I don't have a sound effect for either tank firing at each other, but I do have the low rumble and the beep beep that's constantly in the background. In the cone game the boomp sound that's made as the blocks rotate is similar, but compared with original, noticeably different, and the sound of firing the disk sounds different too.
I'm going to start the grid spiders (or sometimes called grid bugs) game now. And I'll probably have to start completely over with the light cycle game after that.
-
OK, I've been going about this all wrong. I pulled out the code for the light cycle game and placed it in its own program. Everything runs real slow, but it runs. You can control the blue (player) light cycle and there are 3 yellow enemy cycles.
There's a timer that every 5 seconds (and also every 3 if you're holding down the trigger) will call the routine to move the blue cycle, then the enemy cycles.
The way I have it now, the enemy cycles are move twice. The first is just to check for collisions, and the other is the actual moving of the cycle. However, this doesn't quiet work, and one cycle crashes almost instantly, and one of the others, or both, sometimes drive outside the square border surrounding the playfield.
Anyway, all the code's here, so if it's still to hard or complicated, I'll just scrap it and start from scratch.
-
I'm experimenting with using the Superchip so the playfield pixels can be smaller, and using smaller light cycles (4x4 instead of 8x8-- or really 6x6, since you've got blank rows and columns on all sides of the players). But I have to go to bed now, so I won't be able to post any suggestions until Friday night.
Michael
After I finish (if I can finish) my game using the standard kernel, I'm going to make another using the superchip. I already remade the playfields using 32x32 screen, so the main screen looks better (although I couldn't make it look like the origional) and the tank screen will look just like what's in the arcade game.
-
Yeah, it is pretty complicated. I shouldn't have posted it probably.
Hey, I know, just ignore everything in the second code box. Just use what's in the first.
Basically, for the cycle, there are two variables to hold the X and Y positions. X is any value 0 to 14 and Y is 0 to 8. To place the cycle on the screen player0x is PX[X variable] and player0y is PY[Y variable].
For the light traces the same X and Y variables are used, but with the LX and LY data statements: pfpixel LX[X variable] LY[Y variable] on. Also, since a light trace is two pixels side by side, then there's an additional pfpixel LX[X variable + 1] LY[Y variable] on.
So, logically, if you're checking for light traces, all that should be required is a variable to be one more or one less......for example, to check for a light trace above the cycle it should just simply be a case of pfread(LX[X variable], LY[Y variable - 1]), but that kind of checking doesn't seem to work.
There, that was a lot shorter and less complicated than in the first post.
-
First off, forgive me for how long this is going to be. It's increadibly rare for me to write a post this long.
OK, so I'm working on the Light Cycle game for the Tron game I'm making. I have the perfect code for moving around the player, but for the past 3 or 4 days I've not been able to make a decent collision check for the enemy lightcycle(s).
So a few minutes ago, I pulled out some code and placed it in a new file. All it's supposed to do is draw a light cycle and then two playfield blocks side by side underneath it.
Since the standard playfield block is 4x8 pixels then the light traces are 2 pf pixels togeather so that the light walls will be 8x8. In order to move the player and the enemies I have a data lookup table of X and Y locations to place the light cycles (PX and PY) and the light traces (LX and LY)
All right, so, here's the code from the test program. When I run it, the playfield: command should cause a wall on the left side, but instead I get some pixels seperated by a space of 2 or 3 pixels, instead of a continuous line. Then, if I take out the + 1 from NextY = LY[Enemy1y] + 1 then the playfield pixels line up under the light cycle just fine, but add the + 1, and there's only partial playfield pixels underneath.
Of course, if you run this program, and everything looks like it should, then maybe I have a/some corrupt DASM or bB files and need to redownload them. Anyway, here's the code:
set kernel_options pfcolors no_blank_lines set smartbranching on dim CurX=a dim CurY=b dim NextX=c dim NextY=d dim Enemy1x=e dim Enemy1y=f data PX 21,29,37,45,53,61,69,77,85,93,101,109,117,125,133 end data PY 15,23,31,39,47,55,63,71,79 end data LX 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29 end data LY 1,2,3,4,5,6,7,8,9 end data HC 10,8,6 end playfield: X............................... X............................... X............................... X............................... X............................... X............................... X............................... X............................... X............................... X............................... X............................... end COLUPF = 254 player0: %00000000 %01111110 %01100110 %00100100 %00100100 %01100110 %00111100 %00000000 end rem Enemy1x = 5: Enemy1y = 5 rem player0x = PX[Enemy1x]: player0y = PY[Enemy1y] rem NextX = LX[Enemy1x]: NextY = LY[Enemy1y] + 1 rem pfpixel NextX NextY on: NextX = NextX + 1: pfpixel NextX NextY on Main COLUP0 = 64: scorecolor = 14: COLUPF = 254: drawscreen goto Main
Also, if I could have some advice on colliison detection, I've tried a few different things but with no luck. Since I only want to draw the screen when moving the cycles, as oppsed to when I'm checking for collisons, I try to check for playfield pixels. For example, if the cycle is moving up, then I check for pixels above it. If there are pixels then I check to the left, and if there are some there, then to the right. If the enemy will collide no matter what, then I keep it going in the direction it's already going and let it crash. However, I can't do it right. This wil make this long post even longer, but I'll show the variables I use and what they mean. This is all probably needlessly complicated, but here's code for checking the first light cycle
First, the code MoveLC1 if Enemy1y = 0 then goto MoveLC2 Arg1=(Direction&Enemy1)/4: CurX = Enemy1x: CurY = Enemy1y: gosub ELCCT Direction=(Direction&Enemies23)|(Arg2*4) Enemy1x = Enemy1x + NextX: Enemy1y = Enemy1y + NextY ELCCT on Arg1 goto CTU CTD CTL CTR CTU gosub DLTU: if Arg2 = 0 then NextX = 0: NextY = 255: return thisbank gosub DLTL: if Arg2 = 2 then NextX = 255: NextY = 0: return thisbank gosub DLTR: if Arg2 = 3 then NextX = 3: NextY = 0: return thisbank Arg2 = 0: NextX = 0: NextY = 255: return thisbank CTD gosub DLTD: if Arg2 = 1 then NextX = 0: NextY = 1: return thisbank gosub DLTL: if Arg2 = 2 then NextX = 255: NextY = 0: return thisbank gosub DLTR: if Arg2 = 3 then NextX = 3: NextY = 0: return thisbank Arg2 = 1: NextX = 0: NextY = 255: return thisbank CTL gosub DLTL: if Arg2 = 2 then NextX = 255: NextY = 0: return thisbank gosub DLTU: if Arg2 = 0 then NextX = 0: NextY = 255: return thisbank gosub DLTD: if Arg2 = 1 then NextX = 0: NextY = 1: return thisbank Arg2 = 2: NextX = 255: NextY = 0 CTR gosub DLTR: if Arg2 = 3 then NextX = 1: NextY = 0: return thisbank gosub DLTU: if Arg2 = 0 then NextX = 0: NextY = 255: return thisbank gosub DLTD: if Arg2 = 1 then NextX = 0: NextY = 1: return thisbank Arg2 = 3: NextX = 1: NextY = 0 DLTU DLTD DLTL DLTR Direction holds which way all the cycles are moving. {0}{1}Player {2}{3}Enemy1 {4}{5}Enemy2 {6}{7}Enemy 3 The bits work like this 00 = Up, 01 = Down, 10 = Left, 11 = Right. For each cycle, the directions are divided by 4, 16, or 64 so that Arg1 holds 0, 1, 2, or 3 (Up, Down, Left, Right). Then, in ELCCT (Enemy Light Cycle Collision Test) check 3 directions depending on which way the cycle is going. In CTU (Collision Test Up) check up, if there's a light trace there, then check left, if a light trace is there, then check right. If a light trace is there, keep going up. For CTL check left, if a light trace is there, then check up and down. Etc... Returning from this sub, Direction is updated and Enemy1/2/3X or Enemy1/2/3Y is increased or decreased accordingly. The problem is with writting a good routine for DLTU/D/L/R (Detect Light Trace Up/Down/Left/Right). What I've tried to do is place the locations to check out in NextX and NextY and either return Arg2 with the direction to go if the way is clear, or 255 if there will be a crash. Basically, say to check for light traces above the the cycle, I'd go something like: NextX = LX[CurX]: NextY = CurY - 1: NextY = LY[NextY] then use pfread(NextX, NextY) to see if a playfield pixel is there. And, to be safe, maybe increase NextX by 1 and check again since the light walls are made up of 2 pixels across.Anyway, if you read all this, and I explained everything clearly
any and all help would be appreciated. Thanks. -
I'm working on the cycle game right now. I noticed that problem too and will eliminate it in the version I'm working on.
-
I've toyed with it a little, so I can answer a couple of your questions.
A) Yes, the playfield works just fine.
B) I couldn't get pfcolors to work right and I didn't try pfheights.
Hope that helps a little.
-
Minor Update.
It took me about a week, but I finally finished.....the tank game. I had to rewrite the sucker about 3 or 4 times but it's finally done. I focused on that because it's the hardest game for me to write. With maybe the exception of the grid spiders game, all the rest should be a peice of cake.
Let's see, other than that. I redid the Tron sprites and the tank sprites. I read that in the arcade version, there's like, 11 or 12 levels, mine only has 3, but when I post the program here, I'll also post the code so anybody who can improve it will be more than welcome. I toyed with trying a superchip version so that I can use a 32x32 screen for backgrounds that are more faithful to the arcade, but I have to rearange some code because simply adding an SC to the romsize gives me a blank screen. Anyway, here's a couple of pictures. The first is from the tank game, and the second shows how I've redrawn Tron himself. I tried doing a print screen to capture the third level of the tank game, since it has 3 enemy tanks, but only 1 tank shows (and not that it makes a difference, but I'm not using the multisprite kernel).
-
atari2600land basically I use a timer to count down from 9 to 0 and then jump to a sub that uses rand to choose a game. The code for the routine is:
TimerChoose
b = rand
if b <= 64 then goto ChooseUp
if b <= 128 then goto ChooseDown
if b <= 191 then goto ChooseLeft
if b <= 255 then goto ChooseRight
SeaGtGruff That's very interesting, and good to know. Since I only use an emulator I will do multiple instances of rand. Thanks.
-
I seem to be running into a problem using rand in a multibank game. In the first Tron, in the grid spiders game, I had 6 grid spiders that moved around using rand, yet, when I integrated the game into the main Tron game, which uses 14K, all of a sudden rand didn't work any more and the spiders just stayed in the same location.
In my second version of Tron that I'm working on, so far using 8k, I'm trying to use rand when the timer in the main screen runs out to choose a game for the player. However, every time I test this out, the same game allways gets chosen.
Is this a known bug or something? It doesn't make any difference if I use set optimization inlinerand either.
-
Jess Ragan, Vic George 2K3, tjb, and haroldop, thank you very much.
Besides getting rid of all the problems from the first version, I'm also doing everything I can to make the game come closer to matching the arcade. Looking at the message board, in the Hombrew Discussion they're talking about a 2600 version of Tron and one of the things someone mentioned was doing the dual set up of the joystick to move the player and use a paddle to move the arm just like the spinner does in the arcade version. I'm really thinking about doing that even though it'll be slightly more complex and involve a lot more sprites. Although I'll probably finish this version that just uses the joystick first and then do the joystick/paddle combo as another release.
Oh, and something I could use help on, music and sound effects. I was able to get a simple beep when the tanks fired at each other, but I don't know how to do anything like car or tank moving noises, if anybody could help me with that, I'd appreciate it. And if I knew how to read sheet music, I'd find some from the arcade and use WebTune2600 to play it on the Atari.
Oh, and mos6507, I'm definitely planning on making the MPC cone drop down. In the last version I used a variable to hold which row to start rotating the blocks. At a regular timed inverval, I would use pfhline to turn off all the pixels across the bottom of the screen, then scroll the screen down by 1 and increase the variable. But for some reason not only did the blocks not rotate right after the first scroll, but I couldn't scroll the screen down more than 3 times. But at any rate, in this version I'll just do things somewhat differently and drop the cone down.
-
Nicegreetings gambler172
Thanks.
-
Can we have pics of your progress posted, please?
I assume you're talking about my program. I tried to put one in the announcement post, but got a strange error. I'll try again. Here's the new...I guess it would be a main menu. It's the same, except I've added a counter in the middle that, just like in the arcade game, will count down and then choose a game for you if you don't select on yourself.
Also, I changed the score graphics so that the numbers are like those in the arcade game, and I included the life counter and defined the life counter sprite to, again, look like what's in the arcade game.
I tried to move the life sprites over using dim lives_centered=1, but it didn't change their position at all.
-
When I studied the asm for assigning sprite designs for players 0 & 1 I noticed something interesting. I noticed that a .data 0 is added to the sprite data statements so that the player0height or player1height matches the number of rows after a player0: or player1: statement, but I'm just curious why since
data LightCycleUp %00011000, %00100100, %01100110, %01100110, %00100100, %01100110, %00100100, %00011000 end BlueSpriteUp asm LDA #<LightCycleUp STA player0pointerlo LDA #>LightCycleUp STA player0pointerhi LDA #7 STA player0height end
seems to work just fine.
That's a really good question. The zeros were needed at one time (i.e. before VDEL was used in the kernel), and although they aren't technically needed anymore, removing them would have shifted all sprites down by one pixel, so it was left in for reverse compatibility.
But now that you mention it, there is probably a better solution that may take a little space to implement but will save one byte for every sprite, so I'll look into this.
Wow, I might have actually made a difference, I fee so honored
.Of course at one byte per sprite, people may not notice a difference unless they have a bunch of sprite definitions in their program. But I still want you to go ahead and see about changing this, so that I can claim the credit for the idea
-
I'm using 2 banks and I thought that maybe each bank would have 26 variables each, but after testing this, I found out that a-z seems to be universal, or only apply to bank 1. Even though I'm studying the asm output fom the bas files I compile, I'm still not that familiar with 6502 assembly or the 2600 memory layout, but I'm sure that there must be memory in each bank that I can use for variables using inline assembly.
Here's a very simplified memory map of the Atari 2600 VCS (I'm using hex addresses):
$0000 to $002C = TIA chip
$0080 to $00FF = RAM (RIOT chip)
$0280 to $0285 = I/O (RIOT chip)
$0294 to $0297 = Timer (RIOT chip)
$1000 to $1FFF = Cartridge slot (4K)
Due to the way the 6507 CPU is designed (i.e., with only 13 address pins instead of 16 address pins), it can address or "see" only 8K of memory, therefore the rest of the 64K contains mirror images of the primary 8K address space. And due to the way the TIA and RIOT chips are designed-- especially the way they're connected to the 6507's address pins-- the memory locations which are shown above for the TIA and RIOT chips are mirrored throughout the primary 8K address space. But all of that mirroring doesn't really matter as far as your question is concerned-- I'm just trying to give you a very simplified picture of how the 2600's memory is mapped out, without going into too many details.
So what you have are 128 bytes of RAM at addresses $0080 through $00FF, and 4K of cartridge ROM plugged into addresses $1000 through $1FFF. To create an 8K game, you need to use some kind of bankswitching to swap the ROM. Most 8K carts use a bankswitching method that swaps out all 4K of the cart memory area, although some bankswitching methods swap smaller banks (e.g., 2K banks or 1K banks).
Anyway, the RAM and ROM are in two completely different areas of memory, and swapping between two or more ROM banks to get carts that are 8K, 12K, 16K, 32K, etc., doesn't have any effect on the RAM-- you're still stuck with only 128 bytes of RAM.
However, some carts have extra RAM added to them. As far as I know, only bankswitched carts have any extra RAM (i.e., no 2K or 4K carts were ever produced with extra RAM in them)-- but don't assume that bankswitching automatically adds extra RAM, because not all bankswitched carts have extra RAM. Some of the schemes that add extra RAM have a set amount of extra RAM that's always in the same spot within the cart memory, and the extra RAM never changes as you swap banks. This is how the Superchip works-- it adds 128 bytes of extra RAM at the beginning of the cart area, and those 128 bytes of RAM do *not* get swapped as you swap banks. But there are a few bankswitching schemes that add multiple *banks* of extra RAM, and you can select between those RAM banks the same way you can select ROM banks. The classic example would be M-Network's E7 bankswitching scheme, which has a 1K RAM bank that can be selected at one area of the cart memory, and four separate 256-byte RAM banks that can be swapped around at a different area of the cart memory. On the other hand, the new 4A50 bankswitching scheme has 32K of extra RAM that can be swapped around at three different memory areas in chunks of 2K, 1.5K, or 256 bytes of RAM.
As far as batari Basic programs are concerned, the only "official" way to use any extra RAM at this time is to specify the Superchip option in your program, which doubles the amount of available RAM by adding an extra 128 bytes of RAM. A while back, I unofficially modified batari Basic version 0.35 to allow M-Network's E7 bankswitching scheme to be used, but there are three drawbacks to using that modified version: (1) it doesn't include the enhancements that were made to batari Basic after version 0.35; (2) it was a bit cumbersome to use; and-- most importantly-- (3) there are no modern homebrew carts that replicate the M-Network E7 bankswitching method, so if you write a game using that method, you won't be able to produce carts and sell your game!
Thus, at present the best way to get more RAM variables in your batari Basic games is to specify the Superchip option. All you have to do is add "SC" to the romsize, as follows:
For an 8K game that uses the Superchip:
set romsize 8kSC
For a 16K game that uses the Superchip:
set romsize 16kSC
For a 32K game that uses the Superchip:
set romsize 32kSC
Be sure to read the version 1.0 documentation for information on how to use the Superchip RAM.
Note that if you create a batari Basic game with the Superchip option, you *can* have carts made and sell your game, because there are modern homebrew boards available with the Superchip!
Michael
Holly cow, so much detail in that post, you really know your stuff.
Well, I might have a use for the Superchip option in the future, but for what I'm working on now, I think the 26 variable limit will do.
If you don't mind, I have one more question, which is neither here nor there, I'm just asking out of curiosity.
When I studied the asm for assigning sprite designs for players 0 & 1 I noticed something interesting. I noticed that a .data 0 is added to the sprite data statements so that the player0height or player1height matches the number of rows after a player0: or player1: statement, but I'm just curious why since
data LightCycleUp %00011000, %00100100, %01100110, %01100110, %00100100, %01100110, %00100100, %00011000 end BlueSpriteUp asm LDA #<LightCycleUp STA player0pointerlo LDA #>LightCycleUp STA player0pointerhi LDA #7 STA player0height end
seems to work just fine.
-
Ram memory and Rom memory are 2 seperate animals.
Well yeah, I am aware of that. I've done programing for fun off an on for years, just not for an Atari, or 6502 CPU for that matter.
While you can bankswitch to your heart's content (within reason) to make more rom space as long as you keep within the boundries according to that bankswitch scheme, the same is not true for Ram. The 2600 itself only offers 128 bytes of user ram...with some bits a little higher that can be configured to read/write...and that's if you are programming in pure assembly.
OK, I understand, each bank is just ROM, rather than a mix of ROM and RAM. Makes sense.
The ram variables are read/written the same way regardless of what rom bank you are in. So you need to try to reuse ram wherever you can. Got a variable that doesn't apply to this portion of the game? Reuse it for something else. Got a variable that only holds a value of 0-3? Use 2 bits to hold it instead of the full 8-bit byte.
Yeah, I'm familiar with all that already. Only having 128 bytes (or 26 bytes using Batari Basic) isn't going to be a problem.
Thank you for answering my question.
-
This is the second time I'm typing this, the first attempt to post this got eaten up.
I made an Atari 2600 version of the Tron arcade game. It was a rush job, so it's riddled with problems, but I'm in the middle of working on a second version which won't only fix these problems, but also add some things, like score keeping
.Also, I have a question. I'm using 2 banks and I thought that maybe each bank would have 26 variables each, but after testing this, I found out that a-z seems to be universal, or only apply to bank 1. Even though I'm studying the asm output fom the bas files I compile, I'm still not that familiar with 6502 assembly or the 2600 memory layout, but I'm sure that there must be memory in each bank that I can use for variables using inline assembly. So if anybody can help me out, I'd appreciate it. Thank you.
-
1
-
-
Oh, and for some reason, when you shoot, if you move your player, the missile changes direction until you stopFrom first glance, it appears that your player movement lines are causing it:
PlayerLeft
player0x = player0x - 1: missile1x = missile1x - 1
if joy0up then Sprite_PTR = 0: goto West else Sprite_PTR = 1: goto NorthWest
PlayerRight
player0x = player0x + 1: missile1x = missile1x + 1
Since the missile's initial location is already set up when you fire, is there any particular reason that updates are happening on these lines?
D'oh! That's code that was supposed to be eliminated earlier on. Guess I wasn't paying enough attention. Thank you.
-
Until someone is awake to help you, I wonder if this thread might be useful:
That's a good thread to detail one of the biggest differences between the 2600 and other platforms. Using an empty loop to consume time is pointless, because the display MUST happen at regular intervals. Instead, you check a frame counter (# of screens drawn) against another value to see if the movement portion of the game should be executed. This other value can be static, or variable amount.
With the game it's based on, you'd probably want it to be a variable amount of frames to skip movement on (so it gets faster as you progress to higher levels). If you already have a level counter set up, this wastes no additional ram...you could just read the check value from a table in rom (using the level # as an index).
Right now I'm keeping things,well basic, no pun intended. For the moment all the games don't get harder, you either win or lose and then go back to the main screen where you can choose to play them again.
After I finish this and the spider game I'll post the whole thing, then go back and rewrite the code for each game, pretty much from scratch to make it more efficient (the tank code is horribly bloated) and to make each level harder.
Anyway, I think using a frame checker will help solve another problem I've been trying to figure out. I've been trying to figure out how to time the cone dropping downwards like it does in the arcade game. Thanks.
-
Until someone is awake to help you, I wonder if this thread might be useful:
Thanks, I'll take a loot at it.
er, look at it, I mean.
-
Until someone is awake to help you, I wonder if this thread might be useful:
Thanks, I'll take a loot at it.
-
P.S. A big well duh, but if you download this, compile it and play it. You can move the player and shoot the blocks. You'll then see how horribly fast they rotate.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
bB Tron release 2
in batari Basic
Posted
I finished the second version of the Tron arcade game, but there's still some major bugs, so I need to make a 3rd release, using 32K, because I discovered that 16K isn't enough. And it's funny, but during this game, things stopped working the bigger the program got. I had to start switching to actual numbers instead of relying on constants for instance.
Anyway, some major bugs.
1) When you win the tank game, the game goes blank and hangs.
2) The grid spider game doesn't count down the clock, because, while it worked at first, when I added the spiders, going to the clock countdown routine then caused the program to go back to the main menu
.
3) Also, I didn't have enough memory left to cause the player to loose the game should they hit a spider.
4) The light cycle controlled by the player has its sprite change while driving (you're moving up and it switches between up and left, for example, but it still drives up.) And this isn't a bug, but I need to improve control for driving the light cycle.
5) Since the game hangs if you win the tank game, you can't advance all 3 levels. So I compiled a game for each level.
6) There's problably one or two more that I'm blanking on.
Now, despite all those problems, I think what I've accomplished so far is pretty cool. All I need to do, is rewrite it using 32K, and it should be all set. Please, let me know what you think so far. Thank you.
Tron2L1.bas.bin Tron2L2.bas.bin Tron2L3.bas.bin