Questions Galore!

[Cybearg]

Oh, right. It had been that way, but it got cut out at some point here when I was trying something.

 

And yes, that's not the extent of the problem, since it is still there after I've added that back in.

 

This still doesn't work:

 

rem BOUNCY BALL

rem possible values for bouncing within circle
temp1 = rand
temp2 = temp4 / 2

if temp1 <= 85 then anglevar = (temp2 + 3) & 7
if temp1 > 85 && temp1 <= 170 then anglevar = (temp2 + 4) & 7
if temp1 > 170 then anglevar = (temp2 + 5) & 7

[bogax]

Why did you go back to doing the collision detection

in code?

 

Is it possible you're colliding more than once?

Perhaps you should set the position out of bounds

for a bounce and see if that helps.

[Cybearg]

Because I need to know which pfpixel the ball collides with so I can compare colors. Since, so far as I know, the game doesn't return any information about where collisions happened, I have to have soft collisions as well to determine where it took place.

 

Maybe it's colliding more than once, but all of these blocks are destroyed upon collision (or they should be), so if they're not doing so, I don't know why.

[iesposta]

Somebody said, "Don't use temp, it can't be trusted."

Try it with fixed variables.

Unrelated: Also, did you see my post about using an older DASM from 2003, or are you using the latest? Which are you using?

[Cybearg]

Somebody said, "Don't use temp, it can't be trusted."

Try it with fixed variables.

Unrelated: Also, did you see my post about using an older DASM from 2003, or are you using the latest? Which are you using?

Temps work a little differently now because Omega built me a new kernel that doesn't utilize memory the way the standard kernel does. He hasn't informed me of any concern over using temporary variables.

 

I had intended to switch to the 2003, but now that I check, I guess I'm still using the 2008 DASM. Do you think that would cause the issues here?

 

EDIT: Just tested with the 2003 DASM. Same problems.

[Omegamatrix]

Basically with the new kernel there are no bits for the playfield stored in ram. The standard kernel has been removed and replaced with a custom assembly one so locations $A4-$D3 are now free ram. I believe those locations are different then the locations BB has put aside for temp ram though.

 

In short, the assembly kernel doesn't touch the BB temp ram at all.

[Cybearg]

Basically with the new kernel there are no bits for the playfield stored in ram. The standard kernel has been removed and replaced with a custom assembly one so locations $A4-$D3 are now free ram. I believe those locations are different then the locations BB has put aside for temp ram though.

 

In short, the assembly kernel doesn't touch the BB temp ram at all.

I don't think I ever asked, but are temp1-temp6 cleared during a drawscreen, like they used to be? I've been coding under the assumption that they're cleared every full loop, though I don't know if that could be the root of any of these problems or not since everything still functions correctly for the normal game.

[bogax]

Not sure I'm following what you're doing.

It looks to me like you do the normal thing,

except sometimes you also bounce.

 

Because I need to know which pfpixel the ball collides with so I can compare colors. Since, so far as I know, the game doesn't return any information about where collisions happened, I have to have soft collisions as well to determine where it took place.

 

There's still only certain possible collisions depending on anglevar

they just change if you've bounced.

 

 

Maybe it's colliding more than once, but all of these blocks are destroyed upon collision (or they should be), so if they're not doing so, I don't know why.

 

If the block was not destroyed you could collide with it again(?)

(assuming you could collide more than once at all)

[iesposta]

 

Temps work a little differently now because Omega built me a new kernel that doesn't utilize memory the way the standard kernel does. He hasn't informed me of any concern over using temporary variables.

 

I had intended to switch to the 2003, but now that I check, I guess I'm still using the 2008 DASM. Do you think that would cause the issues here?

 

EDIT: Just tested with the 2003 DASM. Same problems.

DASM shouldn't cause the issues here. The newer subversion will cause compile errors, so if you can compile a bin DASM is ok.

When I see "it should work" and code with temp my first thought is "don't use temp"

