jrok

You have to really experiment with color blending to get a decent effect going. It's always going to look a little "ghostly" though. And, of course, if you are flickering an object more than once (i.e. alternating between three or more screen positions), you may also get "blinking" in addition to the color loss. I'm sure most people recall games where this was the case. "Superman" was one, if I remember correctly.

You have to really experiment with color blending to get a decent effect going. It's always going to look a little "ghostly" though.

Flicker isn't really complex. It just means displaying a sprite (or other object) at two or more positions. Probably the simplest flicker can be achieved by flipping a bit and and writing a conditional statement for the sprite's x and/or y values. for instance. player0: %11111111 %11111111 %11111111 %11111111 end Loop COLUP0 = 14 if !a{0} then a{0}=1 : goto SpritePosB player0x=40 : player0y=20 : a{0}=0 : goto DrawFrame SpritePosB player0x=100 : player0y=70 DrawFrame drawscreen goto Loop So basically in the above, you are saying "When the first bit of 'a' is set to off, show the sprite here. If it's set to on, then show the sprite over here." When people talk about flicker when describing a display, they usually talk about the clarity/brightness of the sprite. When objects are flickered, they will lose some of their natural brightness, since they aren't being displayed in the same position every time the screen is drawn. Hope that helps a little. Jarod.

My guess is most people aren't really talking about morality or family-friendliness here, but just taste. I mean, humor is tough. What sounds funny to one guy might just make another guy roll his eyes. It's also just such a good, polished game that it the concept feels jarring rather than whimsical or Atari-weird. "Severed penises" seems like something meant to jazz up an inferior game, and this is an excellent one. But, it's your baby. If unsevered penises (penii?) is what you want, not a man among us can stop you.

Or rather, the "unmissing member?" I confess I've totally forgotten the plot behind this one, severed or otherwise. Great game, though.

Probably the best way to achieve this is by using flicker to display a player sprite at x during even frames and at x + 8 during odd frames. It's probably not worth using up both player objects to draw a single item in batari's standard kernel. If you want the sprite to move, this will require you to reserve an additional variable for the "big sprite's" x value (i.e "dim myspriteX") , rather than using the predefined player0x/player1x variables. Set the position of the sprite to myspriteX and myspriteX + 8 on alternating frames. You would then manipulate myspriteX in your code to move the 16-wide sprite. I'm actually writing a game in the multisprite kernel that uses a 16-wide sprite, but I still flicker player0 rather than use other combinations (player0+virtual sprite or virtual sprite+virtual sprite) to prevent one half of the character from flickering or disappearing when the spritelines overlap other player1 virtual sprites.

No problem. You can also include the "on" statements outside of subroutines. Such as: PlayerSprite (position updates, AI, player color, etc.) goto PlayerSpriteAnimation return PlayerSpriteAnimation on animFrame goto P0_Frame1 P0_Frame2 P0_Frame3 P0_Frame4 P0_Frame5 P0_Frame6 P0_Frame7 P0_Frame8 return P0_Frame1 player0: %11100111 %11100111 %11100111 %11100000 %11100000 %11100000 %11111111 %11111111 end return (...) I use this technique a lot in bank-switched games with lots of different animations, keeping my animations all in one place. For instance, if your animated sprite has multiple states (running, jumping, shooting, dying, etc), you can just jump to the appropriate "on" statement Label when the criteria is met in your subroutine. In any case, the useful of "on" is that you can maintain a constant animation schedule for all the elements in your game without having to keep track of a lot of different stuff. Cheers, Jarod.

I've always found it helpful to just reserve one variable for a universal "animation frame" and a one variable for a "framerate." Main_Loop framerate = framerate + 1 if framerate = 4 then animFrame = animFrame + 1 : framerate = 0 if animFrame = 8 then animFrame = 0 gosub PlayerSprite drawscreen goto Main_Loop So in the above, you have an 8-frame animation schedule that updates every fourth loop. To make game animation slower or faster, just alter "4" to the desired speed (higher numbers slow animation down, lower numbers speed it up) That way, rather than having to do something like "if P0_Anim_Count = 10 then player0:" you can simply do a "on" statement for every sprite you want to animate, i.e.: PlayerSprite (position updates, AI, player color, etc.) on animFrame goto P0_Frame1 P0_Frame2 P0_Frame3 P0_Frame4 P0_Frame5 P0_Frame6 P0_Frame7 P0_Frame8 return P0_Frame1 player0: %11100111 %11100111 %11100111 %11100000 %11100000 %11100000 %11111111 %11111111 end return (...) I normally contain each "on" statement at the end of whatever general subroutine I've come up with for each sprite/entity. So if it's, for instance, an enemy hunting you down, I begin the subroutine by updating it's position, then include the A.I. nodes, then end the subroutine with the "on" statements and their pointers to the sprite definitions. The important thing to remember about using this technique is to include a return after each sprite definition. After the routine reads the definition, it should return to the subroutine, which then returns to the main loop. You can do this for as many sprites (or other objects) as you want, including flickered sprites. Cheers, Jarod.

