Blinky Goes Up (formerly GIANA BROS)

[Blinky Goes Up (formerly GIANA BROS)]

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!

[Do you like any 2600 ports better than the arcade original?]

Moon Patrol... this thread has become a ridiculous joke...

 

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!" )

[Do you like any 2600 ports better than the arcade original?]

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.

[Player 2-9 Collision?]

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."

[Harmony cart "THANK YOU!" thread]

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

[Using the score for a game title or inventory strip]

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.

["Apple II Adventures" blog]

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.

[1.0 multisprite bug?]

I think batari may have posted a corrected version of the multisprite kernel in the forums. I'll search later and see if I can find it. I may also have it on a USB stick drive that I brought with me to my sister's house.

 

Michael

Aha! With that hint I think I found the updated version of the kernel here.

 

Works fine now, much thanks!

 

JJ

[1.0 multisprite bug?]

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

[Tron Arcade - Beta version.]

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.

[Superchip double-height playfield and kernel options]

Ah, thanks batari and jbs30000. Good to know.

[Superchip double-height playfield and kernel options]

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

[RPG IN 1-2-3 WITH bB]

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.

[Jumper - Final Version Complete]

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

[bB bleeding-edge builds]

(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.

[Bug Report Thread]

I may have messed something up, but it appears the numbering of the y-axis is reversed when you move from 99b standard to 99b w/multisprite kernel. Ie, assuming you're using y for player0's y postition, in 99b standard, y = y + 1 moves player0 down 1 pixel, but in 99b multisprite y = y + 1 moves player0 UP 1 pixel. Although, my changes to player0's y position were tied to joystick movement, so maybe the joy0up/down reads are somehow reversed? I didn't test by just changing player0's initial position, which I should have (and will do tonight).

 

UPDATE: Tested again, and it IS the y numbering of that's reversed. A player0 with y directly set to 20 will appear at the top of the screen in 99b standard, and near the bottom in 99b multisprite.

 

Also, I was having trouble getting the extra sprites to show, but I now think that was due to not having them all defined at once (as Atarius Maximus notes above). I will try that out tonight and see if that solves that problem.

 

UPDATE pt 2: Got it to work! At first I was still having problems after defining all the sprites, but I discovered if any sprite is positioned offscreen, it can cause all all the extra sprites to disappear. Keeping them w/n screen bounds, it works fine.

[bB bleeding-edge builds]

Great! I've started playing around with it already.

[Need opinions on multisprite kernel]

Demo looks good! I like putting the playfield in ROM as the better solution for now, and can't wait for the official release! In other words: .

[Kernel request thread]

Ah, I can see how it's been a quandry!

 

But now that you bring up the kernel again, it may be a good idea to go ahead and ignore the issue entirely, letting the compiler be a little wasteful on space and optimize it at some later release.  But at the same time, if I allow an option to build 8k bankswitched binaries, it will mitigate the waste issues somewhat.  I have figured out how to do the bankswitching, so there's no dilemma here.

 

I concur, that does sound like a good idea, especially with a bankswitching option to compensate for some of the wastefulness. Plus, once it's "out there", members of the community may have additional clever ideas about how to help with optimization.

 

Well, I also want to finish the Space Invaders clone too

952490[/snapback]

 

Whoo hoo! And thanks for the update.

[Kernel request thread]

batari and vdub, how goes integration of the multi-sprite kernel into bB? Or that process in a state where there's no guessing how long it may or may not take? (Not trying to be a pest, just very interested to see it )

[Reventure -- a batari BASIC adventure]

There's only one drawscreen per loop, so I don't think it's the number of them, but I *do* use the pfvline, pfhline, and pfpixel to draw the room in every loop, so that must be the culprit-- coupled with all of the other logic, of course. I'll try splitting some of the tasks across alternate frames.

 

Yes, in my project, I found that doing a lot of playfield drawing every loop can induce flicker. To get this playfield --

-- flicker-free I had to split the drawing across two seperate frames.

 

Despite the flicker, your game's basic room layout/movement works well and seems a good basis for an adventure game. Good luck with this.

[Should I release Alpha 0.3 now?]

Er, apparently I'm the only one DYING for the multi-sprite kernel (my project requires a bunch of tricky (for me) switching between different drawscreens otherwise), but if the majority wants .3 now, so be it. It will be good for bug finding/squashing to commence.

[Are you happy that we have batari Basic?]

Yes, I'm definitely very happy that Batari BASIC has come out. I've already plotted out the gameplay for a very (I mean VERY) simple RPGish game (main map screenshot below), but I'm waiting on the multi-sprite kernel and the next version of bB to come out before I dive in for good, but even the little I've done has been quite fun to create.

 

[Kernel request thread]

How about interest in a maze kernel?  Think Dark Cavern, Pac-Man, Ms. Pac-Man, Alien, Berzerk; symmetrical, in other words.

 

Or asymmetrical, like in Venture?

900999[/snapback]

 

I'd be pretty interested in an asymmetrical maze kernel (though a symmetrical would also be fine, since I imagine it saves a considerable amount of memory and/or cycles).

 

And I'm salivating with anticipation for your multi-sprite kernel, of course.

[Kernel request thread]

Therefore, the solution I've come up with is a "includes file."  The default includes file will contain everything you are used to.  If you want to include more or take things out, either modify the default includes file (not recommended but will work) use a different includes file.  There would be a bB command to specify a different includes file.

 

Actually, there should be a few different include files packaged with bB for common combinations of kernels/modules.  But you are welcome to make your own includes file and it will be fairly easy to do.

 

It's not really any harder this way, and it's much more powerful since you would have direct control over what modules or kernel (or kernels) get compiled in.

 

Is this a bad idea?  Let me know before it all gets coded in...

 

I think includes would be a great idea, and would be very useful for allowing programmers to "pick and choose" which kernel elements they want for their own game. Please go forward with it.