Lodmot

Okay, now the game is running great, and I even got AI working properly, with the same physics as the player car.

I actually saw it on a youtube video, here: (skip to about 7:04) http://www.youtube.com/watch?v=ONvf11l-wbY And those two pictures.

Take a look at this: Why.... it appears to be a heavy 4-switcher! Here's another picture, to kinda prove that I'm not making this up: Has anyone else noticed this? Are there any heavy four-switcher Atari's? Or... did they just simply use the heavy sixer picture and paint out the two other switches?

Alright... I think I effed up xDDD I tried implementing AI into my game today, and the whole thing runs extremely slow now. I should probably refrain from bit operations for a while. 8D I was hoping to get 3 cars all with working physics and AI on the screen at once, shooting each other and what not, but it's starting to look like an impossible feat. I wish there was a way I can figure out how many CPU cycles my game is using up.. Guess the Atari 2600 wasn't exactly prepared for a game like Twisted Metal. xD

Alright, I've finally finished re-writing the game with the new variable and bit aliases that I laid out for the game. And low and behold................. it works perfectly! No slowdowns whatsoever. :3 Now I feel a lot better about being able to make this game. I plan on just doing it a little at a time, and I'm gonna be doing a lot of testing on my real Atari in between. Best thing to do is get the basics done first, and then once everything is working solidly then I could start adding in nice little extras like explosions or sounds.

Okay, that's good. I think ill be okay. I pretty much have all the game mechanics in there that its going to have. The game is going to be a 16k rom, and I still have yet to use up the first bank, so rom space isn't a problem. I can also set speed optimization and write a bit more code to detect whether a bit needs to be changed or not, so the game isn't unnecessarily setting the bit value when it doesn't need to. Hopefully that would save the CPU a bit. I don't understand why setting individual bits would take more cpu than setting regular variables though. Id figure it would take less cpu for setting single bits, since the game would only be setting one bit rather than 8 bits at one time, you know?

I should have been more precise... "converting your variables to use bits instead of bytes". Not a whole lot. The main wrinkle is you that you read from one location of superchip memory, and write to another. So to add 10 to a superchip variable you'd do something like... set romsize 8kSC dim spaceshipx_r=r100 dim spaceshipx_w=w100 spaceshipx_w=spaceshipx_r+10 I think I may have been converting the variables from bytes to bits all along. Now my code is looking more like this: rem Setup Variable and Bit Aliases dim P1_Acceleration=a def P1_Speed1=b{0} def P1_Speed2=b{1} def P1_Direction1=b{2} def P1_Direction2=b{3} def P1_ResistanceDir1=b{4} def P1_ResistanceDir2=b{5} def P1_MissileDir1=b{6} def P1_MissileDir2=b{7} dim P1_Velocity=c dim P1_Weapon=d Not sure if that's what you meant. I'm just trying to avoid confusion by giving each individual bit a name. Those were all separate variables at one point, so that's when I thought maybe just using individual bits for each asset would help. Also, giving aliases uses more ROM? I was kinda hoping that the compiler would convert all the aliases back to their letter variables..

It will work, and yes it can get confusing. It's worth mentioning that bitwise ops usually take up more ROM and CPU than bytewise ones, so it's a trade-off. To minimise that trade-off, you can convert those bytes that are accessed the least in your code. If you're using the standard kernel, you also might look at using var44-var47 which are normally hidden unless you're scrolling. And there's also the possibility of switching the game to superchip ram. Well, I'm using the multisprite kernel to display 3 cars on the screen at once, so that's why I resorted to this method. I'm not exactly sure what you mean by converting the bytes... What is involved in using Superchip RAM? I've seen that mentioned in the guide, but I don't quite understand it. As you could tell, I've been learning a lot today about BB, but I'm also still pretty new at it. xD