One thought about the whole "up for jump" controversy. I sometimes think it might be better for "up+button" to jump. Or, rather "up+button", "up+left+button" and "up+right+button" are all mapped to jump, and every other direction plus a button would shoot. This might help alleviate the frustration with timing that comes with "up to jump." The player could move in either direction using either right/left and up+right/up+left, but the button would cause the player to jump when the joystick is registering an up-combination, and cause it to shoot otherwise. Another idea I've been toying with is the "Flashback: Quest for Identity" model, where the player can change between jumping and shooting on the fly by tapping up to draw his gun (or, if he has it out, to holster it.) I think that would work for some kinds of games.

One tip is to really explore this forum exhaustively. It's a gold mine for tips and techniques. Random Terrain's webpage is a great reference doc for language, too. The greatest limitation of bB's kernel is that you need to draw the entire screen at once, meaning that all of your objects (2 player sprites, 2 missiles, the playfield and the ball) can only be displayed once per frame. For that reason I'd recommend that you look into flickering ASAP, since that at least doubles the number of objects you'll have at your disposal. Cheers, J

Hmmm. I don't see the dots. Any more information? It's a single dot that appears on the center of the top edge of the screen then moves diagonally down and right into the box in which the boss gladiator is running. It then goes from the lower-right corner of that box toward the lower-right corner of the screen. Next, it reappears at the lower-right corner of the box and again goes to the lower-right corner of the screen. The cycle then repeats. The dot's position along this path isn't consistent but the direction it takes is. I have attached a screen shot showing the dot. I am using Stella 3.0 on Windows 7 64-bit. Hmmm. That's the ball object. I must have accidentally used its ram pointers for something. Thanks for the report... I wonder why I never noticed this? Does this dot appear anywhere else during play?

Thanks! I can beat him, but the game is unforgiving. I might add a few "lives," Hmmm. I don't see the dots. Any more information? Thanks for the bug report. I'll fix this in the next build. Thanks again. I'll fix this. I noticed this too. I will work on it. Thanks for your help.

It's hard to say without knowing how you are testing to find out if a block is black or not. But if the test is met to make a block black, could you just add "1" to a variable until it reaches "25", and then proceed? if blacktotal = 25 then goto levelcomplete else goto continuelevel

It's just you. But I find myself whistling "Only Solutions". For me it's "Dream Police." I am seeking medication for this.

Thanks! A two player mode was always been part of the original plan. But it's a matter of ROM space at this point. Unless I can figure out a clever way of implementing it, I may have to choose between 2-player mode and single player Bonus stages. Due to kernel constraints a smaller, thinner laser is impossible, unfortunately. On the other hand, I can make the actual hit boundaries of the lasers "smaller and thinner." In other words they would look the same, but the area that registers a successful "hit" could be smaller. I doubt that's what you mean, though.

