Cybearg

If they seem annoying, maybe tone down the color. Make them a light grey instead of white so that they don't pop from the background so much.

Well, I've added the reset button. Current version is posted. Now time to move on to playtesting! There may be some things added still, depending on feedback. May increase the pulse over time or require more than one hit to destroy some blocks, but we'll see. heartbreak_rc1.bas.bin

Yeah, though keep in mind that you'd need 4 variables for each line, unless you reduced the playfield's size, since each line on the playfield has 31 blocks, which would require 4 bytes (aka for variables) to have a bit per block, but since there are 11 lines on the playfield, you'd need 44 variables set aside. There are normally only 26 variables available, a[0] to a[25], which is a to z, but that's it. So far as I know, you can't reference SuperChip RAM using the a[x] array-style notation.

Would it cost 20-30 per cartridge if I worked with someone to create them by hand? I saw that there was a site that custom-makes a cartridge for you at 25 a pop (possibly a bit less for bulk orders), but I assumed that creating one myself (assuming I had access to the equipment or to people who have the equipment) would be cheaper. It's odd that it's 536 bytes less than what's reported. That number is generated after the assembly file is created and compiled. it takes into account includes and such (which is why, if you make and compile a blank a blank game, it will only say about 3000 bytes left, since the other 1000 make up the kernel and includes. I could do a reset switch, but I didn't see the point, seeing as it's a game of progression. There is a gradual build throughout the first 6 levels, but by level 7, all the mechanics have been introduced, so the game just rolls random numbers for the colors as long as the player is willing to keep playing. The only other thing I could think of doing to increase difficulty is to speed up the heartbeat at higher levels so one has to react faster to get the color one wants, but that may be more annoying than challenging. The point is, why have a reset switch for a game that resets when you lose (which can be done easily by intentionally shooting the wrong colors) and has no consequences for doing the "wrong" thing? It's not like the player could find themselves in a situation where they're screwed and need to start over. As long as you have at least one heart, you can keep playing. And no, the change of colors at level 4 isn't a bug. It's part of the mechanics progression, like so: Level 1 - introduces the player to the mechanics of shooting balls from the heart and rotating the blocks to hit the ball, rather than the other way around. Level 2 - introduces two colors and the necessity to get the right color to the right block Level 3 - Introduces the three primary colors that the heart can be Level 4 - Introduces the three secondary colors -- instead of getting one heart color to the same color of block, the player can break a secondary color with any of the two colors that make it up (orange = red + yellow, green = blue + yellow, purple = red + blue) Level 5 - Merges the primary and secondary colors -- the idea is that secondary colors are easier to break, but they take a little more thought to determine which colors goes where Level 6 - Introduces white and black blocks -- white blocks (since white is made up of a combination of all three primary colors) can be broken by any color, but black (which is an absence of light) cannot be broken by any color and must be avoided (the challenge here being that the player has to recall which blocks are actually dead, which the ball can pass through without consequence, and which are black, which causes the player to lose a life) Level 7 - Merges the primary colors, secondary colors, and black/white blocks together. After this point, it's mostly the same except the odds of particular blocks appearing just get changed up. Actually, I'm open to advice on this. Currently, every block (besides black) dies from a single hit. The idea there is to keep things relatively fast-paced, but it COULD be tweaked so that secondary colors require each of the two colors that make it up to break them and white takes three, but I'm not sure if that would actually increase the difficulty in any way or just make beating a level a little more tedious). EDIT: if you think that things would look better with the title NOT appearing on the title screen (only the first time, that is, since I want the player to be able to review the score after losing), then, sure, make it so that it doesn't show right away.

