jbs30000

Holly crap, I think I got it. I changed b = (player0y-3)/8 to b = (player0y-6)/8 when the cycle is driving down and it seems to work. Finally, after a couple of months, I finally did it. I can finally move forward with this game. (Did I say finally enough times? )

There are two sprites, 8 pixels wide, and as high as you want them to be (not sure what the limit is), two missles, 1 pixel high and 1 to 8 pixels wide, and a ball, again 1 pixel high, 1 to 8 pixels wide. For your other questions, this site http://www.randomterrain.com/atari-2600-me...c-commands.html should have all your answers. Specifically for the collision http://www.randomterrain.com/atari-2600-me....html#collision Hope that helps.

As some of you might know, I've been working on a bB version of the Tron arcade game. I made a, we'll call it a beta version, and asked for feedback. One of the things mentioned was how jerky the light cycle game is, so I've been trying for a few weeks, hell, actually it's more like a couple of months now, to make a good light cycle game. Yesterday I made a basic light cycle test program where I'm very, very close to having a decent light cycle routine. The light trace is made up of playfield pixels appearing behind the cycle as it drives. What I've settled on for a crash test is to place a missile at the front end of the cycle and test for a missile/playfield collision (see if a playfield pixel is right in front of where the cycle is headed towards). I need the front of the cycle to be clear, like in the first pic, since having what you see in the second pic will lead to a false crash. Moving the cycle up, left, and right is fine. But I can't move it down with the playfield pixels being drawn past the car. So, any help with the code I'm posting would be most appreciated. Thank you. P.S. Things work fine if I have the cycle move 8 pixels up/down/left/right, but that makes it move too fast and is part of the reason why the cycle movement was jerkey the last time. Cycle going up, light trace is fine..Cycle going down, light trace going past the cycle Test.bas Edited to correct spelling error.

Actually, it looks like taking batari's advice about dividing the y position by 8 instead of 3 and then working on the values to add or subtract inside the parenthesise is working out fairly well. Thanks.

Thank you for your responces so far. As for what playfield I'm using it's the default 32x12 playfield. I'm asking about this because while trying to work on my final version of Tron I am having a horrible time trying to draw a light wall behind the light cycles as they drive. I was about to give up as I have been spending weeks on the problem and allways comming close to, but not being completely sucessful, until I thought about the draw program and figured that maybe I could give that a try. As for the sprite, the light cycles are 6 pixels high and 6 pixels wide. Here are a couple of pics to show what they look like. Edited this post to add that I'm using the standard kernel in answer to SeaGtGruff's question.

Seeing as how I just completed a term of college level algebra I probably should be able to figure this out, but I can't. In the sample program draw.bas to place a playfield pixel where the sprite is, these calculations are used: g=(player0y-7)/3 h=(player0x-10)/4 Now this is for a 32x32 playfield. What needs to be changed to make this code work with a 32x11 screen? Thanks.

Thank you both. And batari, I'm especially greatful for the 50 dim warning.

Say at the beginning of the program I go dim MyVar1=a and then somewhere else in the program I do MyVar2=a I can now use either to access a right? Also, say instead of using MyVar2 I do something like MyFixed=a.b Now, I can use MyVar1 to access a as an integer and MyFixed to access a.b as a fixed number, right? Thanks.

Two bytes doesn't sound too bad. But anyway, thank you for answering my question.

Just out of curiosity, why do bB games have the score at the bottom, when the majority of 2600 games have the score at the top of the screen? Also, is there a way to move the score to the top? Thank you. P.S. I'm not complaining or anything, I'm just curious.

I do this all the time. A slightly different way I do it than what Glenn Jupp said is to first set the score to where the sprite is, so if you have player0x = 80 and player0y = 10 then set score for 80010 then, when you move your sprite to the left 1 unit (player0x = player0x - 1) then go score = score - 1000 from score, or if you go right then score = score + 1000. If you go up then of course it's score = score - 1 or score = score + 1 for moving up. Oops, I'm editing this post to say that after looking at Glenn's post, I guess I just repeated what he said. My mistake.

Wow, that's pretty cool . This will definitely come in handy.

Oh, Jbs, I'm sorry.... I scrolled up too high, and accidentally referenced the post above you instead... Please don't take offense... I didn't mean to dis' you in any way.... I'm REALLY REALLY friggin' tired with all this wedding stuff going on! My bad... a typo form lack of sleep... I'd still like to do the music for you, if you are still interested.... I apologize again! I knew that didn't seem right when I said it... Thanks, Mike No problem, I wasn't upset, just confused. And yes, your muisc contributions are allways appreciated as they will help make the game seem a little more realistic, and a little more interesting. And I can wait a week or two until your honeymoon is over before getting more music

Hang on there, Dan.. I've got more music comin'... I'm getting married in a couple of weeks, so I'm a bit distracted... But, I'll get more music out to you as fast as I can... Thanks, mike Uhm, thank you, and congradulations, but my name isn't Dan.

Minor update. Since I'm using 32K in my 3rd attempt at this program, I've been able to make a couple of improvements. In the tank game, the tanks move slower, and the enemy tank(s) not only shoot at you if you're within range, but it/they will also chase you. However, they all share 1 missile, so if you're playing against 2 or 3 of them, only one of them can shoot at you at a time. After trying various methods of fixing the scanline problem in the MPC Cone game, I had to switch to using sprites for the blocks. This has one problem though, it's a little too easy to win. Although I think making the blocks drop faster will help with that. Also, since lord_mike contributed the music that is made when a coin is added, I decided that at the beginning of the game, and every time the main menu is showing, pressing select will be like adding a coin. You'll get an extra guy and the music will play. I also made a screen that will show at the very beginning of the game and every time you loose all your players. It's a privative (due to the low res graphics) replication of the arcade game screen that shows when there's no credits. It has a crude drawing of the MPC Cone with 1 C on the left, and P P on the right to mean 1 Credit Per Player. And on the bottom left is C and the bottom right 0 for Credits 0. Here are the actual arcade graphics Right now, when you lose all your lives, the game ends. I will add a screen where you have a chance to continue. So anyway, test out the two games (They're all I've completed). To play the tank game, after starting the game and pressing Select at least once, move the joystick up. For the cone game, move the joystick right. Tron3.bas.bin