I know haven't posted progress on this one in awhile, so I thought I'd post a BIN. The summary of changes might be incomplete, but here's a rough overview. 1. Added music to (placeholder) Title Screen, Circuit Intro and Upgrade Shop. 2. Added a Circuit Select feature. Press the select switch to select one of three possible circuits (A, B or C, with C being the hardest). The screen will show the letter of the circuit and a picture of that circuit's champion. 3. Players can use their credits to upgrade three traits before the start of each circuit: Health, Range and Movement. Tap back and forth on the joystick to access the different traits, press the fire button to buy one or more upgrades. You begin the game with 4 credits, but will earn additional ones after defeating each circuit's champ (if you are using Circuit Select to try Circuits B or C, the initial number of credits will account for champs that you would have defeated if you played from the beginning.) When finished, tap the joystick until you see the "GO" screen, then press fire to start the first match. Health increases number of hits before death. Range increases the range of the laser beam. Movement increases both foot speed and the range of your dash. 4. Some more powerful enemies will use a flashing deflector shield that can absorb a laser shot without causing damage to the gladiator. Once the shield is down, a second shot will wound him, but you have to get the shot off quickly, since the shield will regenerate over time (some enemies regerate the shield faster than others.) 5. Fixed various bugs and kinks, such as the wrapping laser shots in the left and right safety zones. Here's a current binary. I plan on putting some more work into this over the next couple of weeks, so any feedback you guys have would be much appreciated. There are still lots of things left to implement, such as the Bonus mini games (right now, it's just a screen that says "Bonus" ) and several additional enemy types to finish programming, but I'm hoping to get the main engine to a place where it's fun and bug free, first. Cheers, J CircusGalacticus8.bin

O.K. Random (or whoever) I have one for you, I will make this one fairly easy. Clue one - Charleton Heston Clue two - Kung-Fu Artillery Duel (Charlton Heston liked things that went boom)/Chuck Norris Superkicks (He likes to go punchy/kicky) Next clue David Carridine Oh, both were in the movie Gray Lady Down, so the game has something to do with a submarine. Could be one of these: Submarine Commander Bermuda Triangle Airlock Seaquest Fantastic Voyage James Bond 007 Last clue I am Legend (by the way it is an Atari 2600 game) I've got it. "Gray Lady" is a common nickname of the "New York Times." 20th century newspapers, as we all know, are printed on wood pulp paper, which contains large quantities of acid (and therefore must be de-acidified in order to preserve them). "Gray Lady Down", which starred Charlton Heston and David Carradine, is clearly a code for "Acid Drop," which was programmed by Dennis M. Kiss (a clever reference to the 1982 K.I.S.S rock anthem "I'm A Legend Tonight") What do I win?

Beat-L Flaying Mantis

The bottom one seems more intuitive to me, especially for when the action is furious. The one with the indicator arrow is a bit of an unnecessary distraction. It just seems like one more connection my brain needs to make (the position of the arrow) during gameplay, when it should be thoroughly focused on blowing up subs. Great work so far!

It's really interesting that you picked up on that. I temporarily sacrificed the bounce to preserve some ROM after moving the color pointers into Superchip RAM. Basically, the old animation was using shape data to draw the sprite's "bouncing step," and I was updating the necessary color changes based on the frames of animation where the changes occurred. The good news is that now that I've finished reorganized the memory, I can add the bounce back in by moving the actual sprite object instead of the shape and colors. I will remember to do this in the next build. I set phosphor to "77" in z26, and the flicker doesn't seem to be terribly noticeable. Cheers, Jarod.

I'm ]curious about all the numbers in the bottom score area. What do they signify? As far as the 2600, are all the sprites free roaming? EDIT: P.S, it actually looks like kind of a cool game. Is it mamed?

I think you practically answered your own question. With a question of that nature-- "Can I move 'Variable X' from zero-page RAM to Superchip RAM?", or "Can I move the 'Such-and-Such Table' from ROM to RAM?"-- I see the biggest factor as being what kind of addressing mode is being used by the kernel when reading the data from 'Variable X' or the 'Such-and-Such Table.' Data tables that are normally compiled to ROM and read from there can (most likely) always be moved to RAM-- either to zero-page RAM or Superchip RAM-- since you could always write a zero-page address as an absolute two-byte lo/hi address, or (if it uses zero page pointers) set the zero-page lo/hi pointers to the zero-page address where you've stored the table. That's what you're doing above-- setting the pointers so they point to the zero-page starting address of the table. So you could easily move that table to Superchip RAM, as long as you use the write addresses to store data in the table, and then set the pointers to the read addresses so the kernel will read the data from the correct area. The other situation-- moving a variable that's normally in zero-page RAM into the Superchip RAM-- is a different matter, because if the kernel expects it to be in page zero, moving it to a two-byte address might mess up the kernel's timing. Michael Ah, I see. I feel a little dumb for asking now, actually. So basically it would be: dim p1color = w000 dim p1color_row1 = w000 dim p1color_row2 = w001 dim p1color_row3 = w002 dim p1color_row4 = w003 dim p1color_row5 = w004 dim p1color_row6 = w005 dim p1color_row7 = w006 dim p1color_row8 = w007 dim p1color_row9 = w008 dim p1color_row10 = w009 dim p1color_row11 = w010 dim p1color_row12 = w011 dim p1color_row13 = w012 dim p1color_row14 = w013 dim p1color_row15 = w014 dim p1color_row16 = w015 dim p1colorR = r000 dim p1colorR_row1 = r000 dim p1colorR_row2 = r001 dim p1colorR_row3 = r002 dim p1colorR_row4 = r003 dim p1colorR_row5 = r004 dim p1colorR_row6 = r005 dim p1colorR_row7 = r006 dim p1colorR_row8 = r007 dim p1colorR_row9 = r008 dim p1colorR_row10 = r009 dim p1colorR_row11 = r010 dim p1colorR_row12 = r011 dim p1colorR_row13 = r012 dim p1colorR_row14 = r013 dim p1colorR_row15 = r014 dim p1colorR_row16 = r015 asm LDA #<p1colorR STA player1color LDA #>p1colorR STA player1color+1 end Thanks again! Jarod.

Just for the sake a realism, maybe we should stick with this: Sort garbage, catch money and dodge corpses. When you say it out loud, it actually sounds very, very awesome.

From a few experiments I ran, it seems as though the playfield is stored last in the Superchip RAM, meaning the "first" 32 bytes are free for use. One question I have, if you have the time. In one project I'm working on, I'm using the zero page RAM to store the color table for player 1: dim p1color = a dim p1color_row1 = a dim p1color_row2 = b dim p1color_row3 = c dim p1color_row4 = d dim p1color_row5 = e dim p1color_row6 = f dim p1color_row7 = g dim p1color_row8 = h dim p1color_row9 = i dim p1color_row10 = j dim p1color_row11 = k dim p1color_row12 = l dim p1color_row13 = m dim p1color_row14 = n dim p1color_row15 = o dim p1color_row16 = p asm LDA #<p1color STA player1color LDA #>p1color STA player1color+1 end I'd prefer to keep this RAM available for other things, namely fixed point math. Do you think it would it be possible to store these colors in Superchip RAM (with the usual limitations of read and write access)? Thanks again, Jarod.

I think I am a little confused about the way superchip memory is managed, particularly when it comes to the naming convention used and RAM playfield data storage. For a long while now, I've been working under the assumption that var0-var47 were the named variables representing all the memory available after the 32x24 playfield was stored in SARA RAM. They are, but you're thinking "backwards" here. The variables named var0 through var47 aren't located in the Superchip RAM area; they're located in the RIOT ("page zero") RAM area. In a non-Superchip bB game that uses the standard kernel, those 48 bytes of RIOT RAM are used to store the playfield-- 12 rows of playfield pixels, at 4 bytes per row. But in a Superchip bB game, the playfield is moved into the Superchip RAM area, which makes those 48 bytes of RIOT RAM freely available, since they no longer need to be used to store the playfield. Which are the read and write addresses that this extra 32 bytes of memory correspond to? I noticed that the values defined in the superchip header seem to all be accessible, but I'm not sure how they correspond to the named variables 0-47, or to the RAM playfield. When I experimented with some of the named variables (w000-127, r000-127) I've yet to find a conflicts with the named vars 0-47. Is there a superchip memory map that illustrates the differences between var0-47, w/r000-127, and the RAM superchip playfield? Sorry if this is a dumb question, but I just can't seem to figure it out, and am afraid I'm not even thinking about it in the correct way. Thanks in advance, Jarod. I might have it upside-down, but I think the playfield is stored "first" in the Superchip RAM area, so any bytes of Superchip RAM not used by the playfield would come after the playfield. Thus, if you're using a playfield with 24 rows, that would be 24 * 4 = 96 bytes, leaving the remaining 32 bytes free for other things. They could be referenced by r096 through r127 for reading, and w096 through w127 for writing. (Or else it's the other way around, with the playfield coming last, and any extra bytes coming first, so the extra 32 bytes would be r000 through r031 and w000 through w031.) So you'd have the normal 26 variables named a through z, plus 48 more variables named var0 through var47, all in the "page zero" RIOT RAM area, as well as 32 additional variables in the Superchip RAM area. Michael Ahhh... It all makes perfect sense, now. Thanks Michael!