[Cybearg]

I used to determine collisions based on anglevar, but with the potential that the ball could collide with other bricks, particularly since there may be a game mode where blocks 1, 3, 5, etc. can be hit, I figured it was best to just implement "true" collisions and not the fake ones.

 

I'm trying to implement multiple game modes. So mode 1 is normal Heartbreak, but mode 2 (hitting left or Select while on the menu screen turns the heart yellow, which is mode 2) switches up the gameplay by having the ball bounce and persist after a hit, rather than being destroyed with the block.

[Cybearg]

Omega pointed out a mistake--that collisions can continue to happen since the ball will likely be within a hit box for more than a single cycle, so I have added some code to prevent this, namely:

 

if lasthit = temp4 then goto 760 else lasthit = temp4

 

... And I've incorporated some of the fixes that people pointed out, but the problems of the ball getting "bad" hits when all hits should be good and the ball going off at wrong angles are still there. I've attached the latest version, in case anyone can figure out what stupid mistake I've made while I keep looking as well.

heartbroke.zip

[bogax]

I used to determine collisions based on anglevar, but with the potential that the ball could collide with other bricks, particularly since there may be a game mode where blocks 1, 3, 5, etc. can be hit, I figured it was best to just implement "true" collisions and not the fake ones.

 

If you bounce, there's still only one possible block to collide with

the possible target block will be +4 +8 +12 of what it was in terms

of block number, but there's still only one possibility for a given

angle. Which of those three depends on how the angle changed

 

I think you only change position by +-one max on each pass?

So if you collide with a block on it's left edge and it's not destroyed,

and you bounce to the right won't you collide again on the next

pass because you haven't moved the four (or what ever) positions

you need to take you beyond the right edge.

 

Also, if you limted the collisions by angle you wouldn't be able to

collide with the same block again.

Edited February 17, 2013 by bogax

[Cybearg]

Hm, that's true. Let me try implementing the old collision style and fiddle around with it a bit.

[Cybearg]

Well, I went back to the old collision "detection" style and tried implementing some math to determine what the new block would be, but things just go bonkers, now. Hits count on multiple blocks, some blocks recognize no hits, and the ball still careens off in directions that should be mathematically impossible.

 

Changes:

 

