Don't go! (WIP)

[vitoco]

I added randomization to the play in the following ways:

• The ball starts rolling to any of the 4 corners.

• The ball might be randomly bounce at normal speed or double speed (very like the original A8 version of the game).

But I'm quite frustrated! The game becames unplayable... I had to limit that only horizontal or vertical speed might be doubled, but not both at the same time. It's still too fast!!! The most I could get was 28 points.

 

I've attached the updated demo to let you try it and to answer the following question:

 

How could I solve this ball speed issue? Freezing some frames? Slowing down normal speed to the half of it, so what I called "normal" becames "fast"? Allowing fast speed only on the vertical axis?

 

Thanks!

 

++Vitoco

 

dontgo-20200919-demo.bin

[Just Jeff]

To slow down by 50%, add a frame counter, then AND it with #%00000001, then execute moves only when bit D0 is equal to either 0 (or 1 if you prefer).  I would start with slowing the horizontal speed first since having half the resolution of the vertical makes it move twice as far with each increment or decrement.

 

Something else that is making it difficult is the edge boundaries being right at the front of the paddles.  Maybe put a little more slack in there.

Edited September 22, 2020 by Just Jeff

[vitoco]

4 hours ago, Just Jeff said:

To slow down by 50%, add a frame counter, then AND it with #%00000001, then execute moves only when bit D0 is equal to either 0 (or 1 if you prefer). 

I went into another solution: 16-bits coordinates for each axis, one byte to match the pixels and another for a fraction of a pixel. Doing this way, I can advance just 3/4 of a pixel on each frame adding $C0 to the LSB byte (with carry into the MSB).

 

4 hours ago, Just Jeff said:

I would start with slowing the horizontal speed first since having half the resolution of the vertical makes it move twice as far with each increment or decrement.

Unfortunately, the horizontal pads also doubles the speed of the vertical ones, so slowing down the ball increases the difficulty when the ball moves diagonally.

 

4 hours ago, Just Jeff said:

Something else that is making it difficult is the edge boundaries being right at the front of the paddles.  Maybe put a little more slack in there.

I've thought about that, but it is not a priority. That would need change in the kernel for the pads at the top and the bottom of the arena. By now, I'm trying to keep this game within 2K.

 

Thanks for your comments!

 

Updates:

• Changed the coordinates system into a 2 bytes one. The MSB stores the actual pixel position on screeen and the LSB is used as "decimals" or a fraction of pixels (subpixels). This allowes the ball to bounce on any desired angle, and to slow it down if needed, but sometimes the movement seem to be a little jerky. Some random bits are included in the LSB to enhance difficulty.

• Completed a game with increasing difficulty (in speed and bounce angles). Some fine tuning might be needed.

• Completed a game with curved bounces and increasing difficulty, but fine tuning might also be needed.

• Enabled the Game Select switch to select the game.

 

Next steps:

• Include a game where the direction could be controlled by the pad during the bounce.

• Include a game with a zig-zag (tron like) movement of the ball.

• Include backbounces as a variation for the completed games and the now ones.

• Make some changes in the code to reuse routines from the completed games in the new ones.

Stay tuned!!!

 

 

[+SpiceWare]

On 9/19/2020 at 7:03 PM, vitoco said:

How could I solve this ball speed issue?

 

use fractional positioning, also known as subpixel.

 

 

Edit: you posted that you'd figured it out while I was searching for this link

[vitoco]

25 minutes ago, SpiceWare said:

use fractional positioning, also known as subpixel.

I was thinking about a fractional method to implement what I called "parabolic bounce", but I had my concerns about it on where to position the player (rounding vs truncating) and how it would work on edges. When I got stuck and frustrated, I took a breath, calmed down and started to implement the two bytes routines for testing purposes and applied it to the standard gameplay, which it could allow me set speeds from 0.5X to 1.5X. I was looking for "rounding" techniques on binary numbers (like checking for bit 7 of LSB) when I found the "subpixel" concept.

 

Thanks Darrel. Most of the improvements in my code are due to your posts and tutorials. ?

 

BTW, I kept truncation because, after all, I was already truncating on edges for 2X and 3X speeds, so it seemed to work fine also with fractional speed. Also, "parabolic bounce" didn't look good enough during the gameplay and became "curved bounce".

 