Don't finish it up, just yet. I've got more music stuff for you coming soon! Thanks, Mike Thank you, I really appreciate this. Eventually I'll start learning how to make music. Actually, I'll be able to study your code and learn from that.

Wow, that is awesome.

I didn't mean that you were knocking Stella, but rather that we (you and I) were kind of pointing out that it has some glitches in the TIA emulation-- well, you were discovering that, and I was pointing it out. So I wanted to put in a good word for Stella, too. As far as testing on real consoles, you don't have to do it yourself if you don't have the means-- and even if you *do* have a programmable cart, you might not have every variety of Atari 2600 console or compatible console. So by posting the ROM image for your game(s) in the AtariAge forums, you make it possible for others to load the ROM into a programmable cart (if they have one) and play it on a real console-- which is a way for you to get your game(s) tested on real equipment, and on a *variety* of real equipment. Of course, most people will be playing the ROM images on computers with emulators, and they can give you feedback about any glitches they find, or make suggestions for changes they'd like to see made-- although you, as the game programmer, can choose whether to implement or ignore those suggestions. It's all part of the play-testing phase. That's the beauty of sharing your workd-in-progress on AtariAge-- you have a large audience of Atari lovers who will be more than happy to play-test your games for you! Michael PS -- Another way that AtariAgers can help is if you're developing a version of your game for a console and TV system that you don't actually have access to. For example, if you're developing an NTSC version, but you want to make a PAL version too-- or maybe even a SECAM version-- then you can of course play the PAL or SECAM version on an emulator, but you might also want to make a special request for anyone with the means to do so to please test the game on an actual PAL or SECAM 2600 and TV. Then they can give you feedback about the colors, or about any differences in the sound. Thanks for all of the advice. The biggest thing I'm learning about this is that I shouldn't have started off with such a big project. Oh well, at least it's almost done.

Stella has some glitches in the TIA emulation that are being corrected. But you need to be cautious about z26 as well, and about emulators in general. Despite the fact that z26 is perhaps the best of the Atari 2600 emulators as far as emulation accuracy is concerned, there may be certain things that z26 will let you get away with that won't work on a real Atari 2600. No emulator is perfect, and (as I found out the hard way with "E.T. Book Cart") testing your programs on the various emulators is not a good substitute for testing them on a real Atari. In fact, it's a very good idea to test your programs on as many different kinds of Ataris as possible-- heavy sixers, light sixers, four-switchers, juniors, or even 7800s, etc. And since Stella is sort of taking it on the chin in this thread, I'd like to add a comment in favor of Stella-- namely, that it has a wonderful debugger, which you should learn how to use, because it can help you track down funky errors in your programs. Michael Sorry, didn't mean to knock Stella. And I don't have a real Atari, and even if I did, I don't have an EProm burner or any of those programmable cartridges like Krokodile, so I can't test anything on a real atari. I'm thinking about buying these things sometime down the road, but until then, all I have are emulators.

Rather than litter this thread with individual replies, I'll just give my replies to the other posts in this one. CurtisP, right now I'm working on the Tank game, which is the only game I think was running too fast, so I did slow it down some. atari2600land, there's now a delay of roughtly 2 seconds or so whenever the main menu is brought up. Gorf and Lord Helmet, thank you for the compliments Jess Ragan, I don't know. I might take a break after this game. It turned out to be a bigger project than I anticipated. And, wow, I haven't thought about the Journey arcade game in ages. s0c7, I'm making a quick edit to this post. I origionally asked a few questions about what you meant, but a moment ago I downloaded Z26 and ran the program on it, and pretty much everything you're saying became crystal clear. I'm surprised that Stella is letting me get away with things that won't work right on a real Atari. Anyway, thank you for your post, this helps out a lot.

Here's code for the intro theme. I'll work on the other music, too. I've kept is as short and simple as possible, 'cos memory is still somewhat limited. the high pitch is necessary to keep it in tune using the same distortion register. Let me know what you think. tron_music_intro.bas tron_music_intro.bas.bin Thanks, Mike Wow, awesome! And making it so high pitch makes it sounds so, Atari like . And now, you name is added to the list of credits. For a total of....two people who have contributed code to this game, you, and me

The games seem to run a bit fast. I don't remember the arcade Tron moving that fast. Or maybe I'm just slow and old. Yeah, some of them do run kind of fast. I'll see what I can do about that.

Say, do any of you who've downloaded the files have any comments? Any bugs or errors I missed? Anything that's not an error but could use improving? I'd love to hear your opinions so that the third and final release of the game will be a good one. Also, if anybody could write some code for any of these sound effects or music clips, I'd greatly appreciate it. I'm not very good at sound, and the sound effects I put in the game are basic, one note sounds that took a lot of trial and error to come up with. Anything complicated, forget about it. Jerry's Sound Page Thank you.

Well, 32K is kind of bigger than I need actually, but there isn't an option for 20K, 24K, or 28K, so since I ran out of memory at 16K, 32K is my only other option.

Your first Atari game may the most ambitious and advanced BatariBasic game yet! Great stuff!!! If you need help with music (if you can fit it in), let me know... Thanks, Mike Thanks. The sounds that would be needed to make it be like the arcade are here Jerry's Sounds Page, but I'm thinking most of them are too complicated for the 2600.