Sohl

@LatchKeyKid, @splendidnut, great discussion! In my Immunity game I'm working on, in some cases I just use two player graphics on top of each other to render a virus sprite, but in other cases I use flicker or changing color per line for one sprite. I even used the playfield bitmap and color to fill in part of my viruses in a non-play portion of one screen to save a player graphic, probably similar to what @Gemintronic mentioned. In this crop, the white virus bodies are playfield and square, but the overlaid spike proteins sort of hide that and make them seem more rounded, but I can more easily do this here because in this screen, the upper three viruses don't move: In general, using the ball is the most flexible, but you either need to design your playfield and sprites to work together properly, or need to actively control the playfield color in tight timing constraints. Using missiles for extra color is not very flexible, but if your sprites have inverted colors relative each other, it could work. (e.g. Spy-versus-Spy games based on the Mad Magazine cartoon). You'd use Missile 1 with Player 0, and Missile 0 with Player 1. One of my future game ideas will probably use layered player graphic spites with a solid-color silhouette and a color-per-line upper layer, but I will flicker the upper layer between a player and an enemy or other special object as needed. I'm using asm, not bB, so I can try to be more optimized for my particular approach. I do want to set up my data better for efficient use in future drawing kernels so the kernels can be more streamlined and efficient. The kernels in Immunity have been a bit maddening at times to get working correctly and I had to do a lot of rework to make the RAM use somewhat more efficient.

Alex, I do use auto-complete a large extent, but not always. I suppose I can train myself to use it closer to 100%.

I love using Stella as a development tool. Its debugging features are awesome. I've donated money in the past year or so and suggest everyone who has not done that yet to do so too! I've not upgraded to 6.7 yet, but I look forward to trying it. In version 6.6 I do have a minor debugging UI issue... if you start typing in the prompt window, then paste some additional text into the prompt window, that text clobbers what was already entered. I find I do this when I want to setup a break point... I type "break" in the prompt window, then highlight and copy the name of a entry point or symbol from my text editor, then try to paste it into the prompt line to complete the breakpoint definition, but I lose the word break, which I need to re-enter. Just an annoyance when I don't remember it will happen. I might be able to look at the Stella source see if I can spot the cause and maybe even suggest a patch/pull-request.

Back again... I've been toiling away for many weeks at a major refactoring of the "exo" play mode to allow the same code to handle both the lower and higher attacking viruses as well as other streamlining to save ROM space and to avoid timing overruns that led to unstable screen content and overall screen lines per frame. There could still be some linecount glitches on major screen mode changes but those should not be very noticeable. Besides a more stable screen during play, the refactoring effort has freed up just under 400 bytes of ROM space in my 16K cartridge image. This is space I expect to need for a two-player game version (or two?) that I finally feel ready to get working on. While there should be no significant changes in the gameplay in this version over the prior demo release or two, I'm releasing this latest one because I feel it is more stable and should provide a slightly better demo experience. But watch this thread for new forays into the two-player realm! immunity_2022_Jun_12.bin

@rsiddall You came fairly far in a short amount of time! The single-color-per-line man looks better than I expected, to be honest. I hope you stay involved, even if others collaborate more directly from this point.

I'm really impressed with the character sprites but even more impressed with your background graphics, especially the color design. It's simply fantastic!

Agreed! It's really starting to feel like the original versions in overall effect.

@rsiddall The character looks better to me. I really like the progress on furniture. Looking forward to another .mov update!

@rsiddall The robots in the new update look pretty good to me now, even with some flicker! However, the flicker at the computer stand is quite noticeable. Is it feasible to hide the stand when the player is right in front of it searching? Also, the player's nose is looking very, how should I say?, prominent. I know the original sprite had a bit of nose, but since in you need to make the character in lower-resolution, I wonder if it would be better without that pixel?

That's cool! The original was my favorite game on the C64.

If I understand what you're saying, I tried that but didn't like the overall look for my work-in-progress game. In one section of the game that I want to use only one sprite for the game object but make it appear to have two colors per scanline. I tried it with one version of the sprite as a sort of a silhouette , with the other frame having the "accent" color sprite with transparent pixels, but it made the accent color rather washed out and not the right color I wanted: Alternatively, if I separate the two sprites so that the pixels of accent color are transparent in the other sprite, it mixes uniformly with the background, which works better I think in my case: It's a bit muted but I think it looks OK and I can explain it away as as a "fluid immersion" effect! Maybe I'll revisit this before final release, but I have a whole lot of other things I want to work on, so it won't be a high priority now that I think it works decently well in my game.