After reading the guide on RT's website, I've figured out how to modify single bits to save a shitload of variables in my game. Before, I thought I'd be lucky to get 3 cars in the screen at once, but now, I think there's enough resources for even 5 cars! I've laid out how I plan on using bits to control multiple actions in a mere two to three variables. ______________________________________________ a = P1 Car Acceleration b = P1 Car Speed P1 Car Direction P1 Car Resistance Direction P1 Missile Direction c = P1 Car Velocity d = P1 Selected Weapon AI Global: e = AI1/P2 Car is Accelerating (1 bit) AI1/P2 Direction (2 bits) AI2 Firing Action (1 bit) AI2 Car is Accelerating (1 bit) AI2 Car Direction (2 bits) AI2 Firing Action (1 bit) f = AI Timer AI Car 1: g = Car Acceleration h = Car Velocity i = Speed (2 bits) Resistance Direction(2 bits) Missile Direction (2 bits) Selected Weapon (2 bits) AI Car 2: j = AI2 Car Acceleration k = Car Velocity l = Speed (2 bits) Resistance Direction (2 bits) Missile Direction (2 bits) Selected Weapon (2 bits) m = P1 Health n = AI1/P2 Health o = AI2 Health p = AUDV0 q = AUDF0 r = AUDV1 s = AUDF1 temp3 = Car AI 1 Control temp4 = Car AI 2 Control ______________________________________________ Player 1 Multi-Function Variable – b 00xxxxxx = Car Speed is 0 01xxxxxx = Car Speed is 1 11xxxxxx = Car Speed is 2 xx01xxxx = Car Direction is Right xx00xxxx = Car Direction is Down xx10xxxx = Car Direction is Left xx11xxxx = Car Direction is Up xxxx01xx = Resistance Direction is Right xxxx00xx = Resistance Direction is Down xxxx10xx = Resistance Direction is Left xxxx11xx = Resistance Direction is Up xxxxxx01 = Missile Direction is Right xxxxxx00 = Missile Direction is Down xxxxxx10 = Missile Direction is Left xxxxxx11 = Missile Direction is Up AI Global Variable – e AI Car 1: Bits 0,1,2,3 AI Car 2: Bits 4,5,6,7 xx0x = not accelerating xx1x = accelerating 00xx = facing down 11xx = facing up 01xx = facing right 10xx = facing left xxx0 = not firing xxx1 = firing AI Action Variable 2 – i for AI1 and l for AI2 xxxxxx00 = Speed 0 xxxxxx01 = Speed 1 xxxxxx10 = Speed 2 xxxx01xx = Resistance Direction is right xxxx00xx = Resistance Direction is down xxxx11xx = Resistance Direction is up xxxx10xx = Resistance Direction is left xx01xxxx = Missile Direction is Right xx00xxxx = Missile Direction is Down xx10xxxx = Missile Direction is Left xx11xxxx = Missile Direction is Up 00xxxxxx = Weapon Selected is Missile 01xxxxxx = Weapon Selected is Remote Mine 11xxxxxx = Weapon Selected is Homing Missile 10xxxxxx = Weapon Selected is Lightning Bolt ________________________________________________ If I'm correct, this variable setup should free up 7 VARIABLES!!! WOOHOO!!!!! The reason why I'm posting this here is, I just wanted to make sure bits could be used in this fashion. Logically, I think I should have no problems. The only matter I see there being is that it may get very confusing figuring out which bits to apply where, when I'm editing the game.

I think you should go for the holographic label.

Hey. ^^ Just wanted to say VisualBB has been working great for me so far. I can't stop using it. :3 The only weird issue I've ran into is, the "macro" command isn't recognized in VisualBB, even though it's listed in the documentation. Therefore I haven't been able to utilize nybble variables in my game that I'm working on now. I'm using version 554. Perhaps there's a newer version I don't have? Or maybe an asm file I need to include in my code? Thanks. ^^

I found a strange glitch with the multisprite kernel. In my game, I have it so when the car changes direction, it switches to the corresponding sprite for that direction. However on one of the directions, the car sprite has an extra line at the top that shouldn't be there. I checked the sprite code and the line isn't there. Interestingly enough, if I change around the order of the loops in the code, the line will go to a different directional sprite. It seems to be a timing issue of some kind.... Perhaps I've made the code between each drawscreen too long? I should mention I wrote a physics engine for the car, so that along with the drawing of missiles that the car fires, along with the directional sprites, maybe is pushing it a bit? EDIT: As I was trying to figure out the problem, I eventually said "screw it", and continued work on the game. Then after adding a few pieces of unrelated code into the game and testing it again, the weird sprite glitch mysteriously disappeared. Strange....... So I guess..... uh..... this issue has been resolved...? xD default.bas default.bas.bin

Okay. I also understand that Boulder Dash is on the verge of being released, which could also cause a delay. I'm sorry if I'm sounding selfish by the way.. It's just something I had to get off my chest. Nothing against AA or Albert.

