jjsonique

Played great on my Harmony cart. I agree with the others who suggest tweaking the name, as I too assumed it was an arcade port of some kind. Excited to see where you take it!

Ridiculous because....littleman jack *should* like the original better? That seems a tad...ridiculous. We're talking about personal reactions to games here. I don't prefer the 2600 version of Moon Patrol to the original, but why should he feel the same? There are many objective ways of measuring how the arcade originals are more technically advanced, more graphically detailed, richer and more varied in content, and more important historically than their 2600 ports. But this thread is about personal reactions... "Do you like any 2600 ports better than the arcade original?" You can't call someone's personal preference invalid, unless you're claiming they're deluding themselves about what they consider more fun. (Hm, perhaps there could be treatment for that rare form of delusion: "It took me years of therapy to admit I actually had more fun playing the stand-up arcade version of Moon Patrol. I was too attached to my Atari - blinded by Stella love!" )

In terms of enjoyment: Space Invaders - even as a kid in the late 70's, early 80's I never liked the arcade version that much - it's essential video game history, but as for the fun to be had from it, other arcade games were eclipsing it pretty quickly. The 2600 version, then and now, is just more fun for me. Part of it is the lower-fi stomp-stomp-stomp sound and rigid march of the 2600 invaders making the ratcheting up of the tension work better. Defender and Defender II - as others mentioned, the multiple buttons on the stand-up arcade versions made playing those an insane typing fest - the simplified controls on the Atari make them much more enjoyable Missile Command - despite a lack of a trackball (outside of the hack I don't have the controller for), the Atari 2600 version retains the fluidity of the arcade version's gameplay and manages to escalate the tension at its own but still challenging pace. I rarely chose to play the original in arcades but always play the 2600 version when my attention turns back to the 2600. Bezerk - the arcade version is definitely cooler, but the 2600 port has an addictiveness I never felt strongly with the arcade version (and with the nifty voice hack you get 'Chicken, fight like a robot!' etc. back ) Like Tinman said for Space Invaders, in these cases it's actually the differences of the Atari 2600 ports that make me enjoy them more as games. Judged strictly as ports, of course they're lacking, but judged but how much fun I have with them, they totally win.

Yeah, in the next version of bB thread he said it's incomplete, but you can try it: "The ability to assign multiple players to a single set of sprite data is another feature I neglected to mention. It is incomplete at the moment but so far, to assign the same data to players 1-4, use player1-4: for the declaration. It apparently only assigns player#height for the first player. Also, it does not yet work for assigning the same colors to multiple players (I will use player1-4color: for that). Since this is a feature you guys probably want, I'll look into getting it going properly."

Received my Harmony cart earlier this week - works great! Thanks so much for realizing this excellent hardware feat!

This is great! This could make me return to the super-simple rpg I was attempting in bB, since inventory/messages was the holdup when I tried before.

Thanks for the highlighting my blog, Fort Apocalypse! It's been fun getting back into Apple II-land. I'm going to try to keep a pace of at least one posting a week, though real life will likely intervene.

Aha! With that hint I think I found the updated version of the kernel here. Works fine now, much thanks! JJ

A happy holidays bug report. It seems like the 1.0 multisprite kernel has a glitch that the pre-1.0 bleeding-edge versions didn't: if player0 is positioned at close to the same y coordinate of any of the other sprites (it seems to be + 2 pixels of the other sprite's y), that other sprite 'jumps' 3 pixels to the right until player0 moves out of that particular y position. Here's a test binary - as you move player0 by the other sprites quickly, you'll see the little jump in each as you pass by, if you precisely line player0 up with one of the other sprites, you'll see the displacement clearly. The code is below and I've also attached two screenshots. I'm assuming this is distinct from known issues with the flicker routine? set kernel multisprite x=55 : y=84 loop COLUP0=46 _COLUP1=30 COLUP2=72 COLUP3=212 COLUP4=252 COLUP5=190 player0: %01101100 %00101000 %00111000 %00010000 %01111100 %00010000 %00011100 %00011100 end player1: %00110110 %00010100 %10010100 %10010101 %01011101 %10111110 %10011100 %10011000 end player2: %00000000 %00000011 %00000101 %00001010 %01010100 %00101000 %01110000 %01101000 end player3: %00111100 %01000010 %01000010 %01000010 %00100100 %10011000 %00111100 %01000001 end player4: %01011011 %01001010 %01001010 %00111100 %01001110 %01011101 %01011001 %01000001 end player5: %11111111 %01000001 %00100010 %00010010 %00001100 %00100000 %00000010 %00000000 end rem placement player0x=x : player0y=y player1x=30 : player1y=80 player2x=30: player2y=65 player3x=30: player3y=50 player4x=30: player4y=35 player5x=30: player5y=20 rem draw the screen drawscreen rem player0 control if joy0left then x = x - 1: REFP0 = 8 if joy0right then x = x + 1: REFP0 = 0 if x < 5 then x = 5 if x > 147 then x = 147 if joy0up then y = y + 1 if joy0down then y = y - 1 if y > 85 then y = 85 if y < 20 then y = 20 goto loop multisprite_bug_test.bas.bin

Just another vote of "this is great! please continue!" I do agree with the statement above that the cycle race sequence would be better with pauses both before and after it.

Ah, thanks batari and jbs30000. Good to know.

I've been looking into the goodness of 1.0, and I'm wondering -- If you use Superchip RAM and pfres to have a double-height playfield (say 24 or 32 lines)... a) does the " playfield:" command still work normally for the extra rows ? b) can you use the pfcolors and pfheights kernel options and adjust the color and height of the extra lines? (I'll test this out myself tomorrow night, but thought I'd ask in case the answers are already known. ) Thanks, JJ

MausBoy, that sounds great. I'm going to be tackling an RPG/Adventure-style game using bB as well. I'm not going to take on Ultima-like tiles and scrolling (as much as I love Ultima and lusted after the Homestar RPG), however -- movement in the world will be pretty quick and abstracted. I do hope to have a menu for a limited inventory, and the ability to buy/sell things, and a very simple turn-based combat engine (somewhat like Dragon Warrior's, but even simpler -- no statistics besides HP and current armor, and no magic (just item use instead) ). It will have two members in the party, however, who can each use different weapons, items each round of combat for some tactical options. I've laid out on paper how the screens could work within the limits of the current multisprite kernel, and now that I got that kernel working for me, I'll be making some test screens. In short, I'll try to make something that would be pretty complex for a 2600 game, but very simple in terms of RPGs. I agree that anything approaching RPG-ness would need bankswitching to work, so I hope Batari's planned merge of multisprite with bankswitching will not prove too difficult.

This looks awesome and is a harbinger of bB Things to Come. Keep up the good work!

(Removed previous question about only being able to get player0 to show with 99b multisprite) Got it to work! I was dumbly positioning some of the sprites off the screen, and this seems to cause all the extra sprites to disappear. Keeping all the y values within screen bounds made it work fine.