18 replies to this topic

[Lodmot]

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! ^^

Attached Files

•  automayhem_beta2_03122012.bas.bin   16K   66 downloads

Edited by Lodmot, Mon Mar 12, 2012 9:03 PM.

[RevEng]

Looks good!

A few things you probably already know about:

• if the car is full throttle and you press the opposite joystick direction the car keeps going in the same direction.
  
• occasionally the car gets stuck on the left side of the screen when travelling left.

[Lodmot]

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;;

Edited by Lodmot, Thu Feb 23, 2012 3:51 PM.

[Nateo]

Nifty! I actually had a similar idea, except the goal was to smash a large truck into smaller cars a la destruction derby. This could turn into a really cool game!

A couple thoughts:
- Is diagonal movement a possibility?
- Full speed seems to be awful fast. I assume though that it wouldn't be difficult to tune it to a particular game's needs.

All in all though, pretty cool demo!

[Lodmot]

Nateo, on Thu Feb 23, 2012 9:26 PM, said:

Nifty! I actually had a similar idea, except the goal was to smash a large truck into smaller cars a la destruction derby. This could turn into a really cool game! A couple thoughts: - Is diagonal movement a possibility? - Full speed seems to be awful fast. I assume though that it wouldn't be difficult to tune it to a particular game's needs. All in all though, pretty cool demo!

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...

[Nateo]

Lodmot, on Thu Feb 23, 2012 10:57 PM, said:

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...

I wouldn't say that! I'm sure with some clever code cleanup you could totally turn it into something resembling your intended game.

[Lodmot]

Nateo, on Fri Feb 24, 2012 1:51 PM, said:

Lodmot, on Thu Feb 23, 2012 10:57 PM, said:

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...

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.

[Lodmot]

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

Edited by Lodmot, Fri Feb 24, 2012 11:18 PM.

[Lodmot]

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.

Edited by Lodmot, Thu Mar 1, 2012 2:40 PM.

[RevEng]

Lodmot, on Thu Mar 1, 2012 2:39 PM, said:

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.

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.

[Lodmot]

RevEng, on Thu Mar 1, 2012 3:24 PM, said:

Lodmot, on Thu Mar 1, 2012 2:39 PM, said:

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.

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

Edited by Lodmot, Thu Mar 1, 2012 3:43 PM.

[RevEng]

Lodmot, on Thu Mar 1, 2012 3:43 PM, said:

I'm not exactly sure what you mean by converting the bytes...

I should have been more precise... "converting your variables to use bits instead of bytes".

Lodmot, on Thu Mar 1, 2012 3:43 PM, said:

What is involved in using Superchip RAM? I've seen that mentioned in the guide, but I don't quite understand it.

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

[Lodmot]

RevEng, on Thu Mar 1, 2012 3:52 PM, said:

Lodmot, on Thu Mar 1, 2012 3:43 PM, said:

I'm not exactly sure what you mean by converting the bytes...

I should have been more precise... "converting your variables to use bits instead of bytes".

Lodmot, on Thu Mar 1, 2012 3:43 PM, said:

What is involved in using Superchip RAM? I've seen that mentioned in the guide, but I don't quite understand it.

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..

Edited by Lodmot, Thu Mar 1, 2012 4:06 PM.

[RevEng]

Lodmot, on Thu Mar 1, 2012 3:56 PM, said:

I think I may have been converting the variables from bytes to bits all along.

Yes, by using bitwise access (e.g. b{3}) you're using bits instead of the whole bytes, for your variables.

Lodmot, on Thu Mar 1, 2012 3:56 PM, said:

Also, giving aliases uses more ROM? I was kinda hoping that the compiler would convert all the aliases back to their letter variables..

No, using aliases doesn't use more ROM. Using "a{3}=1" uses more ROM than "a=1", for one example.

It's not a problem in itself. You should just be aware it's the trade-off you're making.

[Lodmot]

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?

Edited by Lodmot, Thu Mar 1, 2012 7:30 PM.

[RevEng]

Lodmot, on Thu Mar 1, 2012 7:27 PM, said:

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.

The checking code will probably be more expensive than the time to just do the bit setting. Don't give my original caution that much weight - it's only something to think about if your program is eventually doing hundreds of bitwise operations and running low on CPU cycles or ROM.

Lodmot, on Thu Mar 1, 2012 7:27 PM, said:

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?

There's no command in 6502/6507 assembly to "store a bit" or "retrieve a bit". So bB (and the assembly language programmer) uses masking commands to isolate/combine bits first, and then they use commands to retrieve/store a byte at a time.

[Lodmot]

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.

[Lodmot]

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

Edited by Lodmot, Sat Mar 3, 2012 1:38 PM.

[Lodmot]

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