Added a special check in the case that, when selection = 1 (which means mode #2) and it is not the first shot (assuming that the first shot can be recognized because it will break a block, though that may not be the case and will have to be rewritten later), use a slightly different number to determine which block will be hit in a successful collision. It's the same as before, just with a +4 or - 4 (aka + 12) for high and low, respectively:

rem double anglevar in order to determine how the number relates to a 0-15 range rather than a 0-7 range
temp4 = 4 - anglevar
temp4 = (temp4 + temp4)  & 15
if selection <> 1 || blkcount = 16 then goto hit_type

offsetcollisions
temp4 = (temp4 + angleoff) & 15

hit_type

rem checks for various hit-types

 

... which is set up with the addition of angleoff (angle offset) for whether it was a min, med, or max hit.

 

rem possible values for bouncing within circle
temp1 = rand
temp2 = temp4 / 2

if temp1 <= 85 then anglevar = (temp2 + 3) & 7: angleoff = 12
if temp1 > 85 && temp1 <= 170 then anglevar = (temp2 + 4) & 7: angleoff = 0
if temp1 > 170 then anglevar = (temp2 + 5) & 7: angleoff = 4

ballspeed = (ballspeed + 1) & 15

 

This doesn't fix anything and to the contrary makes things worse, but it's closer to what seems like should be "correct," if I knew what the hell was going on in the first place.

[bogax]

Did you remember to reset angle off when you spawn a new

ball?

 

You might want to use a different offset if you'vealready bounced

 

Do you really want an out of bounds to go to bad hit?

[Omegamatrix]

I just sent off an updated assembly kernel that checks the collisions, and returns which block was hit (stored in a register I called cxBlock for collision block). Then the BB kernel can just use that as index.

 

When there is no collision on the frame just drawn the cxBlock register holds $FF. When a hit occurs the cxBlock register holds which block (0-15) as given by the numbering diagram earlier.

[Cybearg]

I discovered some of those problems as well, bogax, though that wasn't a full fix.

 

Since Omega saved my bacon with the collision report, I'm going to go back to before I started adding this mess and build it back from the ground up. Hopefully I'll catch any problems along the way. If not, I'm sure everyone will hear about it.

[Omegamatrix]

I don't think I ever asked, but are temp1-temp6 cleared during a drawscreen, like they used to be? I've been coding under the assumption that they're cleared every full loop

 

I just looked at what BB does, and it doesn't actually clear these registers. It does copy values over from other registers (some of which happened to be zero, but not all), but it doesn't go through and clear them. If you are every using any temp ram you should always assume that it doesn't hold a preset value.

[Cybearg]

Thanks to Omega, I've got the kernel handling collision detection now, which is a great relief! I've also gotten great advice, between him and you guys here, which showed me a number of little mistakes I was making.

 

As for the ball moving in impossible ways, that was simply me misreading my motion table for the different movement angles. I was thinking of y + 1 moving up, when it actually moves down, so my numbers were set up wrong, causing everything to be mirrored without me realizing it.

[Cybearg]

If there is anyone out there willing to test, this version is probably pretty close to "The End," but then I've said that before and here I am still.

 

This should work for the joystick, gamepad, and driving controller on the 2600 and 7800 (and I would love to know how it feels using each of those controllers, for those who are able to test it).

 

 

 

HOW TO PLAY:

 

The modes (chosen with left/right or the select switch and then selected with trigger or reset on the title screen) are separated by color:

 

Red: Classic Heartbreak: match colors until a block is destroyed. You earn points by destroying a block. Bonus points are awarded depending on which heart size you have left: 200 for small, 400 for medium, and 600 for large. After 3 incorrect matches, you lose a heat size. Once all blocks are destroyed, the level is complete.

 

Yellow: Bouncy Heartbreak: the same as above, except the ball bounces! Hit the trigger at any time and the ball will take on the current color of the heart. Points are awarded per bounce, so try to keep your ball in play! Bonus points are awarded for bouncing streaks: 200 for 12 bounces, 400 for 16 bounces, and 600 for 24 bounces.

 

Blue: Inverted Heartbreak: likely more difficult than the first two, this one works the other way around. You start with nothing and you need to start adding colors to make a white block. Only match colors that the block doesn't already have. Once all blocks are white, the level is complete.

 

Green: Inverted Bouncy Heartbreak: probably the most difficult, this is like Bouncy Heartbreak, except with inverted colors.

 

Hopefully everyone has fun with it! Note that this isn't the "final" version yet. I'd still like to do some kind of theme music if possible (and if someone is willing to write me something) and there may be minor game tweaks before the final version.

 

Special Options:

 

1. Turning the left difficulty switch to Pro will cause the ball to slowly increase as more blocks are completed.

 

2. Turning the right difficulty switch to Pro will disable the sound of the heartbeat, in case you would prefer not to hear it.

 

EDIT: Added updated version (rc16_2) which tweaks the driving controller response and removes hitting reset to select a game mode (in order to prevent a loop of the player accidentally holding reset too long and being bounced between the game and the title screen). Just use the trigger button to select a game mode, instead.

 

EDIT2: Changed Heartbreak's red and orange colors to hopefully stand out a bit more.

heartbreak_rc16_3.bas.bin

[Csonicgo]

I am loving this simple yet addictive game. Already loving the stages and how they progress.

[chas10e]

I'm playing on a PC with Stella.

 

somehow I missed looking @ the special options so both difficulty switches would be "novice" or the "b" setting

 

I need to get some sleep , I reached 20,000 on bouncy heartbreak (yellow heart option) and I enjoy it very much

 

I like the color changes on the hearts on title screen to denote different levels

 

I like the bouncy heartbreak over standard as you don't have to launch the ball for every broken brick ... keeping the ball in play & trying to determine if that color ball will change or eliminate the brick it's heading for is cool.

 

next time I will try the left "pro" or "a" setting ( gatta figure out how in Stella but will be easy )

 

the right difficulty I would leave the heartbeat on "b" ... during gameplay it doesn't sound monotonous ... with Stella I have to hit [alt+tab] to switch to another window usually chat ... the heartbeat still playing in the backround bekons me to come back & play ( I get distracted easy )

 

if I was playing on my television & walked away I would be concerned about the image getting burned into it as I see no "screen saver"

 

one bug I experienced ... only with yellow ball ... with no yellow affected blocks remaining ... I will get a raspberry sound & assuming a penalty on the 3 strikes rule if I allow the ball to miss the remaining blocks.

 

or mebbe it's supposed to do that ... ( doesn't seem to do that for red or blue )

 

