Jump to content
IGNORED

Bounce & Catch (WIP)


vitoco

Recommended Posts

After finishing Don't go!, which it was written in assembly (2K), I wanted to learn bBasic, and I selected another of my tenliners minigames for the A8 that uses a paddle controller: Bounce & Catch:

 

BOUNCE.PNG

 

That game was written in Atari BASIC and it uses 2 hardware players (ball and pad), and playfield number to catch and score. I used a lot of tricks to manage the players and simulate the parabolic movement, so the BASIC code is very obfuscated that it cannot be copied and pasted into bB source code, and I had to start from scratch again.

 

For the 2600, I thought I could use one player for the ball and one for the pad, but I also needed one for the counter to catch, because I cannot use bB managed playfield for that (extremelly low resolution). Solution: try a multiplayer kernel. New problem: can't read paddles in multiplayer kernel. New solution: use the 2600 ball object as the pad, and let the players be the bouncing ball and the floating counter.

 

The programming was simple, but the result was a very small pad (8 color clocks or pixels), and an horizontal resolution for the pad of about 80 (the half of the screen width). To increase the pad size, I had just one more sprite element availabe: a missile. I just set it up like the ball object and both provide 16 color clocks for a pad, not a courved one, and with two colors (the missile repeats its corresponding player color).

 

I managed to change and test all the available fonts for the score (by defining the "font" const as the number of the selected font), but I couldn't use their bitmap for the floating counter, so I defined some baloon bitmaps with their respective number in the bB style, selecting the right one using ON-GOTO structure. I also added an animation to the ball, but this time using IF-THEN-IF-THEN structure... I said that I was learning... ;-)

 

I also found that the score in batari BASIC is quite hard to manage, because the parser/compiler expects BCD values to add, and it interprets the numeric literals as BCD to add constant values to the score. But I wanted to add variable values, so I inserted a small piece of ASM code to perform the addition of variable values to the score in BCD.

 

The result looks like this:

 

Bounce.bas_2.png.eadfa276a7a81fb31b41065a51d5eb2d.png

 

Of course, I want to get a single color pad, but I cannot change the missile color from the right half of the pad, because it must be of the same color than the target. If I try multi color sprites, I'll loose this missile (the other one was lost because I wanted to read a paddle).

 

Now, I have to fix some border contitions and the next step will be to tweak the kernel in order to change that missile to be of the same color of the ball object (not the bouncing ball... it is somehow confusing in the source code), or create a minikernel to redefine the target's player and get a courved pad.

 

If there is some interest, I'll post the binary here after the fixes.

 

Anyway, I want it to have more features than the tenliner version. Ideas? I have some, but it would be interesting to hear fresh ones.

 

BTW, the original game can be downloaded at BOUNCE.ATR and played in Altirra or any XL/XE computer with a paddle controller in port 1.

 

  • Like 5
Link to comment
Share on other sites

It looks pretty good. I'd be interested in trying it.

 

2 hours ago, vitoco said:

Of course, I want to get a single color pad, but I cannot change the missile color from the right half of the pad, because it must be of the same color than the target

You may want to post questions about the game in the batari Basic subforum.

 

Two solutions come to mind to get a single color pad:

 

1) Is there any reason you can't just set COLUPF to match the missile/player color? It doesn't seem that you are using the playfield in this version at all.

 

Or, if that won't work for some reason, you could:

 

2) Swap the positions of the ball and missile every frame, to effectively mix the colors of the two to make the whole pad a common mixed color.

Link to comment
Share on other sites

23 minutes ago, Karl G said:

1) Is there any reason you can't just set COLUPF to match the missile/player color? It doesn't seem that you are using the playfield in this version at all.

I want the target balloon to change colors and brights depending on its number and other bonuses. Matching the ball to the missile would make the pad also change accordingly.

 

26 minutes ago, Karl G said:

2) Swap the positions of the ball and missile every frame, to effectively mix the colors of the two to make the whole pad a common mixed color.

I thought about using the ball on both sides, one side per frame, but it will flicker. If I cannot tweak the kernel, I would probably try this. The mixed color is a good idea, but it would change as the target also changes its color and luminance.

 

I'll try some alternatives this night, so I'll probably release a WIP binary tomorrow.

 

32 minutes ago, Karl G said:

You may want to post questions about the game in the batari Basic subforum.

At the moment, programming in bB has not been as hard as I thought, but I'll go there for the minikernels for sure.

 

Link to comment
Share on other sites

I almost forgot - there is also a paddle minikernel that reuses a player object at the bottom of the screen, so you can have a pad of your own design and color without it being affected by the colors of the other objects:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#paddle_minikernel

 

Link to comment
Share on other sites

After reviewing the kernel for the resulting ASM from my BAS code, it becames clear that it won't be easy to modify it, and as I said, I supposed that minikernels might be the way... or the option to write a custom kernel for the playfield.

 

25 minutes ago, Karl G said:

I almost forgot - there is also a paddle minikernel that reuses a player object at the bottom of the screen, so you can have a pad of your own design and color without it being affected by the colors of the other objects:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#paddle_minikernel

I have to check that, how it is integrated to the entire bB proccess, and if I could change it a bit to allow the transition of a player instead of a missile between the main kernel and this minikernel.

 

Anyway, I also tried the flikering ball solution for both halves of the pad and the result was ugly, because when the paddle is rotated, two consecutive frames might have different position values, and sometimes I got a narrower pad with a solid center or a wider one with a space...

 

Then I tried the mixed color between the ball and the missile. This time the result was better, but there is a visual glitch in the transition between the two objects, probably because the pad can change its position faster than what a joystick controlled object could do. To avoid the mixted color to change as a consequence of the target's color change, I swapped both players.

 

I couldn't figure out on how to take a screenshot (snapshot) of the mixed frames, but I attached the demo's binary ROM file so you can see by yourself.

 

Please comment about the dynamics. Is it too slow or fast?

 

Thanks!

 

Bounce-demo1.bin

Link to comment
Share on other sites

10 minutes ago, vitoco said:

I have to check that, how it is integrated to the entire bB proccess, and if I could change it a bit to allow the transition of a player instead of a missile between the main kernel and this minikernel.

Yeah I guess it would take a bit of reworking, as it uses the P1 object for the paddle graphic, so it would have to be changed to use P0 (easy), and the drawing of M0 would have to be changed to P1.

 

12 minutes ago, vitoco said:

Please comment about the dynamics. Is it too slow or fast?

 

I think the speed feels about right. It's tricky, but a bit of practice would help with that. Your scoring mechanic is clever.

Link to comment
Share on other sites

Humpf... Some things weren't working in my game as intended, and that was because I thought that the screen limits for the player's pixels were (0,0) and (159,88) as those values are in the bB docs and other tutorials, but I learned this today by brute force:

 

  • player0x and player1x must start from 1 and the max horizontal position should be 153 to make all 8 pixels be inside the playfield (in standard width).
  • player0y and player1y must start from their own height to be placed on the line at the top, and the max vertical position is always 88, regardless of their height.
  • The top row of player0 is never displayed in the playfield's top row.
  • The two players won't be shown starting at the same line for the same Y value if their sizes are not the same.
  • Missiles and the ball are 1 pixel longer than their respective missile0height, missile1height and ballheight.
  • missile0x and missile1x must start from 2 in standard width, and the max horiz position is 161.
  • missile0y must start from its own real height (missile0height+1), but it is displayed 1 scanline later.
  • missile1y must start from its own real height (missile1height+1).
  • ballx must start from 2 in standard width, and the max horiz position is 161.
  • bally must start from its own real height (ballheight+1), but it is displayed 1 pixel later (2 scanlines).
  • Players, missiles an ball sizes should be considered in a different way when used to test collisions by software (when using flickering).

 

Changing the width of the players or missiles makes horizontal position change, at least for player0, which seems to start from horizontal position 0 in double width (16 color clocks wide).

 

As I'm a newbie in bB, I'm not sure if all of these issues depend on some kernel options.

 

Could someone confirm these?

 

Thanks!

 

Link to comment
Share on other sites

41 minutes ago, vitoco said:

Since my previous post I have done nothing in this game. I think I have to change how I built this game in bB, because I don't like the results. It feels crappy both in Stella and real hardware. What do you think? I'll let you try the latest build, attached!

 

Bounce-demo2.bin 4 kB · 4 downloads

 

It seems like bouncing off of the paddle at the bottom is better in this version if I am remembering the last version correctly. This version looks good, too. After you catch a number, you need to reset your timer that you use for counting down the numbers, though, because sometimes the "9" lasts almost no time at all when it starts over.

Link to comment
Share on other sites

16 minutes ago, Karl G said:

It seems like bouncing off of the paddle at the bottom is better in this version if I am remembering the last version correctly. This version looks good, too.

I don't like the fact that I had to combine 2 objects to build a pad. Also, bB returns me half of the paddle resolution (result of the two lines kernel), so the pad also moves only trough even positions (every two pixels or color clocks), which makes harder to give the bouncing ball a direction.

21 minutes ago, Karl G said:

After you catch a number, you need to reset your timer that you use for counting down the numbers, though, because sometimes the "9" lasts almost no time at all when it starts over.

Every bounce adds one point. When you catch a target, you get a hundred times the target value, but if you catch it when the ball is going down, it adds three times that score. As the new target appears immediatelly after you got one, the "9" target only lasts until the ball bounces again... if you were going down, it lasts for less than a second... Then, you are lucky if you catch a nine.

 

I'll start programming this game from scratch, trying to build a kernel where one player could be used for both the target and the pad, without affecting the ball shape in the transition. One way to get that it could be to do the horizontal reposition at two different heights between the target zone and the pad area, depending on which is the current height of the ball.

 