[vitoco]

Changelog:

• A "back bounce" variation was added to both current games.

• A third game (zig-zag) was added, including the "back bounce" variation.

 

The 2K limit was exceeded. I had to move the starting address to $8000 for a 4K ROM and found that my code finishes at $F814, that is just 26 bytes more than the 2K limit (20 bytes plus 3 vectors), so I have to go into the code optimization.

 

The code has 6 selectable games in total, but I really want to include the controlled bounce game and a "crazy" game (to randomly change the game type on every bounce or round), and I think that those don't require too much extra bytes to keep a 2K version.

 

I don't think that my code was quick and dirty, but I know I have to finish the mini sound tracker and save many bytes from the FX data by compressing them. I feel that all my previous packaging and optimizing experience with BASIC tenliners would help here, at least to decide which features to include in the final version and which ones to remove.

 

Let's see how this goes...

 

BTW, about NTSC vs PAL: Which is the current procedure or best practice to make a game to look and feel the same on both systems? Adjust color palettes, the number of scan lines, drop or repeat frames for speed, compile both versions or allow a single version to autoadjust, ...  Links or hints? ?

 

[+SpiceWare]

Easiest for PAL is PAL60 - just change the colors and everything else stays the same.  I use constants in my games to control this, from Stay Frosty:

 

;----------------------------------------
; Constants
;----------------------------------------
; COMPILE_VERSION
;   Set to NTSC or PAL to set the color constants to the appropriate values
;   NOTE: we're doing PAL60 so the timing values aren't changed
;----------------------------------------
NTSC        = 0
PAL         = 1

COMPILE_VERSION = NTSC
;COMPILE_VERSION = PAL

 IF COMPILE_VERSION = NTSC
ICE_TOP_COLOR    = $9E ; light blue
ICE_COLOR        = $9A ; blue
ICE_BOTTOM_COLOR = $96 ; dark blue
SUN_COLOR        = $18 ; yellow
DAY_SKY_COLOR    = $80 ; blue
FIREBALL_COLOR   = $38 ; reddish orange
HAT_BAND_COLOR   = $44 ; red
 ELSE
ICE_TOP_COLOR    = $9E ; light blue
ICE_COLOR        = $9A ; blue
ICE_BOTTOM_COLOR = $96 ; dark blue
SUN_COLOR        = $28 ; yellow
DAY_SKY_COLOR    = $D0 ; blue
FIREBALL_COLOR   = $48 ; reddish orange
HAT_BAND_COLOR   = $64 ; red
 ENDIF

 

[vitoco]

Changelog:

• I forgot to mention that the number of extra balls was increased from 2 to 4, some versions ago, and I'm thinking about a way to recover lost extra balls during the game.

• I completed the FX mini tracker and that saved many data bytes from the "samples", and went back to 2K.

• With the extra free bytes, I added the routines to include a 4th game: "controlled bounce". The idea is to be able to control the bounce direction depending on which side of the pad touches the ball. The pads were divided in 3 zones, giving 3 different angles, but all in the same incoming direction, for instance 110°, 135° and 160° (plus a random variation to avoid sequences during the play), but there is no backbounces (lower than 90°). Some fine tunning is needed and there is no speed increase during the game yet.

The size of the current version is 2K+8 bytes!!! I know that some more bytes could be recovered from the sound FX data, and reorganizing the code to remove JSR from subroutines that are called just once (4 bytes each time). A few more tricks should also be used to save bytes, but the code will be obfuscated a little.

 

 

On 9/23/2020 at 12:20 PM, SpiceWare said:

Easiest for PAL is PAL60 - just change the colors and everything else stays the same.  I use constants in my games to control this, from Stay Frosty:

What about the number of scanlines? Do I have to fill with blank scanlines? Where?

 

BTW, do PAL CRTs support PAL60?

 

[+SpiceWare]

12 hours ago, vitoco said:

What about the number of scanlines? Do I have to fill with blank scanlines? Where?

 

PAL60 = PAL colors + NTSC timing, so the same 262 scanlines.

 

NOTE: PAL requires the line count to be even, if its odd then the image will be black & white. There's a Developer setting in Stella that will emulate this color loss - be sure to turn it on:

 

 

Quote

BTW, do PAL CRTs support PAL60?

 