I do not write any code , strictly an end user.

this is the first homebrew game that I played, the number of the others seemed overwelming to play as is the carts I already have.

tinkering with this game a bit does make me desire to get a Harmony cartridge so I could play with the actual controllers in question.

 

will have to report back on lvls 3 & 4 in the future. inverted heartbreak

 

thanks to Cybearg & all who helped get this project of his to this point ( I haven't read entire post . I came across this title via chat room where it's quite occasionally mentioned)

 

chas10e

[Cybearg]

Thanks so much to everyone who's tried the game and given feedback. It's very encouraging and much appreciated!

 

I wasn't aware that 2600 games typically had "screen savers." As it stands, I don't think that it will really be possible for me to add one in a practical way, though if that is very important, let me know and I'll try to figure something out.

 

 

one bug I experienced ... only with yellow ball ... with no yellow affected blocks remaining ... I will get a raspberry sound & assuming a penalty on the 3 strikes rule if I allow the ball to miss the remaining blocks.

 

As for the bug you experienced, which game mode (red, yellow, blue, or green) were you playing at the time? Were there any black blocks at the start of the level? Once white blocks get introduced, hidden black blocks do as well. Hitting those is bad, so try to keep track of where they are when you start as you won't be able to tell the difference between empty space and black blocks once you've broken most of the blocks.

 

If you can remember any more details that could help me to recreate the problem, it would be much appreciated!

 

And to everyone, thanks again for playing.

[chas10e]

I wasn't aware that 2600 games typically had "screen savers." As it stands, I don't think that it will really be possible for me to add one in a practical way, though if that is very important, let me know and I'll try to figure something out.

some games have cut screens ... one example is Ms Pac-Man that I just got & played for first time ... just so image doesn't get burned into TV Screen ... I dunno if "screensaver" is the correct term or not

 

 

As for the bug you experienced, which game mode (red, yellow, blue, or green) were you playing at the time? Were there any black blocks at the start of the level? Once white blocks get introduced, hidden black blocks do as well. Hitting those is bad, so try to keep track of where they are when you start as you won't be able to tell the difference between empty space and black blocks once you've broken most of the blocks.

 

That must be what it is ... I noticed a missing block (or invisable) & didn't think much of it when I got to levels that included white blocks.

 

so it wasn't a "bug" it happened by design ...

 

I was playin bouncy heartbreak when I discovered it ...

 

discovery is half the fun of this game

[+SpiceWare]

I wasn't aware that 2600 games typically had "screen savers." As it stands, I don't think that it will really be possible for me to add one in a practical way, though if that is very important, let me know and I'll try to figure something out.

 

Earlier games used color cycling when the game was idle - load up Combat and let it set and you see it change colors like this:

 

I suspect they did the color cycling because they didn't have the ROM space to implement menus with attract modes.

Edited February 26, 2013 by SpiceWare