So far as I can tell, folder A and B both work just fine! The way you talked, folder A was better if it worked, and indeed, using folder A, I'm left with 1061 bytes of ROM left after compiling (though after a quick test, folder B leaves me with 1061 bytes to spare as well). Which would you recommend? I removed the playfield clear as you said and it seems to work just fine without it. I played 3-4 levels in and didn't notice any problems. The score is working perfectly and I didn't see the ball flicker around at all. Again, thanks so much for all the work! Just let me know which of the two kernel sets you'd recommend and I'd say we're pretty much done. Just need to get a couple playtesters to see if the controls are stiff. Also, if you know someone with a Harmony cartridge, I'd like someone to playtest the game with an actual 2600 controller, since I've always been playing it with the arrow keys + space or the mouse + left click, so it may feel entirely different on a real 2600. Can you recommend anyone? As for that stuff about the dot notation, yes, I was trying to explain that last night, but I think we were both tired and not communicating on the same wavelengths. Still, thanks SO MUCH for all the hard work in making the magic kernel I'd been waiting for! Once everything is playtested, I'd like to have a few cartridges made. Depending on how much the cartridges end up costing to produce (hopefully it's not more than 10 dollars per cartridge), I'll happily send you and anyone else who helped out a physical cartridge with the game on it for keepsake.

Yeah, I agree, GroovyBee, but an array (that is, a data set) is read-only in batariBasic, like so: dataArray 100, 99, 98, 97, 96 end ... So you'd have to rely on something like a[0] = %00000001 It won't be easy, that's for certain. It'd be a lot easier, though, if the playfield wasn't the full 31 x 11 and you only actually did the game on a limited space on it, otherwise you'd need enough bytes to mirror the var set for the playfield, which is made even MORE complicated because every other byte is reversed.

Lives should at least be simple. Use the super-convenient built-in lives variable! If you don't want all that complex stuff that is discussed in that link, you can simply use lives as a free variable. For instance, somewhere at the beginning of your game: lives = 3 and then when you eat a lemon: lives = lives - 1 and somewhere else: if lives = 0 then goto Game_Over EDIT: Also, you may be aware, but if you miss a banana, they don't actually stop falling. It just falls down until it returns to the top of the screen and falls again from the same x location.

Uh... I have no idea what a trapwrite is, heh. It's pretty late for me as well, so I'll just post what I've got and maybe you'll have time to take a peek at it tomorrow, Omega. Like I said, it's got to be something to do with the kernel, because the score isn't being written at all on the first title (which maybe you did intentionally? If so, that's fine) and it's staying red until a new level starts once lives < 1, which directly contradicts the code that has been there the whole time: rem turn the score red if player is on the last life if lives = 1 then scorecolor = 64 else scorecolor = 10 ... But if you absolutely can't get it fixed, I can live with it. The zip contains all the important files: the .asm, .bin, .bas, and the three includes: two .asm and one .inc heartbreak.zip

Works just fine! I simply made a new includes file: ; ; Inclues go below - order is crucial, since this is also the order in which ; they will appear in the generated assembly file ; ; header file 2600basicheader.asm ; standard kernel: two players, two missiles, a ball and an asymmetric playfield. std_kernel.asm ; standard startup routine. startup.asm ; below are collections of subroutines and functions ; if you have any more to add, put them immediately below this line. pf_drawing.asm pf_scrolling.asm std_routines.asm ; The overscan routine goes below. it sets up sprites for the std_kernel. ; if you have any routines that will not run until the overscan period, ; put them immediately below this line. heart_overscan.asm ; below is the generated batari Basic file bB.asm heartkernel.asm ; score graphics. score_graphics.asm ; below is the footer, which contains the score digits and startup vectors. ; If you want to create your own custom score digits, you may hack the file below, ; but first you should rename it to something else. 2600basicfooter.asm ... and referenced it at the top of all my code in the .bas file: includesfile heartincludes.inc ... Note that, like in the video, the score doesn't show up at first and it remains red after death. That must be something to do with the kernel. But, with those additions, things compile and seem to function!

I included the default.inc file a few posts above. Look up on this page. If you tweak the default bB kernel, that's just fine. All I have to do is call the new .asm file in lieu of bB's std_kernel.asm and make a new .inc file to call the kernels. It's really not a problem! Thanks SO MUCH for all the work and hope you get a good sleep! If you're curious, this is the contents of default.inc (which is called by default, but a different .inc file can be specified, which is what I would do): ; ; Inclues go below - order is crucial, since this is also the order in which ; they will appear in the generated assembly file ; ; header file 2600basicheader.asm ; standard kernel: two players, two missiles, a ball and an asymmetric playfield. std_kernel.asm ; standard startup routine. startup.asm ; below are collections of subroutines and functions ; if you have any more to add, put them immediately below this line. pf_drawing.asm pf_scrolling.asm std_routines.asm ; The overscan routine goes below. it sets up sprites for the std_kernel. ; if you have any routines that will not run until the overscan period, ; put them immediately below this line. std_overscan.asm ; below is the generated batari Basic file bB.asm ; score graphics. score_graphics.asm ; below is the footer, which contains the score digits and startup vectors. ; If you want to create your own custom score digits, you may hack the file below, ; but first you should rename it to something else. 2600basicfooter.asm There have been a LOT of changes since the version back in post #60. It's much easier to take the new one and add in the old code than the old one and add in the new code. Besides, Omega got it working, we just have to figure out a way to made it modular. EDIT: I've attached a zip with all the .asm files called by default.inc, as well as default.inc itself, so hopefully that saves you some time. includes.zip

Afraid that's a no go. If I change all drawscreens to gosub DrawKernel then I get a flicker of the titlescreen and that's it. If I only use it for the main drawscreen, title is fine but things don't work once you enter the actual level. Keeping all the drawscreens, but putting gosub DrawKernel in the place where the COLOR FLICKER used to be just gives me a mess of pixels at the top of the screen. I'm basically doing exactly what I did before that didn't work, unless you've got a new .asm file for me to use? You can see an example of the working .bin you sent below. http://youtu.be/lIjihRbETw4 I'm not sure why the score color remains red when in the title screen on death. That hasn't happened before, so it must be tied to the kernel. Maybe it's not getting redrawn after going to the title screen, since the title screen has its own drawscreen call? And if not, it's not the worst bug to have. This may be the case, since, when I am able to see the title screen and the blocks look like a mess, as mentioned above, I don't see the score at all in the title screen, so it's tied to the kernel somehow, perhaps. Another small bug I noticed is that, occasionally, the ball would jump around a bit. It only happened to me one time while recording, though.

It doesn't matter if it's asm include x.asm end or asm stuff here end It should work the same, so we can certainly nestle the assembly code directly, if you prefer. bB requires a function to have a . in front of it in assembly, such as .drawScreen, but when it's called in bB, the . gets dropped, such as with gosub drawScreen If need be, we could call a different includes file that changes the order that the kernels are put together. Attached is a .txt version of default.inc, which can be used as a template. We could call this at the start of the bB file, which would change the way that the kernels are called, if that would help. EDIT: RevEng, in the example here, has: rem ** this is how we call our custom drawscreen... gosub rainbowdrawscreen bank2 goto mainloop bank 2 rem ** include our assembly kernel. rem ** The kernel has an entry point (starting label) of ".rainbowdrawscreen" rem ** Hence our "gosub rainbowdrawscreen bank2" in bank 1. asm include "rainbowkernel.asm" end ... which relates to the rainbowkernel.asm file, which says: ; when bB compiles its code, it adds a dot in front of labels. So to create ; an assembly destination for "gosub rainbowdrawscreen", we add a dot in front .rainbowdrawscreen default.inc.txt

AWESOME! I'm going to keep testing--could you please figure out where the calls need to be so I can actually integrate the Assembly directly into my bB stuff for easier editing? Kudos again! First two levels seem gold, but I'll keep playing.

It's kind of ironic--the greatest help I had from others was to streamline the flicker and the rotation code, but now the rotation code gets returned to the old style and the improved flicker is removed entirely. Anyway, I tested the attached version and it works on the first level, anyway. Also, THANK GOD for my decision to keep a saved archive of .txt files containing the code for every major iteration of the program. heartbreak.bas.bin heartbreak.bas heartbreak.bas.asm

Here you go. This version has the include and the gosub call removed, so it displays the title screen, generates the level, and enters the level, but that you see is the heart beating in the center, since the pfpixels aren't being drawn. heartbreak.bas heartbreak.bas.asm heartbreak.bas.bin

Okay, so I need to use drawscreens AND call the function where appropriate? P.S. Maybe we should take this to chat/PMs instead, since this is getting crazy. EDIT: I've got the files attached. I returned the main drawscreen to where it belongs and added gosub StartPlayScreen just before, where the color drawing code used to be. You actually get something on-screen now, as was the case once before, though it's not exactly a circle. heartbreak.bas.bin heartbreak.bas.asm heartbreak.bas

Sure thing! I would have posted it immediately, but I figured, "bah, there can't possibly be any use for this." Silly me. Want the .lst as well? heartbreak.bas.bin

Alright, I did as you said, using $00 as the dead color and $01 as the black. In this version, I only replaced the main drawscreen with gosub StartPlayScreen but I kept a normal drawscreen to render the title screen and to generate a level (since neither of those involve the circular pfpixels being drawn on-screen). I've attached the .bas and .asm files, so hopefully that helps. Note that currently, it works fine for the title screen (as expected since it uses the normal drawscreen) but gets only a blank screen after trigger (wherein the level is generated and the blocks are drawn). heartbreak.bas heartbreak.bas.asm

Bogax made a modification to the way the flicker works that inserts values directly into the pfpixels. Is that what you're referring to? It was done by what seemed necessity, since without that change, the game was sucking up too many cycles. If we revert back to before that change, when the colors were still scrolled manually, could the kernel make up the difference in cycles? I already posted the flicker code above. Here's how it used to look: rem ============== rem COLOR FLICKER rem ============== 100 rem if the player has zero lives, skip this part if lives = 0 then goto 410 rem set up possible colors data blkc 64, 28, 148 end rem set up possible pfpixel locations data ctbl 16, 20, 24, 27, 28, 27, 24, 20, 16, 12, 8, 5, 4, 5, 8, 12 end data rtbl 0, 0, 1, 3, 5, 7, 9, 10, 10, 10, 9, 7, 5, 3, 1, 0 end rem cycle through pfpixels, turning them on if they are equal to the color being drawn for temp5 = 0 to 15 if a[temp5] = blkc[flicker] then pfpixel ctbl[temp5] rtbl[temp5] on next rem set playfield to current color COLUPF = blkc[flicker] rem increment flicker temp1 = blkc_length + 1 if flicker = temp1 then flicker = 0 else flicker = flicker + 1 ... Though should that really make a difference? Even in the new version, the colors for the pfpixels are still being stored in the RAM in "a" through "p". They hold the color value that the pfpixel should have, or 1 (currently, after that change you requested) if that pfpixel should be turned off. That hasn't changed. That's done like so (note I use the words "index", "data set", and "array" interchangeably since they're basically the same thing in the context of batariBasic): When a stage is generated, the game checks a data set to see which colors are in the current level: rem defines which color checks are in a stage data levelcolors %00000001, %00000011, %00000111, %00111000, %00111111, %11000000, %11000111, %11000111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111 end ... This corresponds to another data set, which indicates which colors are possible (it just so happens there are only 8, so it's coincidentally perfect): rem set up possible colors data blkc $42, $1C, $96, $2E, $D6, $66, $0E, $00 end There is another data set that has all the possible "chances" for the colors (in the format of "if >= x") rem defines the odds of a color for each stage data colorodds 0, 0, 128, 0, 85, 170, 0, 42, 84, 126, 168, 210, 0, 80, 160, 240, 247, 0, 40, 80, 120, 160, 200, 240, 247, 0, 60, 120, 180, 200, 220, 240, 245, 0, 60, 120, 180, 195, 210, 225, 230 end ... And yet ANOTHER data set that indicates, per level, how far into the colorodds data set to reach in order to get the odds for all the current colors rem saves space by indicating where the colorodds index should begin, per level data startindex 0, 1, 3, 3, 6, 1, 12, 12, 17, 17, 25, 25, 33, 33 end So, for instance, at level 0, the game checks to see where it should start at the color odds index. starindex[0] indicates that it should start at colorodds[0]. levelcolors[0] indicates that the first level only has one possible color, the first color, which is defined at blkc[0]. From this, the game determines that, at level 0, if a random number (from 0 to 255) is >= 0 (which will be true 100% of the time), the block being written (which starts at a[0]) should be given the color $42 (which is red in the NTSC palette). This is done with the following code: rem generate a random number temp2 = rand rem determine what the level's index is temp3 = startindex[level] rem if a color is in a level and its number has been rolled, set a pfpixel to its color, then increment the counter (temp 3) if temp4{0} && temp2 >= colorodds[temp3] then a[temp1] = blkc[0]: temp3 = temp3 + 1 if temp4{1} && temp2 >= colorodds[temp3] then a[temp1] = blkc[1]: temp3 = temp3 + 1 if temp4{2} && temp2 >= colorodds[temp3] then a[temp1] = blkc[2]: temp3 = temp3 + 1 if temp4{3} && temp2 >= colorodds[temp3] then a[temp1] = blkc[3]: temp3 = temp3 + 1 if temp4{4} && temp2 >= colorodds[temp3] then a[temp1] = blkc[4]: temp3 = temp3 + 1 if temp4{5} && temp2 >= colorodds[temp3] then a[temp1] = blkc[5]: temp3 = temp3 + 1 if temp4{6} && temp2 >= colorodds[temp3] then a[temp1] = blkc[6]: temp3 = temp3 + 1 if temp4{7} && temp2 >= colorodds[temp3] then a[temp1] = blkc[7]: blkcount = blkcount - 1 drawscreen This is done once per loop. The drawscreen and the choice to use a full loop through my main draw_loop loop is simply to space out the work so that the 2600 doesn't run over cycles for a particular frame. This happens 16 times and then lives are set to 9, which begins the level (though there's also a variable called pulse which keeps the game stuck in the block-generation loop until it's complete). Hopefully that helps explain things and doesn't come off as condescending. Does that help at all? As I said, the values SHOULD still be in the memory, in a[0] - a[15], which is also "a" through "p" since, in batariBasic, a[0] = a, a[1] = b, a[2] = c, etc.

Could you use missile 0, missile 1, and the ball to create more sprites that could be used without needing the multisprite kernel?

Seems it's not working. I tried starting from the basic .bas file I posted earlier, then added the include for heartkernel.asm, which worked fine when I tried compiling. Then, precisely as you wrote, I changed drawscreen to gosub .DrawKernel and got assembly errors. I think one of the problems is that bB doesn't need that . I tried replacing just the drawscreen that comes after the flicker stuff (by the way, what should I do with that flicker code? Should it be entirely removed?) with gosub DrawKernel, but that gives me a black screen after leaving the title screen. If I replace both drawscreen calls (there's a drawscreen that's only called for the title screen, since everything else is bypassed when lives = 0) with gosub DrawKernel, I get a brief flicker of the title screen when the game begins, then nothing. Attached are both occurrences and another one that just has the include but no drawscreen changes. This is the flicker code. Should it be there or removed? In both the above examples, it was still there. rem ============== rem COLOR FLICKER rem ============== 100 rem first, set levelcolor[level] into another variable for bitwise operations temp4 = levelcolors[level] 105 rem increment flicker flicker = flicker + 1 & 7 rem determines if a color is being used if setbits[flicker] & temp4 then goto 110 goto 105 data screen_add 2, 2, 7, 15, 23, 31, 39, 42, 42, 41, 37, 28, 20, 12, 5, 1 end data block_bit 128, 8, 1, 8, 16, 8, 1, 8, 128, 16, 1, 4, 8, 4, 1, 16 end data setbits 1, 2, 4, 8, 10, 32, 64, 128 end 110 rem cycle through pfpixels, turning them on if they are equal to the color being drawn temp6 = base for temp5 = 0 to 15 if a[temp6] = blkc[flicker] then temp2 = screen_add[temp5] : $A4[temp2] = $A4[temp2] | block_bit[temp5] temp6 = temp6 + 1 & 15 next rem set playfield to current color COLUPF = blkc[flicker] rem ================== rem MAIN DRAWSCREEN rem ================== rem ... etc. heartbreak_bothdrawsreplaced.bas.asm heartbreak_maindrawreplaced.bas.asm heartbreak_justinclude.bas.asm

Not sure if this is relevant to your original question, but the second and fourth bytes are apparently reversed as this says. I understand your desire for a title screen, but good gameplay trumps a title screen. It's not that the idea is bad, it's just that it isn't fully realized. Obviously the mouth catching the bananas isn't enough because there's no challege to it. Maybe if different kinds of food (multiple at a type, so multisprite may be necessary), some of which are undesirable, so the player has to deal with multiple foods falling down at different locations, thinking quickly to eat the right ones and avoid the wrong ones, etc. So, no, it's not a lousy idea, it just needs to be expanded upon. There's nothing wrong with a simple game. It's all about whether or not the gameplay can be expanded to have increasing challenge, and that's what makes things fun or not, at least in my opinion. In response to RT, I think that you can start making a game for any reason, challenge or "for the players" or not. Whether it will work or not is consciousness of scope, gameplay, and overall elegance in design (that is, all the parts, the visuals, mechanics, etc. work together to create a cohesive, complimentary experience). If someone like myself or Atari2600Land want to do things in limited space for the challenge, there's nothing wrong at that, so long as that size is sufficient to create a quality product. Bigger isn't necessarily better.

I think the pattern is that everyone has spammed this poor guy's thread with zero feedback. I'll be back with some feedback after I give it a try.

Yeah, sorry. I didn't know what that was for. Had to make it a .txt because .lst files can't be uploaded, apparently. EDIT: Also, apparently I'm not supposed to distribute it? But, uh, don't turn me in to the coppers, k? heartbreak.bas.lst.txt

Sure thing! Sorry I didn't think to post it already. Attached is the assembly file from the latest version (and I included the .bas and .bin in case anyone else wants a peek). This is without the added stuff that calls your code, so you can figure out how it works without that. Hopefully that's kinda what you were looking for! I call the assembly with the following code at the end of the file: rem end loop 800 goto draw_loop asm include "heartkernel.asm" end As long as the player as no lives, they get booted to the title screen. If they have no lives and fire the trigger, the game spends a few cycles generating the level, then sets the lives count up to 9 which enables play again. rem if the player has zero lives, skip this part if lives = 0 then goto 410 rem exits title screen and generates a new stage if joy0fire && lives = 0 then score = 0: level = startlevel: goto 774 No rush! I can't say I fully understand the way the jumping works between the assembly code and the bB, but hopefully we'll get it worked out without me bugging you to death. heartbreak.bas heartbreak.bas.asm heartbreak.bas.bin