Link to comment
Share on other sites

ZeroPage Homebrew is playing BOUNCE & CATCH on tomorrow's (Tue Mar 2, 2021) stream LIVE on Twitch at 6PM PT | 9PM ET | 2AM GMT! Hope everyone can watch!

 

 

Games:

 

 (SET VIDEO TO 1080P60 FOR FULL QUALITY)

 

 

Edited by ZeroPage Homebrew
Link to comment
Share on other sites

As I said, I started again from scratch, this time in assembly (no bB for a while). This is how it looks like:

 

bounce_1.png.c0390b15155e7b312f9512d24c75d068.png

 

The new code uses one player for the bouncing ball, and another player for both the target and the pad, and this pad can be curved now as I wanted.

 

I used a single line Kernel, so all the bitmaps are more detailed than before.

 

There is still a scanline that I have to hide by moving it up or down as needed, because the ball shape is being affected by it when it goes through that line.

 

I also had to include a 6 digit score, so I took the one from the 1997 explaination by Erik Mooney that he posted in a mailing list, but I had to deal with the setup for it. If I have the need, I'll try to modify it in order to include more info in that portion of the screen.

 

The attached binary is playable, but it does not include the features I have in my mind for the gamplay.

 

BTW, the green lines are there only for debugging purposes, and they will be removed later (I'm thinking about leaving the leftmost and rightmost columns in order to show where are the playfield limits for the lateral bounces).

 

Does someone have any idea about game variations to be included?

 

 

Bounce-demo3.bin

  • Like 2
Link to comment
Share on other sites

19 hours ago, vitoco said:

Does someone have any idea about game variations to be included?

My ideas:

 

- Similar to the original A8 game: Targets are static and are located randomly in the playfield. You have a single ball and bounce it for a given time (4 minutes) trying to score the highest possible without loosing the ball. In the A8, every bounce takes 4 seconds (it is Atari BASIC speed), and this time it takes 2 seconds. Then, you can bounce up to 120 times in 4 minutes.

 

- Unlimited number of bounces with a single ball with static targets.

 

- Unlimited number of bounces with a single ball with moving targets.

 

- Unlimited number of bounces with a single ball with moving targets, and their speed increases at certain points (up to a reasonable limit).

 

- The same variations with limited number of bounces.

 

- The same variations with a number of balls.

 

- Make the ball bounce on targets instead of going through them.

 

- Introduce a special target to obtain an extra ball.

 

- Two players "sobotage" mode: the second player controls the target with a joystick, avoiding being hit by the ball.

 

 

  • Like 1
Link to comment
Share on other sites

Changelog:


- Increasing the speed of the target: done! The target moves from side to side at a constant slow speed, but if the target count reaches 0, the speed of the next target will increase a bit when the zero target got catched.

 

- The extra scanline in the middle of the screen was hiden by moving it depending on which is the height of the ball, so it's bitmap won't be stretched again.

 

- FX: included! I included the sound tracker I wrote for my previous game, with the same sounds just to test. I'll change that later.

 

I'm still waiting for comments, ideas, whatever... ?

bounce-20210309-demo4.bin

  • Like 1
Link to comment
Share on other sites

Changelog:

 

- Added a floor. The ball must not touch the floor or the game ends.

 

- Added a timer bar. The timed games allows to play for 80 bounces (2m40s) and the objective is to score the maximum in that time. The PF and the BL where used to build the colorful timer bar. When the time is over, the pad turns gray and it won't receive a ball.

 

- Shades and colors for the targets. They are no longer solid.

 

- Shades for the pad, to give a little of shine.

 

- No shades for the ball... :( C'mon, it's a single line kernel (1LK) with paddle reading code!!! Also, the ball does not roll when it is not moving.

 

- The playfield (arena) was shrinked from 180 to 174 scanlines to give space to the timer bar.

 

- There was a glitch in the pad when the ball bounced near the left border, because the paddle (POT) jitters when the ball was about to touch the pad as a consequence of moving the player reposition scanline for the pad, skipping a POT lecture.

 

With all those changes, it looks like this:

 

bounce_2.png.01e00b2624b93a71249519f74c236c2a.png

 

There are two issues that disturb me:

 

(1) The black line in the ground as a result of the HMOVE for the score. To hide it, I could turn the whole line black or from that line to the end of the screen, leaving the score with black background as before. I'm not sure which of these is better... suggestions?

 

(2) The pad is floating over the ground. Might I change it in order to lay it in the ground?

 

Next steps:

 

- I need to reorganize the code. I'm not sure how much space is being used, because there are many tables that were lined up to a memory page, with many blank areas, so the game had to be changed to 4K to allow compilation.

 

- I want to add a title screen or a simple game mode selector. It will depend on the used memory in order to fit 2K...  BTW, might I use the AA logo in this game?

 

Sorry, no binary this time... ?

Edited by vitoco
  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...