Cool!

Good point on the Atari IP!

I'm not familiar with this game at all. I just took a very quick look at the video clip (not the whole thing). Looks sort of interesting, but I'm not sure it would have the same kind of visceral addictiveness that Space Invaders, Asteroids, and many others had since the gameplay tasks seem sort of arbitrary. Vector display games are very challenging to port to the 2600 and still be recognizable. It might need some big compromises to work, like Asteroids made when it was ported, or how Star Castle was totally reworked/re-imagined and became Yar's Revenge. The 2600 hardware is not well equipped to draw extended thin scribble-like curves. Horizontal lines are not too bad, and you can easily have a few vertical lines, but diagonal/curved ones are much more of a pain! On 5200, 7800, or later machines, it may be a lot more feasible to make a decent port. Maybe a dev from one of those machines can weigh in.

Hi @LatchKeyKid! Hope you find this place fun and helpful. Hacking an existing game is not the way I happened to start, but I do believe several others have started this way, and it would allow you to change things bit by bit as you learn and can understand the original code. For some games, there are commented and annotated "disassembly" code listings available, which are very helpful to study. @DEBRO has made these for several titles, but I don't know whether Pitfall is one of these. For extra colors, you need to remember how the ball and missile object colors relate to player graphics and playfield. At a given point in time, Missile 0 is the same color as Player 0, likewise for Missile 1 & Player 1, while the Ball is the same as the playfield (foreground) color. Depending on whether the player sprites are visible in the same location as the missiles, or the ball with foreground playfield, it may not matter and you will have opportunities to switch the colors in time to use them as you suggest. So you can use Missile 1 to add a different color to the figure drawn by Player 0, and vice-versa if these figures are on different scan lines, or on alternating frames, or the colors are complementary (e.g. Player 0 is blue with a touch of red from Missile 1, while Player 1 is red with a touch of blue from Missile 0). Depending on your color needs, using the ball may fit perfectly, or the playfield is empty in near the figure you want to compose, so you can switch your playfield/ball color for the figure then switch to something for your playfield graphics. Hope that all makes sense!

This week's minor updates: I addressed the skipped score review when the health is already maxed. You will now see the earned bonus point icons swoop up, but you won't see point addition animations once the max health of 99% is reached. This helps shorten the review period if it is not relevant, but you still get some acknowledgement that you earned a bonus. I did implement the vanishing loose spike protein idea mentioned in my last reply. Over several seconds, the quantity of loose spike proteins dwindles down, and may completely disappear. Later I plan to make the rate of dwindling A/B difficulty-based. Minor fix for lung icon positioning in the score area (sometimes misplaced during score review) Moderately faster target object speeds to raise the challenge level somewhat (should I go further?) Working out some design details for a two-player game (virus versus cell version) I think I notice a very sporadic screen glitch happening. It does not seem to affect gameplay, but I'd like to fix it. To do that I need to be able to replicate it consistently, but I'm not sure what conditions trigger it. If you test this demo release and see a pattern to any glitch, I'd like to hear your observations! immunity_2022_Apr_29.bin

I have a new demo version! The changes in terms of gameplay are minimal, but I spent quite a bit of time reworking the drawing kernel for the 'extracellular' screen (AKA exo mode). It is more stable in terms of the simple playfield texture positioning and drawing of the antibodies when flung. It's also about 130 bytes less ROM space! (I bet I can use that later for the 2-player gameplay). Not saying this demo release is bug-free, but seems fairly good in some testing I did tonight. A few of the changes, if you look closely: Macrophage is drawn without flicker when away from any latched viruses at the bottom. This was done by making the fully-neutralized virus a solid color (one sprite instead of two) The exo mode bonus review if you clear all the viruses in that tissue will now only show you as many point animations as needed to reach the max health of 99%, e.g. if you had 96% when the tissue is cleared, you will see only 3 of the animated +1 point icons rather than the 10 you'd see before, which is the full bonus. If you are already at 99% when the review starts, it just flashes an empty review background briefly. I'm not sure I like this... maybe I can show something else or at least play a bonus sound effect before switching to the intracellular mode screen. One concern I have is the beginner difficulty level at least is still too easy. I think I will try to speed up all of the moving targets a bit. I may also make the loose spike proteins start to dwindle over time, so if you don't collect them right away, you won't get as many, or perhaps none at all. I'm also thinking of a type of power-up in the exo mode that will repel the viruses, giving you more time to neutralize them. Not 100% I can pull that off and still get one or two two-player game variations I'm thinking of with game-select screens, etc. 1st two-player idea: One player controls the cell's immune system while the other controls movement of the viruses and viral DNA. It would be a sort of dodge-em. At the end of a round, the roles could reverse. Scoring might be a simpler point system rather than health %. 2nd two-player idea: Rival macrophages attempt to collect the most neutralized viruses. Other helpful items can be collected, but still-active viruses will hurt your macrophage in some way. Let me know if you have any thoughts on these ideas or any issues with the current demo! immunity_2022_Apr_24.bin