Alright. Well, I'm still waiting for the two custom cartridges.. When I look in my account's order history, it doesn't list my cartridges as shipped, it still says the order is Pending... I understand they do a professional job and they make their cartridges with care; that's fine.. But it's also kind of odd that it would take this long. I sent my binary file and labels the night I placed the order, and it was stated on one of the pages that the cartridges would actually ship within two business days of receiving those pieces. Honestly, with all due respect to AA, I'm a little annoyed...

Alright, got a new version of the Car Physics engine up. I completely re-wrote the way the physics were calculated and was able to spare one variable. Considering I was hoping to get 3 cars in the game simultaneously, that's 3 variables which I've freed up for use. The physics are slightly different too. I think they're a bit better now, actually. The car doesn't move awkwardly fast (but if you prefer the fast speed, you can always turn it on via the left difficulty switch ^^), the car will no longer get stuck when you drive off the screen towards the left, and if you're moving in a certain direction and press the opposite arrow key, the car will slow down and begin moving in the other direction as it should. Also, de-acceleration is much better now. If you're at full speed and let go of the joystick completely, the amount of time it takes for the car to coast to a stop is longer than the time it takes to accelerate full speed. It works quite nicely now. Hope you guys like it. :3

I wouldn't say that! I'm sure with some clever code cleanup you could totally turn it into something resembling your intended game. Hmm... Perhaps. What I wanted to try and do was get up to 3 cars (including the player) duking it out against each other. Obviously by making 3 cars on the screen at once, graphical flicker is unavoidable. Ill look into the code further when I get home from work tonight.

Thanks for the response Nateo. :3 I'm not sure if diagonal movement would work here.. I think I need to clean up some of the code, because I'm sure there's probably lines of code in the physics loop that aren't needed. I originally wanted to make a full game out of this, but like I said, I'm not sure if what I was intending to do is actually possible on the 2600...

Thanks for the response ^^ I got another new version up, which allows you to shoot missiles from the car. I'm sorta going for a Twisted Metal-styled game, where you battle other AI cars but I don't know if that's possible yet. The one car that you control on the screen already uses up like 6 or 7 variables, most of which are for physics. o.e;;

Here's my next project that I'm working on... What started out as merely a demo showing off a car physics engine, has actually turned into a full-fledged game. You basically control a car that zooms around the screen, and the objective is to destroy the opponent cars. As you progress through the game, the enemies get more difficult to shoot at, and there are pickups scattered throughout the screen that will change your weapon. This is actually my first shot at making physics in Visual BB. I made it so that when you press the joystick in a direction, the car will gradually speed up, and you can actually swerve around corners. It's also my first game that has animated explosion sprites. Updates 3/11 Alright, so I've got everything in the game fully done as far as the game itself goes. Now is the tricky/fun part: optimizing the code. I've done a lot tonight with optimizing the code. After going through the entire game and re-arranging portions of the code, I'm amazed to say that the game runs at 262 scanlines with two active cars on the screen. No changes in gameplay had to be done! ^^ When there are 3 cars on the screen, the game runs up to about 274 scanlines, which is way better than the 282 I had it using up before! Hopefully at this point the game will not roll as much as it did before on the real system. So, here's to hoping I can get it nice and smooth-running, but 262 scanlines is 16 less than where I am right now, and that seems to be a looong way down. xDD!!! Here are some of the features I've got in the game: - Changing backgrounds - AI difficulty increases as you progress through the game - 1P and 2P modes - Changing the left difficulty switch alters the max. speed of the cars. - During a 2P mode game, the right difficulty switch enables a battle consisting of both players along with an AI car. - Working game over screen - High quality title screen (no music as of now) - Different weapon varieties -- remote mines, homing missiles and fire missiles - Realistic car physics - Pressing the reset button during a game will bring you back to the titlescreen - Two separate score displays for both players during a 2P game - Awesome explosion effects Hope you guys like it! ^^ automayhem_beta2_03122012.bas.bin

Hi. I was wondering when I should expect my custom-made 2600 carts to come in. This past Sunday, I ordered two carts that I wanted to be made the same way. The weird thing is, the site gives two completely different estimates for shipping the items. On the custom cartridges page, it says: "We will ship your completed cartridge within two business days upon receipt of your label and binary files." But on the 'Shipping and Returns' page, it says this: "Orders placed with AtariAge are generally shipped within one week of receipt of payment." I guess the two statements are consistent with each other.. So I guess I'm just wondering if anyone else has ever tried the custom cart service and how long did it take for them to get their carts? Thanks. ^^