If you check the AtariAge store you'll see a lot of 2600 games are available using PAL60, such as Juno First by @cd-w who's from the UK.

 

 

There's also this topic by @davyK of Ireland, where NTSC games are being converted to PAL60 because they often look and play better, such as Kaboom!

 

 

 

[+SpiceWare]

You should also be aware that Stella does not auto-detect PAL60.  You can change the setting in Stella:

 

 

Newer builds of Stella support a filename override, which is even easier as then nobody else has to change Stella's TV Format to PAL60.  To do this just make sure your ROM's filename ends with _PAL60.  The _ is important, mm20100612_PAL60.bin works:

 

 

but mm20100612PAL60.bin does not:

 

 

 

[vitoco]

Thanks again, Darrell.

 

Changelog:

• The color palette for NTSC was modified to match a palette for PAL, which it can be selected at assembly time by defining "PAL" symbol in the DASM command line.

• The colors for left and right pads were swapped to create a better colors contrast on the bottom-right side of the screen, where the extra balls are displayed.

• The ball now bounces over the pads and not in front of them, as @Just Jeff suggested.

• Added speed up to the controlled bounce game.

• I made some code adjustments that allowed me to add the backbounce variation for the controlled bounce game.

 

This is how it looks in PAL60, with the ball bouncing over the right pad:

 

 

This new version with 8 games is 29 bytes over 2K... I have to continue exploring the code in order to fit a 2K ROM.

 

14 hours ago, SpiceWare said:

If you check the AtariAge store you'll see a lot of 2600 games are available using PAL60, such as Juno First by @cd-w who's from the UK.

 

Which are the requirements and the procedure to publish a game in the store?

 

BTW, @Al_Nafuur, I bring back my VCS from where I stored it and opened it to check its board. It happens to be a 2600A rev 13 board (C015519) from 1980. Even when I haven't remove the shield to check the chips, it looked like quite good, better than I expected from the upper side, but in the bottom side there are strange "bubbles" under half of the traces. I think I can scratch a bit to check what is going on there, but I'll test it first to be sure it is still working.

 

[+SpiceWare]

11 hours ago, vitoco said:

Which are the requirements and the procedure to publish a game in the store?

 

Send a PM to Albert

[vitoco]

Changelog:

• I could reduce the size of the code about 11 bytes by removing the diagonal starting movement of the ball. When I wrote the zigzag game, a diagonal starting was not appropiate, so I added a horizontal or vertical start for that game, which it also became the default for the curved ball game. Now, it is the only way to start a game.

• I couldn't resist and added a 9th game: Crazy. On every bounce, it randomly selects one of the previous games. This cost me another 26 bytes.

• I made many other small changes and optimizations to recover more bytes.

 

Current size is 2K + 10 bytes, not bad for ((4 bounce types)*(2 variations)+(1 randomized))*(2 pad sizes)*(2 no/extra lives)=36 game posibilities!!!

 

I can save some more bytes by going back to a linear flow instead of routines, but I'll work with the sound FX first. I think I can improve sounds and save some bytes from its data at the same time.

 

On 9/26/2020 at 2:21 AM, vitoco said:

I bring back my VCS from where I stored it and opened it to check its board. It happens to be a 2600A rev 13 board (C015519) from 1980. Even when I haven't remove the shield to check the chips, it looked like quite good, better than I expected from the upper side, but in the bottom side there are strange "bubbles" under half of the traces. I think I can scratch a bit to check what is going on there, but I'll test it first to be sure it is still working.

I took break from coding today and tested my 2600 with a CRT TV. The issue I discovered some years ago is still present, so I posted it in another thread: 

 

 

++V

 

[Prizrak]

@vitoco any way I can get updates to upload them to PlusCart? I keep seeing changelogs but no files uploaded.

Sent from my SM-N960U using Tapatalk

[vitoco]

On 9/27/2020 at 9:54 PM, Prizrak said:

@vitoco any way I can get updates to upload them to PlusCart? I keep seeing changelogs but no files uploaded.

I haven't uploaded more demos of the game because I don't want to spread many versions of it. This was too fast for me and the game is almost ready, but I need to reorganize the code to fit in a 2K ROM. Except for DASM, Stella emulator and a spreadsheet (to design the score fonts and to compute some values to build bounce tables), I programmed it using no tools or hardware enhancements, a kind of personal challenge just to learn about the 2600 architecture. Please be pacient... I'll probably send you a beta version for testing purposes! ?

 

