jrok
-
Content Count
1,156 -
Joined
-
Last visited
-
Days Won
5
Posts posted by jrok
-
-
This code doensn't work for sure - is for asking how multicolour sprites works on BatariBasic.What i'm doing wrong on it?
Any help on fixing it is very welcome! =)
Thanks!
First, you forgot to set the bB kernel option to enable player1colors:
set kernel_options player1colors
Then, you used the wrong command to define your player1colors: The command is singular, not plural:
if y=10 then player1: %00111100 %00011000 %00011100 %00111100 %00111100 %00111100 %00111000 %00011000 %00011000 %00011100 %00011100 %00011000 end player1color: $4E $40 $4E $4E $4E $4E $48 $40 $40 $48 $48 $40 end
Fixed code is attached below.
Cheers,
Jarod.
-
Is there a spot you're supposed to be able to kill the guy? I've noticed that sometimes it only kills him when I hit him dead center. Sometimes it'll register on the bottom portion near his feet, but not always.Yes, there is a spot. The laser needs to intersect with the guy's playfield position. It's interesting you pointed this out, because its something that might change a lot before the game is done. Both playfield y position and collision detection in general are complicated by the fact that I am using 16px tall characters and no_blank_lines. I was actually thinking of contacting SeGTGruff about this, since he was so helpful in explaining the basics, but I want to try to figure it out for myself before I bothered him about it.
Wonder if there's any way to access AtariVox from BB.. your guy in the beginning should give an evil laugh or something.Totally! I don't want to bite off more than I can chew right now, but I started reading up on the Vox a few days ago. I was thinking that if I am able to complete the game, I might look into it and see what it would entail.
You ever complete a BB game for release on cart?I've never completed a BB game period. If I'm able to finish this one it will be my first, but like a lot of guys here I dream of being able to put something on cartridge.
I'd be interested in picking this one up if it came out.Thanks, man! I feel like I'm pretty away from that right now. I'm still digesting the Stella Guide and SeaGTGruff's explanation of timing. It seems a little daunting sometimes. I get so close to having a well-timed program, but when I test with debugger I always seem to get a little "jump" to 263 scanlines in certain firing situations. If I'm really going to get serious about this hobby (and I think I am), I know I'll have to eventually break down and buy a Cuttle Cart so I can test this stuff for real.
Cheers,
Jarod.
-
about widht scale you answered a question i'd ask later - but thanks for the advance! =)What i were asking were about height scale...
for example, from this picture:
http://img243.imageshack.us/img243/8263/ex...sicspritpo2.png
most of the examples i'm seeing about using batariBasic is using the sprite 5 (1x width and 2x height) - and what you said were about sprites 5, 6, 7 and 8
but what i'm looking for is the sprite 1 (1x width and 1x height), or the sprites 1, 2, 3 or 4 - are they possible?
would be this a limitation of batariBasic, which seems to the compiled result being too 'slow' for having sprites smaller than 2x height?
thanks! =)
Ah! My apologies. After reading Impaler's reply below, I think I understand your question now. Yes, that is true, batari's standard kernel uses double-height pixels to draw the player sprites. But it's possible someone have written a batari kernel mod that uses single-height pixels... you might want to search through this thread and maybe make a request.
Good luck,
Jarod.
-
about widht scale you answered a question i'd ask later - but thanks for the advance! =)What i were asking were about height scale...
I'm not quite sure I follow you. As far as I know, there is no TIA register that would "scale" a sprite's height, whether you are coding in batariBasic or pure Assembly... and there actually doesn't need to be. You can write as many lines as you want in a sprite's shape table. It could be 3 pixels high, 8 pixels high, 100 pixels high, etc. You are only limited by the amount of ROM the sprite uses. In other words, there is no such thing as "1x height" or "2x height." The height of a sprite is just the number of rows in it's shape table. For instance, the following draws a sprite that is 16 pixels tall:
player0: %00000000 %00100100 %00000000 %00100100 %00100100 %00100100 %00111100 %00111100 %10111101 %00111100 %10111101 %10011001 %01011010 %01100110 %01011010 %00011000 end
for example, from this picture:http://img243.imageshack.us/img243/8263/ex...sicspritpo2.png
most of the examples i'm seeing about using batariBasic is using the sprite 5 (1x width and 2x height) - and what you said were about sprites 5, 6, 7 and 8
but what i'm looking for is the sprite 1 (1x width and 1x height), or the sprites 1, 2, 3 or 4 - are they possible?
I'm not sure what the person who created that picture was specifically doing to achieve 4, but you can easily make sprites 2 and 3 by using the TIA registers scale a sprite's width to either 200% or 400%:
NUSIZ0 = $05;(double-width player) NUSIZ0 = $07;(quad-width player)
Same thing goes for all the pictures underneath 5-8. For example, image 9 isn't a scaled version of image 5, it's just that the person drew a taller sprite, than altered it's width it using a NUSIZ register. Hope that helps.
Cheers,
Jarod.
-
I were looking for all examples possible, and i found none with 1-pixel-high scaled sprites - the smaller one seems to be 2-pixel-high (the most usual)Is there some limitation of batariBasic, or there is some way to define x and y sprite scales, and having as well 1-pixel-high sprites available?
If possible, please answer also with working snippets (i'm a newbie! =) )
Thanks! =)
When you say "sprite scale", are you referring to the TIA registers NUSIZ0 and NUSIZ1? If that's the case, you might want to consider using either the missiles or the ball to create the graphic you need. For instance:
NUSIZ0 = $10;(missile is 2 pixels wide) NUSIZ0 = $20;(missile is 4 pixels wide) NUSIZ0 = $30;(missile is 8 pixels wide)
Or you could use the CTRLPF register to reshape the ball:
CTRLPF = $11;(ball is 2 pixels wide) CTRLPF = $21;(ball is 4 pixels wide) CTRLPF = $31;(ball is 8 pixels wide)
If all you want to do is scale a single pixel, it seems like a little bit of a waste to use up a whole sprite, unless that is essential to your game. What is the effect you would like to achieve?
If you want to learn more about TIA registers in bB, here's a link.
Cheers,
Jarod.
-
Thank for the feedback.
Some things I notice:1 - After you get shot and the death animation plays you can still move your character around. Doesn't really matter anyway, but I don't think he should be allowed to move when dead.
Absolutely agree. I was trying to figure out if there was a way to get off one last "revenge" shot when dying, but he still shouldn't be able to physically move around. I will fix that.
2 - Enemy can walk right through playfield and I can't. He should have to shoot through to get to me also, instead he walks right over it sometimes.I've noticed the same thing. The collision detection isn't fully resolved yet, that's for sure. I'm still working on some bits.
3 - When enemy shoots right side of wall, his shot will go through and hit the left side also.Yep, that's a doozy. This is the result of returning values above 31 or less then zero for the playfield pixels when a shot goes past a wall. I'm working on it, I'm just trying to figure where in my program I would be the best place to ice off those kinds of shots.
4 - Your guy in the beginning with the flaming head reminds me of the guy in "Crazy Balloon" which was an arcade port done to the 2600 by Cybergoth. In some levels there's a guy blowing air at you. Maybe your guy can poke his head out and blow you around.Hahahah, yeah. That would be hilarious. I definitely plan to use him during the match to f*** with you, shooting stuff at you and what not. "Blowing" you around the screen would be a nice addition to his bag of tricks. Great idea!
FYI, I have attached yet *another* build, which adds color progression to the enemy sprite and playfield as you advance. It also lengthen's the range of the enemies beam in addition to making him more aggressive as you get farther in the game. I think that's gonna be my last update today, because I have to get my butt back to work. Thanks for the encouragement.
Cheers,
Jarod.
-
Send a PM to gambler172. I see him test out a lot of stuff. Maybe he'll do it. He tried out my Acid Fish game.Will do. Thanks for the advice.
-
Great freakin game. Simple, yet fun. Sprites look great.Thanks man!
EDT:
I think I resolved the issue with the enemy taking diagonal shots (new BIN attached). I'll have to work on the accuracy, though.
Out of curiousity, does anyone own a Cuttle Cart or similar device that wouldn't mind testing this program out on it? I just wanted to find out if it's rolling the screen. If so, thanks in advance.
Cheers,
Jarod.
-
I have a new update. You can read about the build on my blog for more details if you're interested.
Evil Emperor
A talking hologram that announces the start of each battle. Press fire to make to shut him up and get on with the fight. Later on, I plan on making him serve an "Evil Otto" sort of function when matches take too long.
Game Progression
- Playfields change as you advance through the game (only three so far).
- The enemy becomes more inclined to take a shot at you as you advance through the game.
- The score, playfield and enemy aggression reset to zero when you lose.
Bugs/ To-do
- Laser beams aren't stopped at exterior walls.
- Enemy is having trouble shooting diagonally.
- Playfields are are too limited/boring, need improvement
- Need to change colors/powers for enemies
Cheers,
Jarod.
EDT:
- Fixed a sound bug at the completion of battles
- Made the laser beams faster and more powerful
- MY TOP SCORE SO FAR= 1600. Can anyone beat it???
- Playfields change as you advance through the game (only three so far).
-
Plus, I am not having any success adding animated sprites. I want to have walking animations for the player (in all 4 directions if possible) and a simple one for the incoming robots. It's driving me nuts because I am not sure how to implement the code, For example, I create the frames for the sprites, and when the Joy0 command (i.e. joy0up) is used it should point to the sprite bank and then recycle back? Would a then statement be used? I realize that if joy0up is used, I point to player0 (and the designated labels where the sprites reside that make up the animation) but I can't seem to get any of it to work.Actually, you might want to consider avoiding "if-then" statements when setting up an animation routine. Basically, you have to remember that Atari doesn't natively have any commands that execute animation. In order to animate something, you have to build the logic fom scratch. Start by creating a variable that represents the frame of animation that should be displayed, and make it increment in your gameloop independently of anything else that you are doing. For example, if you wanted to create a game with sprites that had four-step animations:
dim frame = f gameloop frame = frame + 1 if frame = 4 then frame = 0 drawscreen goto gameloop
So now you have a looping variable that you can point to for your animation. The next step would be to include some subroutines that draw the player sprites.
dim frame = f player0x=30 player0y=48 player1x=60 player1y=48 gameloop frame = frame + 1 if frame = 4 then frame = 0 gosub Sprite1 gosub Sprite2 drawscreen goto gameloop Sprite1 COLUP0 = $66 goto Shape1 return Sprite2 COLUP1 = $C6 goto Shape2 return Shape1 player0: %00000000 %00000000 %00000000 %00011000 %00011000 %00000000 %00000000 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape2 player1: %00000000 %00011000 %00011000 %00011000 %00011000 %00011000 %00011000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return
Now, every time your program loops, it will draw two player sprites with unique colors and shapes. But instead of your Sprite subroutine pointing to a single shape (i.e. "goto Shape1"), we would want it to point to an animation. In that case, we would use the "on" command to track the current value of "frame" and have it point to the desired shape table.
dim frame = m player0x=30 player0y=48 player1x=60 player1y=48 gameloop frame = frame + 1 if frame = 4 then frame = 0 gosub Sprite1 gosub Sprite2 drawscreen goto gameloop Sprite1 COLUP0 = $66 goto Sprite1Animation return Sprite2 COLUP1 = $C6 goto Sprite2Animation return Sprite1Animation on frame goto Shape1_1 Shape1_2 Shape1_3 Shape1_4 Sprite2Animation on frame goto Shape2_1 Shape2_2 Shape2_3 Shape2_4 Shape1_1 player0: %00000000 %00000000 %00000000 %00011000 %00011000 %00000000 %00000000 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape1_2 player0: %00000000 %00000000 %00111100 %00111100 %00111100 %00111100 %00000000 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape1_3 player0: %00000000 %01111110 %01111110 %01111110 %01111110 %01111110 %01111110 %00000000 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape1_4 player0: %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11100011 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11110111 %11010111 %11100111 %11111111 %11111111 end return Shape2_1 player1: %00000000 %00011000 %00011000 %00011000 %00011000 %00011000 %00011000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return Shape2_2 player1: %00000000 %00000110 %00001100 %00011000 %00110000 %01100000 %11000000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return Shape2_3 player1: %00000000 %00000000 %00000000 %11111111 %11111111 %00000000 %00000000 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return Shape2_4 player1: %00000000 %00000000 %01100000 %00110000 %00011000 %00001100 %00000110 %00000000 %11111111 %11111111 %11000011 %11011111 %11011111 %11011111 %11011111 %11101111 %11110011 %11111011 %11011011 %11011011 %11011011 %11100111 %11111111 %11111111 end return
The way the above works is that, in every game loop the value of frame is incrementing from 0 to 3 and the subroutines "Sprite1" and "Sprite2" are comparing that value to the four Labels listed after the "on" command. So if the value of frame is "0", "on frame" goes to the first label after the command ("Shape_1_1" for player0 and "Shape_2_1" for player1), if its "1" it goes to the second label, if it's "2" it goes to the third label and if it's "3" it goes to the fourth label. Once you have a stable animation routine in place, you can use conditional statements to switch between multiple animations based on user inputs.
Cheers,
Jarod.
-
Okay, I have a new version, and here's what's in it:
- Both the player and the enemy can be killed. When either man is shot, a brief death animation plays, then the game resets.
- Improved enemy AI (there's still a ways to go, but he's a little trickier now, and can detect and dodge shots every once in a while).
- Incorporated Michael Rideout's method for variable playercolors to palette-swap the Hero and the bad guys. Hopefully, I can use this to create a bunch of different flavors of baddie without using up a lot of space in my shape bank.
- Added some sound effects (these still need a LOT of work.)
Now that there's actually a game here, I think my next steps will be to add some game progression to make the game tougher with each new stage. For this, I'm thinking of:
- Giving the badguy a number of shields/hitpoints that increments.
- Having the badguy's level of aggression ramp up
- Include two additional enemy types with different weapons/abililties.
- Changing the playfield layout and properties (Electrified playfield, Ricochet shots, etc)
- Using my two flickered sprites and the ball for obstacles or additional enemies (Gun Turrets, Hungry Beasties, Landmines, etc)
The size of the game is 32K, but I'm not using most of it and might downgrade to 16k again. Bank 2 is empty. Banks 3-4-5 are filled with the 48-playfield map routine I was using for Armageddon Complex, and I doubt I'll need 48 unique playfields for this game. Bank 6 is about two-thirds full, and contains my player control schema and my enemy AI. Bank7 is is filled with my animation loops and my player1color variables, and bank8 is about halfway-filled with my shape data and my vblank.
EDT:
Oh did I mention bugs? There are a few:
- I need to halt the progress of the beams at the edges of the screen, so neither combatant can exit
- There's still a few collision detection issues with the enemy, where he can get stuck for a few loops. Usually though, he just blasts his was out of it.
Cheers,
Jarod
- Both the player and the enemy can be killed. When either man is shot, a brief death animation plays, then the game resets.
-
-
Music Starter using sdata is my adapted version of code posted in the Ballblazer thread:http://www.atariage.com/forums/index.php?s...t&p=1615280
The 256-byte limitation is removed when using sdata. You can fill a whole 4k bank with music if you want. The volume/control/frequency data is in the same order as what you see in Tone Toy 2008 to make it easier for me since I use Tone Toy 2008 to hunt for sounds.
Format:
v,c,f (voice 0)
v,c,f (voice 1)
d
Explanation:
v - volume (0 to 15)
c - control [a.k.a. tone, voice, and distortion] (0 to 15)
f - frequency (0 to 31)
d - duration
I added a bunch of default data in case you're like me and like to have a guide:
0,0,0 0,0,0 1 0,0,0 0,0,0 1 0,0,0 0,0,0 1
Here's the .bas file:
music_starter_2008y_11m_19d_0632t.bas
I haven't had time to make any tunes with it yet, but I'll post a few in the future. Feel free to post your own tunes. I'm thinking about trying things like the Doctor Who theme from the Tom Baker years and Darth Vader's theme from Star Wars.
Hey this is pretty cool! Thanks!
-
Nice idea, it's about time someone finally makes an adult homebrew!
You mean a homebrew where you work 9 to 5, pay your bills, walk the dog, pick up steaming hot dog turds, go on a diet because you're getting too fat around the middle, and so on? Yeah! It's about time!
When he said "Adult Homebrew," I thought he meant a thought-provoking exploration of the themes of art and confrontation in Proust's "Time Regained." Imagine my relief when I saw blood and sperm.
-
Note that you can define only one vblank subroutine-- but if you want, you can use an if or on...goto statement to choose between two or more subroutines depending on some factor, such as a frame counter or a game state flag (just as you can do in your main display loop if you want to).Michael
Thanks for the advice. I actually *am* using the vblank to do certain things, but I have the feeling that I am using it badly. Currently, my vblank does the following:
- Updates each sprite's current playfield position.
- Updates each sprites next playfield position based on their current directions.
- Reads the state of the each sprite's next playfield pixel based on the their current directions (for collision detection).
It doesn't seem like a lot of cycles when i describe it like that, but it works out that way because I'm changing the value of each sprite's Y playfield position based on the sprite's current direction. It seems awful and wasteful when I look at it, but If when I track their playfield Y with a universal formula, they end up getting stuck on collisions.
dim sprite1dir = a; The 8-directional vector of the sprite dim sprite1ydir = b; Vertical direction (Up or Down, including diagonals) dim sprite1xdir = c; Horizontal direction (Left or Right, including diagonals) dim sprite1lastX = d; The last x coordinate before a collision dim sprite1lastY = e; The last y coordinate before a collision dim sprite1PFX = f; The sprite's playfield X position dim sprite1PFY = h; The sprite's playfield Y position dim sprite1nextPFX = i; The next playfield X dim sprite1nextPFY = j; The next playfield Y dim sprite2dir = k dim sprite2ydir = l dim sprite2xdir = m dim sprite2lastX = n dim sprite2lastY = o dim sprite2PFX = p dim sprite2PFY = q dim sprite2nextPFX = t dim sprite2nextPFY = u const pfres = 24 ... vblank sprite1PFX = (sprite1X-14)/4 if sprite1dir = 0 then sprite1PFY = (sprite1Y-13)/4 if sprite1dir = 1 then sprite1PFY = (sprite1Y-13)/4 if sprite1dir = 2 then sprite1PFY = (sprite1Y-8)/4 if sprite1dir = 3 then sprite1PFY = (sprite1Y)/4 if sprite1dir = 4 then sprite1PFY = (sprite1Y)/4 if sprite1dir = 5 then sprite1PFY = (sprite1Y)/4 if sprite1dir = 6 then sprite1PFY = (sprite1Y-8)/4 if sprite1dir = 7 then sprite1PFY = (sprite1Y-13)/4 if sprite1xdir = 0 then sprite1nextPFX = sprite1PFX + 1 else sprite1nextPFX = sprite1PFX - 1 if sprite1ydir = 0 then sprite1nextPFY = sprite1PFY + 1 else sprite1nextPFY = sprite1PFY - 1 if pfread(sprite1nextPFX,sprite1PFY) then sprite1X = sprite1lastX : sprite1Y = sprite1lastY if pfread(sprite1PFX,sprite1nextPFY) then sprite1Y = sprite1lastY : sprite1X = sprite1lastX sprite2PFX = (sprite2X-14)/4 if sprite2dir = 0 then sprite2PFY = (sprite2Y-13)/4 if sprite2dir = 1 then sprite2PFY = (sprite2Y-13)/4 if sprite2dir = 2 then sprite2PFY = (sprite2Y-8)/4 if sprite2dir = 3 then sprite2PFY = (sprite2Y)/4 if sprite2dir = 4 then sprite2PFY = (sprite2Y)/4 if sprite2dir = 5 then sprite2PFY = (sprite2Y)/4 if sprite2dir = 6 then sprite2PFY = (sprite2Y-8)/4 if sprite2dir = 7 then sprite2PFY = (sprite2Y-13)/4 if sprite2xdir = 0 then sprite2nextPFX = sprite2PFX + 1 else sprite2nextPFX = sprite2PFX - 1 if sprite2ydir = 0 then sprite2nextPFY = sprite2PFY + 1 else sprite2nextPFY = sprite2PFY - 1 if pfread(sprite2nextPFX,sprite2PFY) then sprite2X = sprite2lastX : sprite2Y = sprite2lastY if pfread(sprite2PFX,sprite2nextPFY) then sprite2Y = sprite2lastY : sprite2X = sprite2lastX return
The main idea is that a sprite's playfield position is the both origin of it's laser and the value used for collision detection. The sprite itself isn't used for anything - it's just a pretty coat. But the above looks and feels incredibly sloppy to me. I mean, I know that "sprite1xdir" and "sprite1ydir" are binary values, and should be nybbles, and there are some other ways I can pretty obviously save RAM. But what really bothers me about the above is how much division I'm doing, just for collision detection. I get the feeling I probably shouldn't be doing this stuff at all, let alone here in the vblank. Is there a simpler way to achieve what I'm going for?
Thanks,
Jarod.
- Updates each sprite's current playfield position.
-
I just played a few rounds and i like the concept of your game, i think this could become a fun to play game!Thanks man!
I was just wondering why you're using flicker when you only have 2 sprites on the screen at once?There are actually four sprites on the screen, but I've repositioned the other two offscreen for now until I figure out what I want to do with them. But actually I was flickering even before I added in the sprites, since testing for both player and enemy beam and movement routines before each vsync was causing some scanline problems. Also, I wanted them to share sprite data, so this seemed a pretty straightforward way to do it.
Another Tron game would also be nice. Someone else already made a Tron game with bB, maybe this gives you a few ideas for your version of Tron:http://www.atariage.com/forums/index.php?showtopic=103759
I'll have to check those out, thanks. I was a pretty big fan of the Discs of Tron arcade game, and gameplay wise I love the idea of hitting your opponent with ricochet shots.
And is this the Doom hack you saw?Yep! That's the one. Thanks. You know it's hard for me to think of "Doom" as anything other than a 3D game, since that was sort of its mark of fame. Unfortunately, most of those Atari "First Person Perspective" maze games usually turn out to be frustrating or boring or both for me. What might be kind of cool would be a "Battlezone" version that had the 3D feel but with simple obstacles/landmarks instead of mazes.
Cheers,
Jarod.
-
What's with the game name? I kind of like it, though, but here'sI was thinking it would be a word play on "Circus Maximus" which was the Latin name for the largest gladiator arena in Rome. My original idea was to make a sort of Combat-like game, with different selectable modes for different events. Like, Laser Duel would be one event, while another event might be some sort of futuristic chariot racing thing or an event where you have to survive waves of space monsters.
-
Very cool. I like the sprites, but there's a lot of flicker though on Stella emulator.Could be nice to have different rooms eventually. What's with the game name? I kind of like it, though, but here's what I originally thought of when I tried out the demo:
- The character reminds me of Tron. New Tron game for the 2600? I was picturing a second level where there's a bunch of platforms you must jump from one to the other. Sprite looks like it'd make a good jumper.
- Doom 2600? Change the second character to a Doom-like monster. Make it so you have to get colored passcodes in order to open certain doors and finally the elevator to the next level. Between levels have a cutscene of your guy riding an elevator sort of like "Cloak & Dagger".
- Not quite as intense button mashing gameplay, but maybe some kind of Smash TV for 2600?
I like you can shoot or throw grenades. I don't remember exactly what happened since I am at work right now, but each of the things should go different distances and have different power. Example would be that a gun can shoot farther than one can throw a grenade, but a grenade does more damage.
Good work. Like it so far.
Thanks man! I guess if I went the Tron route, I might as well abandon the whole laser beam thing and go with discs. But on the other I could reuse portions the laser routine to do the lightcycle levels, so that's a pretty interesting idea. I'm almost postive I saw someone do a 2600 Doom hack of something(?), but it might've been Castle Wolfenstein.
Smash TV was probably my favorite Robotron clone, and Robotron was probably my favorite arcade game, period. I have four flicker sprites available to me right now, including the player. I suppose I could beef up that number with the multisprite kernel, but I haven't tried to adapt my beam drawing routine to it yet, and I have a suspicion it won't work with a symetrical playfield. Absent that, I suppose I could use playfield pixels to represent the basic, swarming grunt-type enemies, and save the sprites for more dangerous foes. That actually might be kind of sweet. Has anyone ever done anything like that?
Yeah, I definitely want to try to do the grenade thing in my next build, maybe with a shakescreen effect. I'd also like to have two different modes (1 player and 2 player), but I might not be able to pack that much game onto a 16k romboard.
-
I've been taking a break from Armageddon Complex to try to write something a little less, well, complex. This game is more action-oriented, with a control schema that I based on one of my favorite games, "Berzerk." The setting is a futuristic gladiator tournament, where combatants duel each other to the death for the pleasure of the galactic empire. The game will comprise the player's fighting career, with the difficulty and rewards ramping up with each match.
I've attached a demo of the current engine. The blue character is controlled with the left stick. Holding down the fire button cause the character to stop, and simultaneous aim and charge up his laser gun. The longer the button is held down, the longer the laser beam he will fire when he releases the button. If the beam reaches it's maximum range or hits a portion of the playfield or the enemy character, its progress will stop and the beam will fade away. Once a beam fully disappears, the player may charge and fire a new beam.
The green character is controlled by "A.I.", such as it is
. It's pretty meatheaded right now, so I'll have to figure out ways to trick it into looking smarter. There's no way I can hitch anything as smart as A* into Atari, but I will try to build a very simple short term memory for the dude so he at least doesn't make the same mistakes over and over. I've lent him a few supercharger variables as placeholders to ramp up his aggression and accuracy, but at the present it's sort of like handing a blind man a machine gun. You can shoot him, but for now hits just increment your score. He can shoot you too, but for now you are godlike and invincible.I'm hoping to include a few different breeds of enemy and different arena types with traps and gadgets that you can use to help you win. Another thing I'm thinking of incorporating is a few different options for attack, based on how long you hold down the button and particular joystick movements.
- Short button presses & joystick movement : Perform a quick dodge or melee attack
- Long button presses & back/forth joystick movement : Throw a grenade
There's a bug in the game that I left in on purpose, since I think it might make for an interesting grenade effect. If you fire diagonal past either horizontal edge of the arena, a shortcoming in the beam progression routine causes what looks like a massive explosion on the other side of the screen! Hooray for cool looking bugs!
What do you guys think?
Cheers,
Jarod
UPDATE:
This game has changed substantially since this first-post. I've been posting progress on the Homebrew forum as well, so I will try to keep current updates consistent on both pages. Thanks to everyone in the bB forum for the all the helpful feedback and advice - Jarod.
Current Version:
Circus_Galacticus_m1_d30_y11.bas.bin
- Short button presses & joystick movement : Perform a quick dodge or melee attack
-
Thanks for all the helpful advice. This is a lot of information to "process", if you'll pardon the pun, but it is very fascinating stuff. I'm not much of hardware guy either, but much of it is actually starting to make sense!
Cheers,
Jarod.
-
...Also, bear in mind that when you are using pfread, you don't have to use static values. You could use variables. So in your case, you'd want to do something like
if pfread (my_rand_x,my_rand_y) then gosub do_some_stuff
...where my_rand_x and my_rand_x are the user defined variables that are returned from your random function. So basically, you'll have to build two random functions: one to pick a number between 0 and 31 (the playfield pixel's x position) and one to pick a number between 0 and 11 (the playfield pixel's y position). Then you test those variables with the above statement whenever you want to detect a playfield pixel's state.
Jarod
-
I don't think you can do it like that. As far as I know, "pfpixel [x] [y] on" is actually performing an operation, not testing the state of the pixel. But what you could do is set a variable when the pixel is turned on or off, like:dim pixel_state = a gameloop if [some set of conditions] then pfpixel [x] [y] on : pixel_state=1 if [some other set of conditions] then pfpixel [x] [y] off : pixel_state=0 if pixel_state = 1 then gosub do_some_other_things goto gameloop
I don't think I can do what you are saying. I have WAAAAY too many pixels on to make each one a variable. I have most of the screen filled using pfvlines. I can't possibly set variables for 100 or 200 locations.
Let's say I have the following as a playfield
*********************
*** ***** ** *
* ***
*
You can use your imagination and pretend that it's 32 wide x 11 tall. You can use your imagination and pretend that it's 32 wide x 11 tall. I want to randomly take a number between 1 and 128 (because in that example the tallest piece is 4 tall multiplied by 32 wide is 128) and then see if that pixel is on.
Oh, okay. Well then you can just use pfread to determine the state. That evalutes to true if the pixel is on:
So...
if pfread(20,46) then gosub do_some_stuff
...would mean "if the playfield pixel at x position 20, y position 46 is on, then do my subroutine."
Does that make sense?
Cheers,
Jarod
-
Is it possible to do a command asif pfpixel 31 4 4 on then
What I need to do is tell if a pfpixel is on and if so do some other things.. if the pfpixel is off then do nothing.
I don't think you can do it like that. As far as I know, "pfpixel [x] [y] on" is actually performing an operation, not testing the state of the pixel. But what you could do is set a variable when the pixel is turned on or off, like:
dim pixel_state = a gameloop if [some set of conditions] then pfpixel [x] [y] on : pixel_state=1 if [some other set of conditions] then pfpixel [x] [y] off : pixel_state=0 if pixel_state = 1 then gosub do_some_other_things goto gameloop
-
Okay, I see by your program code that you're using the bankswitch_SC.inc file, which uses std_kernel_SC.asm instead of std_kernel.asm. I checked my copy of std_kernel_SC.asm and modified it a bit (I added another "sta WSYNC" in one spot), then tested your program both with and without the no_blank_lines option. It seems to give a steady 262 lines now. The updated std_kernel_SC.asm file is attached, and the place where I changed it is shown below.Michael
ifconst no_blank_lines; <-- this is line 595 sta WSYNC sta WSYNC; <-- I added this extra sta WSYNC endif
THANK YOU SIR.
I've noticed that certain Atari games carry constant scanline rates above 262. Am I wrong to think that they use similiar technique to balance the number of scanlines?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
SpongeBob SquarePants: Jellyfishing
in batari Basic
Posted
Well, I just played for thirty seconds and died about a dozen times, so I think collision detection is working pretty well the way you have it now.
Nice game, BTW!
Jarod.