Cybearg

Is that enough to put the crash-car sprite back in? I didn't see a problem with that.

Wow... That's pretty amazing. As for uploading, you'll need a recorder of some kind. I take it by your question that you don't have FRAPS or something similar? It'd be best if you could get someone who had a registered version to do it. I'd offer, since I have registered versions of FRAPS and Bandicam, but I'd probably suck so bad at trying to play, I'd make it look bad. Kudos for all the news! That's pretty awesome.

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.

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.

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.

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

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

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.

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.

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.

I got a 2600 Darth Vader with joysticks, paddles, games, and peripherals. Everything worked perfectly and was superbly packaged. Package arrived well in time. AtariBrian was very communicative, so I never felt out of the loop on what was going on, and he very generously was willing to toss in freebies to sweeten the deal. Great seller!

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.

Maybe you'd have enough space left to allow the explosion sound to stop after a while if, instead of plotting out the entire playfield, you drew it with two pfvlines, instead: pfvline 0 0 11 on pfvline 31 0 11 on

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

... And just when I thought I was almost done, I'm back with MORE problems to flood the thread frantically with. These stuff is copied from a PM I sent to Omega, because the guy's a genius with Assembly, but he doesn't know BASIC as well, so maybe someone else will be able to point out where I went wrong: I was trying to create an alternate game mode where the ball bounces. Sadly, it seems like this won't turn out so well because of the awkward placement of the blocks, but I may be able to find a way to correct or compensate for it so it doesn't look so stupid. This led to two problems I've had: 1. I need the ball to bounce, but only in certain directions. I wrote out some code that can do software collision detection and it seems to work fine for what I need (at least in "selection" mode 0, i.e. the normal Heartbreak game), but there is a bigger problem: I needed to make sure that, when a ball hit a block, it would go in the correct angle and not fly somewhere out of bounds. Each of the 8 blocks that tend to get hits could have the ball go in 3 directions: either directly away from the block or at 45 degree angles to the left or right. I came up with a formula that seemed to work. Note that the anglevar variable references an array that says how much a ball moves in a particular direction. The array is set up with values from 0 to 7, with each possibility corresponding to an increase of 45 degrees. So if anglevar = 0, the ball is moving at a 0 degree angle (straight up). If anglevar = 1, it's moving at 45 degrees, etc. I randomly choose for a ball to go in one of 3 directions when it hits a block: a "min" direction, a "med" direction, or a "max" direction, each being separated by 45 degrees. I then figured out which directions a ball should be allowed to go for each of the blocks it hits and made a chart. The columns are the values anglevar can be without sending the ball flying out of bounds for each of the 3 random numbers. The rows are the index of the block (0 being the topmost block, 2 being the block at 45 degrees, 4 being the block at 90 degrees, etc. -- I didn't bother doing anything for the blocks at 1, 3, 5, etc. because the ball should never hit those) In this graphic, the outer numbers are equal to the index of the block for each location (used to determine a block's color, if a collision has occurred, etc.), while the inner numbers are the index locations for the possible angles (so you can see, 0 corresponds to a 0 degree angle, 1 to 45, etc.) min med max 0 3 4 5 2 4 5 6 4 5 6 7 6 6 7 8 ... I'm sure you can see the pattern. anglevar = (ballindex / 2) + 4 + (-1, 0, or 1, depending on the random number) For instance, let's say that the ball just hit block at index 6. It doesn't really mater which direction it came from, but we can see that there are only three "fair" directions it could move. It could either move in the exact opposite direction of the block, angle 7 (the "med" option) or it could move up or to the left (the "min" and "max" options) If you mentally move the angle compass, you can see that the above formula should work for every block at a 45 degree angle to the first block (0). This makes sense to me and it makes sense on paper, but the game just does NOT follow the mathematics, and I can't figure out why. Balls often careen out in directions that should be mathematically impossible, and I don't know why. For instance, when a ball hits block 6, it then goes down or to the right or down-right, but not always. Sometimes it goes the correct directions, but not in any reliable way. This is the code that I'm using for it. Note that temp4 is equal to the index of the block that the ball hit. I'm inclined to think that this works because the ball DOES reliably destroy the block it hits in the first selection mode, where the ball doesn't bounce (the "default" Heartbreak game). 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 <= 170 then anglevar = (temp2 + 4) & 7 if temp1 > 170 then anglevar = (temp2 + 5) & 7 ballspeed = (ballspeed + 1) & 15 I just don't see where it could be going wrong. 2. I use the soft collision detection mentioned above to determine which block the ball hits and what should be done. I've added options for white balls, which should break any block they hit, no matter what color it is (though I have to account for the blocks reacting accordingly, in the cases where they are multi-hit blocks). But for some reason I can't figure out, the collision detection often counts "bad" hits even though bad hits should be impossible for a white ball. It really baffles me because the code seems solid and I've gone over it again and again. It's almost like something's messing with the variables somewhere, but I can't figure out what it is. I'm stumped. Note if you want to see the problem in effect, you have to hit right once on the title screen to switch to the second (yellow) game mode. The first (red) one (the default Heartbreak game) seems to still work perfectly, so far as I can tell. heartbroke.zip

You could do some kind of soft collisions, though it would, of course, take more processing power. Start at the location of the sprite, then check if something is within the range of spritex - 1/2 sprite width and spritey - 1/2 sprite height to spritex + 1/2 sprite width and spritey + 1/2 sprite height.

This sorta explains it, though I couldn't get it to work.

That seems good to me. Could you also do one for the driving paddle? I've been struggling to get it to work, even after looking at the examples like zombie chase.

That's how I get by. I keep a d20 in my pocket and when no one is looking, I roll to see if I should ask a semi-relevant question, smile and nod knowingly, or stand on my head and fart the national anthem. Thankfully, the latter has only been rolled a couple of times.

Oh, will he never be working on that stuff again? :< I guess no one else is willing to take up his mantle? Because it would be awesome to see new possibilities being added and the potential of everything expanded upon.

Do it, loon. I kind of agree with loon. The amount of weave may be a bit excessive, especially since it largely comes down to chance: whether an oil stick happens to have spawned in front of where you were trying to go or not and whether or not the opening spawned close enough for you to reach it without careening out of control. Maybe making it 1/2 or 1/4 the current amount would allow it to come down to a bit of skill rather than pure luck.

After reading this post and fiddling around, I figured out what was wrong. The fixed, working score_graphics_timer.asm file that will allow the set romsize 2k option is attached below. The problem is this, from the top of the file: ifconst ROM2k ORG $F7AC As Gruff explains, since you're using a version of score_graphics.asm that's just had two extra sprites added (for the . and the : ), you need to decrease that ORG by the equivalent of 16 bytes, since each sprite is 8 bytes (1 byte per row, 8 rows per sprite), which leaves you with this: ifconst ROM2k ORG $F79C Also, if you change every "if something > 0 ..." to "if something ..." and every "if something = 0 ..." to "if !something ...", you save JUST enough bytes for sound effects. See attached. GateRacer.zip score_graphics_timer.asm

That's pretty awesome! If your game is under 2k, though, why not put it in a 2k cartridge? set romsize 2k Also, if you used a custom .inc inlcludes file, i'll bet you could get an extra 100-200 bytes by cutting out all the stuff you don't need.

Well, assuming that no one comes forward with a secret version of bB that I haven't mentioned above that has bugs fixed or something, is there any way to have two VisualbB installations that don't share registry locations? If I DCP is going to limit what can be done with earlier stuff and vice versa, I'll need two vbB installations that will point to two different bB convertors.

Great. Now I went and screwed everything up again. Apparently I didn't have the latest version of bB, because, although it was supported in Visual bB, the samples for DPC+ programs that I'd found weren't working, so I went and tried to get the latest versions that batari had posted, including 1.1 beta and then the later 1.1 for Windows 8 fix. Now Visual bB is back to spitting out "complex condition detected" errors every time I try to compile Heartbreak. Could someone please, please, please give specific links to the absolute latest and greatest versions of DASM, Stella, bB, and Visual bB in the precise order they must be installed? In spite of Random Terrain making it seem simple, those links are out of date and are not the latest versions, and whatever it is I'm doing, it's screwing things up and it's very frustrating. EDIT: Apparently, counter-intuitively, the latest version of bB is not, in fact, in batari's blog, but instead in the listing for VisualbB. So I've gone to jwierer's latest blog post to get the files for the latest VisualbB, his second-to-latest post to get the latest version of bB (1.1d) along with an updated .exe, and sed.exe from the Windows 7 64-bit fix pack in this thread (BUT NOT ANYTHING ELSE! Just sed.exe, because everything else is not the latest version) as well as the latest version of 2600bas.bat from the same thread, just above the bBWin7_64bit fix pack. Finally, I got the latest version of DASM from Sourceforge. The result? Heartbreak gets an error when compiling: [2/14/2013 12:21:49 PM] bblint found the following errors in heartbreak.bas warning(): Found 18 commands that use end, and 15 "end" commands. 2600 Basic compilation failed! LINE --> complex condition detected So now what? Is there a newer version of something somewhere else? If not, then what is this error and how can it be resolved? And what's the deal with that end command warning? In case it's just me, here's the source to Heartbreak. Can anyone else compile it? If so, what is your setup and do you have the latest version of everything? I have also attached the .asm file, where there are two spots a complex statement is located: .L0164 ; anglevar = ( rand / 32 ) ; complex statement detected lda rand lsr ifconst rand16 rol rand16 endif bcc *+4 eor #$B4 sta rand ifconst rand16 eor rand16 endif lsr lsr lsr lsr lsr STA anglevar . ; . ; .L0201 ; temp4 = temp4 + temp4 & 15 ; complex statement detected LDA temp4 CLC ADC temp4 AND #15 STA temp4 . ; And as another side note, I tried going back and testing the thing I was having trouble with before on my earlier version of bB (a DCP kernel sample) and it seems to work now, although it seems that I'm now limited to 6 banks for bankswitching? Because setting romsize 32k gives me an error: free ram: 9 DPC free RAM= old value: $0020 new value: $001c old value: $1ff4 new value: $1ff6 bytes of ROM space left in bank 1 bytes of ROM space left in bank 2 bytes of ROM space left in bank 3 bytes of ROM space left in bank 4 bytes of ROM space left in bank 5 bytes of ROM space left in bank 6 bytes of ROM space left in bank 7 -55448 bytes of ROM space left in bank 8 free ram: 9 DPC free RAM= 763 old value: $001c new value: $0020 old value: $1ff6 new value: $1ff4 old value: $0020 new value: $001c old value: $1ff4 new value: $1ff6 105 bytes of ROM space left in bank 1 3887 bytes of ROM space left in bank 2 4052 bytes of ROM space left in bank 3 4052 bytes of ROM space left in bank 4 4052 bytes of ROM space left in bank 5 4052 bytes of ROM space left in bank 6 4052 bytes of ROM space left in bank 7 -55448 bytes of ROM space left in bank 8 free ram: 9 DPC free RAM= 763 old value: $001c new value: $0020 old value: $1ff6 new value: $1ff4 old value: $0020 new value: $001c old value: $1ff4 new value: $1ff6 105 bytes of ROM space left in bank 1 3887 bytes of ROM space left in bank 2 4052 bytes of ROM space left in bank 3 4052 bytes of ROM space left in bank 4 4052 bytes of ROM space left in bank 5 4052 bytes of ROM space left in bank 6 4052 bytes of ROM space left in bank 7 -55448 bytes of ROM space left in bank 8 --- Unresolved Symbol List DPC_kernel_options 0000 ???? (R ) pfwidth 0000 ???? (R ) font 0000 ???? (R ) playfield 0000 ???? (R ) Fatal assembly error: Source is not resolvable. Errors were encountered during assembly. So is bankswitching broken in the latest version of bB? The example I was trying was from here as I was trying to find samples of what it even IS let alone what it does, since there doesn't seem to be any documentation anywhere. Heartbreak.zip heartbreak.bas.asm