Playfield Death Ray

[jrok]

(or "How I Learned to Stop Worrying and Love the Playfield")

 

So, I've been working on designing some routines that use the playfield to draw laser beams that can destroy playfield-drawn terrain. Enclosed is my first effort, which I think could do with a lot of improvement. It its current state, my death ray does the following:

 

• Calculates the playfield position of the sprite from which it originated.
  
• Draws a progressive line in one of eight directions depending on the player's direction when the fire button is released.
  
• When the laser reaches it's full range or hits a playfield pixel, the line progressively erases (also erasing the pfpixel at its endpoint.)
  

 

Ultimately, I'll want to add a second player, and vary the length of the death ray depending on how long the button was held down. But there are many things that i'd like to improve about this code before I can take this to the next stage. Hoping a few of you could take a crack at optimizing down this code... I've been staring at it all weekend and it seems to be begging for a clever function or two to tidy it up. Also, there is a small bump in the scanline count that happens during beam collisions that I can't seem to nail down.

 

Here's a quick rundown of my variables and routines:

 

 

VARS:

 

sprite1dir = One of eight possible directions( 0-7 ) that player0 is facing/moving in

sprite1ydir = One of 2 possible vertical directions( 0 or 8 ) that player0 is facing/moving in.

sprite1xdir = One of 2 possible horizontal directions( 0 or 8 ) that player0 is facing/moving in.

sprite1lastX = player0's last known x position

sprite1lastY = player0's last known y position

sprite1PFX = player0's current playfield pixel x position

sprite1PFY = player0's current playfield pixel y position

sprite1nextPFX = the next playfield pixel x position in the direction player0 is moving

sprite1nextPFY = the next playfield pixel y position in the direction player0 is moving

 

beamlength = the length of an active beam

beampos = the progression of an active beam.

shotnum = the firing state of the beam. (0=no active beams, 1=beam is being drawn, 2=beam is erasing, 3=beam erased)

shotdir = One of eight possible directions the beam can be shot in.

beamTipX = The horizontal tip of an active beam

beamTipY = The vertical tip of an active beam

beamrange = the maximum range of the player's death ray.

rangevar = a variable used to shorten diagonal beams for a more realistic beam range.

 

 

SUBROUTINES

 

Beam: Draws a beam based on the range, direction and progression of the shot.

BeamOff: Erases a beam after its hit it's maximum range or a pfpixel.

Inputs: Uses SWCHA / 16 to determine the direction of player0 and draw the appropriate shape.

 

Thanks in advance for your help and improvements. Hopefully, this can be a weapon of mass destruction we can all enjoy.

 

Cheers,

Jarod.

Playfield_Death_Ray_m11_d10_y08.bas

Playfield_Death_Ray_m11_d10_y08.bin

Edited November 10, 2008 by jrok

[ginnidog]

I know nothing yet of programming for the 2600..and I hope to learn one day..

 

But i like it so far...

 

adding some color to the beam would be nice..as it progress`s its length

 

Great work so far

 

Paulie ( GINNIDOG )

 

[jrok]

I know nothing yet of programming for the 2600..and I hope to learn one day..

 

But i like it so far...

 

adding some color to the beam would be nice..as it progress`s its length

 

Great work so far

 

Paulie ( GINNIDOG )

 

 

Thanks Paulie. I'm pretty new to Atari programming too. Batari Basic seems like a very nice entry point, and everyone here seems awfully helpful.

 

I think your idea of a different colored beam is a good one, but I'm not sure if something like that would be possible in bB. My instinct would be to flicker the playfield across two frames, resetting it to blank lines before the shot is fired, then setting it back to the the room definition in the second frame. But that would create three major limitations:

 

1) The playfield missile would no longer resemble a "laser beam", but would rather appear to be a single 8x8 "bullet" moving across the screen.

 

2) The environment would no longer be destructible, since I'd be redefining the playfield every other frame.

 

3) The scanline count would go wildly out of control.

 

I've attached an example of my best effort to change the color of the playfield missile, but I think its pretty unusable. Another way to approach the problem might be to create variables that would store the states of the playfield pixel, but that sounds like a LOT of variables... that might be equally implausible.

Playfield_Death_Ray_m11_d10_y08_flicker.bin

Edited November 10, 2008 by jrok

[ginnidog]

I like the first version better...you`re right..the 2nd version does not work too well, even though i dont know anything about bB yet..i`d like to learn..

 

still looks good regardless

 

Paulie

[yuppicide]

Neat idea. Not sure what I'd use it for though.

[jrok]

*UPDATE:

 

I've resolved my scanline "bump" problem by jamming some of the pfreading into my vblank. I still think that I should be functionalizing some of my beam routines to conserve space, but at least everything is constant now.

 

I added a player2 with his own beam. I'm liking the way this experiment is turning out so much that I've decided to turn it into a fully-fledged game. I'm thinking of calling it "Circus Galacticus." It will be a sort of futuristic gladiatorial contest, with lots of different playfields and configurable options like "Combat". Hopefully, I can use lessons learned from it to continue my work on Armageddon Complex.

 

For my next build, I'm going to try to increase the hit area of the players. As it stands, your aim has to be pretty exact to hit the opposing player (exact same playfield x or y coordinates). I'll also try to implement Curtis P's 2-score mini-kernel (though I haven't had a luck with it so far, perhaps because I'm using superchip.)

 

One thing that's frustating is that I can't seem to incorporate "no_blank_lines." It just blows my scanline count all to hell. Does anyone know why? How many scanlines does no_blank_lines use per frame?

 

EDT: One other quick question that's been bugging me. Has anyone noticed that when you use the vblank in a bankswitched game that DASM doesn't report how the ROM usage of your last bank? For instance, the only output I get for bank 4 in this game is "-->vblk2f5fb."

 

Cheers,

Jarod.

Circus_Galacticus_m11_d9_y08.bin

Edited November 11, 2008 by jrok

[+Random Terrain]

EDT: One other quick question that's been bugging me. Has anyone noticed that when you use the vblank in a bankswitched game that DASM doesn't report how the ROM usage of your last bank? For instance, the only output I get for bank 4 in this game is "-->vblk2f5fb."

I'm using vblank in that maze game I'm working on and VbB is showing space left for the last bank in the Information Pane.

[jrok]

EDT: One other quick question that's been bugging me. Has anyone noticed that when you use the vblank in a bankswitched game that DASM doesn't report how the ROM usage of your last bank? For instance, the only output I get for bank 4 in this game is "-->vblk2f5fb."

I'm using vblank in that maze game I'm working on and VbB is showing space left for the last bank in the Information Pane.

 

Weird. Now I am getting a report. But I'm not sure which change I made in my code that caused it to come back... I just looked down after my last compile and it was there. If I figure out what was causing that to happen before, I'll post it in a separate thread.

 

Jarod.