[Prizrak]

That's ok, thought maybe I was missing something. Nice to see your project coming along nicely.

Sent from my SM-N960U using Tapatalk

[+atari2600land]

Really hope you can fit this in 2k. I love 2k games.

[vitoco]

Changelog:

• A macro was using too many instructions on every use, so I changed it by some smaller ones given a coding restriction I set for this game, allowing me to save many bytes.

• It is possible to recover extra balls every N number of continuous bounces or stages, but I haven't decided which number should N be, either for bounces or stages. During my tests I could reach 587 bounces by recovering balls every 2 "clean" stages (full stages with continuos bounces), and 4 extra balls as the maximum (5 balls in total). That was in the "standard" mode (Game 1), and the best score I prevously got without recovering balls was 209, but I don't remember which game mode I was playing.

 

 

18 hours ago, atari2600land said:

Really hope you can fit this in 2k. I love 2k games.

The current size is 2K minus 6 bytes, but I want to add another sound FX and that would require more than those 6 bytes. I haven't changed current sound data yet, and that could save more bytes. That will be a long session of FX tests, trying to remember which data sequences sounds better than other attempts.

 

I have two open questions about extra balls:

• How many extra balls should this game have? 2, 3 or 4? (extra balls are additional to the one in the arena).

• How many continuos bounces (without loosing a ball) should be a nice number to recover an extra ball? Should them be by the number of stages, or the number of bounces counted by themselves?

BTW, a stage is completed every 10 bounces, every stage is harder than the previous, and every game mode has its own number of stages. The last 3 stages for a game mode are repeated in a loop at completion. Max score is 999 bounces.

 

Thanks!

 

[+atari2600land]

IMHO, without playing a recent build, I would think just 2 extra balls would be too few.

I would count the extra ball getting to depend on stage completion, if just only to save space.

[vitoco]

Changelog:

• I could finally catch a bug that appeared very few times. It was related to the ball height and the fractional positioning. The solution used those 6 extra bytes.

• The extra balls are now recovered every 25 continuous bounces instead of 3 continuous stages.

• The bounces tables were fine-tuned, with more stages and difficulty. This require to simplify sound FX by removing data from there and transfer the bytes to the tables.

 

The game is almost finished. A trimmed demo version is attached (for NTSC and PAL60). Please let me know how it feels, if it is too hard or too easy, if the number of extra balls is appropiate or it should be less, how to improve the sound FX or colors, whatever you like/dislike... CRT screenshots are welcome, and also your score!!!

 

In this demo version, only games 1 and 5 are available. Both are the same game mode, except that mode 5 features "backbounces". Use Left Difficulty switch to change pad sizes, Right Difficulty switch for the number of extra balls (4 or none), TV Type to select Color or B/W, Select switch to change the game mode, and Reset to start the game. Paddle's trigger can be used only to restart a game, but pressing any of the console buttons disables the trigger. When you complete a stage, you will hear a "ding", and you will also be notified each time you recover an extra ball.

 

Have fun!!!

 

dontgo-20201002-demo.bin dontgo-20201002-demo_PAL60.bin

[+atari2600land]

Is the full version 2k?

[vitoco]

11 minutes ago, atari2600land said:

Is the full version 2k?

Yes, the full version uses exactly 2K.

 

With this trimmed version I want some feedback, specially about sounds, in order to fine tune/change or whatever, and (crossing my fingers) I expect that any change won't require more bytes...  

 

[+atari2600land]

I love it! The sounds are fine the way they are. The only thing that bothers me is the shape of the 5 digit. I think it might be confused with a 6.

[+atari2600land]

Any updates to this?

[vitoco]

While I'm waiting for feedback, I have been modding my VCS and finished it today. But I discovered that I lost the 4 console screws, which I removed about 5 years ago when I turned it on for the first time after 30 years and discovered that there was a lot of interference. Every screw I tried didn't fit, and the Service Manual didn't list them. I just want to try my game in the real hardware, so I was also checking some of my old cartridges for a donor one where I could fit a 2K EEPROM. I've found unexpected things inside some of them.