@ZeroPage Homebrew Question... where did that chiptune "Disco 5" come from that you used for a recent* pre-show? I'd like to snag that and maybe see if there's more from the same musician/creator. EDIT: It was the Tober's Nightmare/Turbo Arcade After Dark episode.

Another "Developer Log" update... Changes: Packed some state flags held in several separate RAM bytes into a single byte Now allow breath count to run from 0 to 9999! (It's easy to go over the old limit of 199 now, especially in "Advanced" difficulty mode) Health and Breath score display eliminates leading zeros Breath icon relocated to left side of breath count and will adjust to stay relatively close to first visible digit Score display drawing kernel loop code moved into a macro so it is only defined once in source code for both intra and exo play modes I also created a "RAM Plan" document that shows all of my RAM declarations, organized and layed out to better show renamed/shared cases over the different execution modes. This will help me determine where I have additional opportunities to share the same RAM location between the different modes, freeing up some additional space. I anticipate that I will need to free up some space to support a better display kernel in the "exocellular" mode as well as the eventual two-player mode. I can also share some RAM values to have a nicer title and game-over screens (better graphics?) and an interactive game initialization (one/two player game select, perhaps additional options). Here's a few screen shots of the new breath count display, showing possible high values and blanking any leading zeros in the count displays.

I have a new playable demo! I finally got the scoring/status update review mode working well after both types of main play screens. Beyond the drawing kernel, there are a lot of changes as to when the scores and status levels change (now mostly synchronized with the review mode animations). I'm pretty happy with this version in terms of how it plays and overall game mechanics. It can and will be further refined before it's considered final. I did some changes to object speeds to make the beginner mode (left difficulty switch setting B) somewhat more challenging. I'm sure I will continue to tune this aspect of the game, as well as initial starting 'inventory' status, etc. The main gameplay is basically the same as the last demo. The prior early draft instruction manual is mostly still applicable, but I will document the updated status indicators and the score/status review "intermission" modes in a future manual draft. Known issues: * Exocellular: playfield drawing is a bit unstable (making it a bit vertically wobbly) even when the scanline count is OK * Exocellular: perhaps occasional scanline count issues, at least when there is a latched virus * Exocellular: when a virus is completely neutralized and macrophage is active, the virus sprite colors may not be the intended yellow + light gray (esp. when virus is low on screen?) Future plans: * Better stabilize the exocellular screen. (Perhaps just by tweaking existing code to make it work more consistently, but I have an idea to change the object positioning method to allow a cleaner drawing kernel and perhaps one or more additional infecting viruses onscreen) * Change the "breath count" to a elapsed time display? Or at least allow a full three digits or more for the breath count (too easy to hit max 199 level right now) * A two-player mode (even if simple) and single/two-player selection mechanism that is couch-compliant(R) * Perhaps switching from playfield graphics to player graphics (AKA sprites) for most text in title/end screens? * * Smooth out some of the jaggies in the title, win screen, and game-over screens? * * Longer main theme and win/game-over music? * * (Potential bonuses for the full retail version? ) Let me know your thoughts and any issues you have with this demo release! immunity_2022_Mar_22.bin

I didn't know about clubs in general! I joined up. Looks like I have version 2.20.41 (not the extra .1), so I should upgrade.

Found my object position issue. I'm a bit chagrinned that a bug that I described back in a reply on Feb. 1 came back to bite me again. It was caused by crossing a memory page boundary with the PosObject code so that the object-positioning loop runs slower than expected and mispositions the object. To avoid this bug for good, I have enhanced the macro to check the current assembly target address and trigger an assembly error and abort with a line number statement if the critical loop part includes a page boundary. Code is adapted from a @SpiceWare programming example... ;=============================================================================== ; PosObjectCode - by Darrell Spice, Jr. (and others?) ; With fix by M. Losh for current DASM's failure to force word abs,x address. ; Conversion to MACRO format to avoid source code repetition, you can place ; macro in each bank, followed with a subroutine return (ret), ; and/or can be expanded inline with other code. ; Added check for code page crossing in loop, which throws off timing and ; therefore the object position. If page crossing detected, will abort ; assembly so you know to fix it (e.g. rearrange code to avoid page crossing) ;---------- ; for setting the X position of any TIA object ; when called, set the following registers: ; A - holds the X position of the object ; X - holds which object to position ; 0 = player0 ; 1 = player1 ; 2 = missile0 ; 3 = missile1 ; 4 = ball ; the routine will set the coarse X position of the object, as well as the ; fine-tune register that will be used when HMOVE is used. ; ; Note: The X position differs based on the object, for player0 and player1 ; 0 is the leftmost pixel while for missile0, missile1 and ball 1 is ; the leftmost pixel: ; players - X range is 0-159 ; missiles - X range is 1-160 ; ball - X range is 1-160 ; Note: Setting players to double or quad size will affect the position of ; the players. ;=============================================================================== MAC PosObjectCode sec sta WSYNC IF (((* & $00ff) > $00fb) && ((* & $00ff) <= $00ff)) echo "PosObject has page crossing that will cause incorrect positions! Address: ", * ERR ENDIF .divideLoop: sbc #15 ; 2 2 - each time thru this loop takes 5 cycles, which is bcs .divideLoop ; 2 4 - the same amount of time it takes to draw 15 pixels eor #7 ; 2 6 - The EOR & ASL statements convert the remainder asl ; 2 8 - of position/15 to the value needed to fine tune asl ; 2 10 - the X position asl ; 2 12 asl ; 2 14 .byte $9d, HMP0, 0 ; force sta.wx HMP0,X (word-address absolute store indexed by x) ; 5 19 - store fine tuning of X sta RESP0,X ; 4 23 - set coarse X position of object ENDM There are only a few bytes in the critical sbc and bcs instruction loop, but if this loop with starts on a 0xXXfc through 0xXXff address, there will be a page-crossing time delay, throwing off this masterfully-constructed bit of code. This macro now looks for this condition and will not let me build a ROM with this issue in it. Hope this helps someone else avoid this subtle bug!

GAHHH! Work on the animated scoring review screen after the "exo" mode isn't going great. It sort of works, but animation runs much longer than it should and pulls in improper sprite data. But worse than that, I have now a regression on the main "intra" play mode where the two parts of the free ribosome (ball and player 0 missile) are not positioned together as intended... the TIA ball object is progressively shifted rightward the further both objects are moved toward the right side of the screen, and it eventually wraps around to the left side when the missile is still on the right. Maybe I'm violating some TIA register change time restriction where the count can't settle into the intended value before its disrupted by something. But I don't think I was mucking around in that part of the code, and my strobe of HMCLR is about 35 cycles after HMOVE, so things should be settled by then, right?

I hope you are all well! I've been rather quiet lately from a combination of more-than-usual family events going on and some rather tricky development on Immunity lately. I've been implementing a scoring review/update mode after one screen of intracellular game play is completed. It's now nicely animated, but it was a bit of a beast to get working well, especially scanlines per screen. I've had some really frustrating hours tackling the scanline issues... rather like whack-a-mole... they kept popping up! Another thing I'm trying now is using flicker to draw the free-floating new viruses in the intracellular screens. While it makes them dimmer and more blueish (due to mixing of the playfield background color), it allows them to appear normal in terms of overall shape and color distribution. Unlike the exocellular screen, where I use both P0 and P1 sprites simultaneously to draw the free-moving viruses, on the intracellular screen I really wanted to keep P0 free for the vitamin, energy, and loose spike protein objects that can appear basically anywhere relative to the free-moving new viruses. I had been using a single sprite with alternating color bands for the virus, but was not very happy with its appearance. As for the new look, hmmm, perhaps I can claim the blueish and dimmer color is due to the fact the virus is still inside the cell's cytoplasm! Before I post a new playable demo, I want to implement a similar scoring review/update mode for the exocellular screens. If I can mostly reuse existing code for that, I might be able to post a new demo here tomorrow! At the worst, hopefully no more than a few days. Here are a few teaser screen captures. \ P.S. Something came up in my family today that left me with less dev time. I did manage to make the review animation even more lively, however!

I really enjoyed the interview with Andrew Pauley on Friday's steam when I caught the replay today! It was great to hear him explain his thought process for using the relative strengths and managing the weaknesses of the 2600 to make a great game with the elements he wanted to include.