jrok Posted November 10, 2008 Share Posted November 10, 2008 (edited) (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 Quote Link to comment Share on other sites More sharing options...
ginnidog Posted November 10, 2008 Share Posted November 10, 2008 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 ) Quote Link to comment Share on other sites More sharing options...
jrok Posted November 10, 2008 Author Share Posted November 10, 2008 (edited) 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 Quote Link to comment Share on other sites More sharing options...
ginnidog Posted November 11, 2008 Share Posted November 11, 2008 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 Quote Link to comment Share on other sites More sharing options...
yuppicide Posted November 11, 2008 Share Posted November 11, 2008 Neat idea. Not sure what I'd use it for though. Quote Link to comment Share on other sites More sharing options...
jrok Posted November 11, 2008 Author Share Posted November 11, 2008 (edited) *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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted November 11, 2008 Share Posted November 11, 2008 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. Quote Link to comment Share on other sites More sharing options...
jrok Posted November 12, 2008 Author Share Posted November 12, 2008 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.