Jump to content

Piggles

Members
  • Posts

    123
  • Joined

  • Last visited

Posts posted by Piggles

  1. Byte Knight, I'm loving it. What a great way to spend a Sunday evening. Level 1 was challenging. I lacked the patience to wait and slaughter both wizards before questing for the goblet. Once they doubled up on me, Rezzing each other as I fired volley after volley of fireballs. I did get the coveted goblet and sent old Red to forever-and-ever land. Looking forward to the other two levels.

  2. This is a fun game. I think you can go places with this. If you have any missiles left, perhaps the bomber might exchange fire with you. I like how that fast plane comes from behind. Perhaps a boss enemy or objective at the end of each level? Bomb a ship, blow a super plane out of the sky? A secret German UFO as a final boss? I just saw the trailer for Iron Sky so it's on my mind.

     

    I get points for shooting the parashootist. It might be fun to splatter him and get bonus points.

     

    I did encounter what appears to be a bug. I started the game and the first enemy was a bomber. It did not die. I have only screenshots, not video I'm afraid.

     

    P-61 Bobmer won't die part 1.

    Here it is at 361 points of shooting.

     

    P61 Bomber Won't die

    At 551 points I decided I should call for reinforcements because that bomber did not want to die.

  3. I suggest using the fire button to set your direction of fire, and then you can walk independently of it as in Robotron. When you want to change the angle, just hold fire and press in the desired direction.

  4. Cool, thanks! I took your code and expanded on it even more, making this demo version (you can tell it's a demo because the colors change every 5 seconds like the early Atari 2600 games did when you first turn them on.) A surprising fact: when having player1colors on, putting "player1color=f" actually works for a one-pixel-tall sprite. I haven't checked this for sprites taller than this (which would be just about every sprite imaginable!)

     

    Well done! Go all the way good sir, and prove it can be done with bB!

  5. You need to put your drawscreen before the collision check - the 2600 actually has to draw the frame for the collision registers to get triggered.

     

    As your code is now, you're checking collisions on the previous frame, which is why it works when you do things based on the wrong frame.

     

    Not a stupid error... it's a pretty common mistake for those new to the 2600. :)

     

    Hey RevEng, thanks for the help. I really took drawscreen for granted there - but now it makes sense (it did solve another problem of mine also).

     

    Let me take this opportunity and ask you about flickering: the way I did it it's how it usually go?

     

     

    You should probably consider not going with native collision detection if your are going to use flicker in your program. Instead, you could set up bounding boxes for them to track whether or not one object has intersected with another. That way, you don't have to be concerned what frame you're in when testing collisions. This is especially helpful when you want to test collisions between two object that share the same sprite, like the crab and then square.

     

    To piggyback on Jrok's suggestion, if you're colliding sprites are different (p0 and p1) but are on opposite frames (one on even, one on odd), you can flicker the p0 every other frame, and flicker the p1 sprites two frames in a row, so that each p0 sprite can intersect with the p1 sprite depending on the current frame. Same for missiles if applicable.

×
×
  • Create New...