Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

e1will

Members
 View Profile  See their activity

  • Content Count

    364

  • Joined

  • Last visited

Posts posted by e1will

  2. Posted · Edited by e1will

    Attached is the latest version, v0.08. I've believe I have fixed all the bugs and eliminated all the screen rolls/jitters. It should hum along at a constant 262 or 312 lines per frame now, no matter what. Please let me know if you see otherwise.

     

    I've also included a PAL-60 version in addition to the PAL-50 version. All 3 versions should look and play identically except for PAL-50 being slightly slower than the other two.

     

    Another change I've made is to enable the Fire button to start a new game even in demo (attract) mode. You can now play game after game without ever having to touch the console (unless you want to pause the game or change the difficulty settings.) At the "select level" screen, you can use the joystick up and down to select the level number (1-9), left and right to turn on or off random mode, and fire to start the game.

     

    I think I'm going to call this "release candidate #1" since there no bugs I'm aware of, I've included all the features I had wanted, and (I think) I've incorporated everyone's suggestions so far.

     

    Let me know what you think... is this ready to go on a cart, or have I missed something?

     

    Thanks,

    --Will

    post-23222-125944879696_thumb.png

  4. Posted · Edited by e1will

    Here's the latest version, v0.07, which has some bug fixes and various enhancements. The biggest changes are:

     

    - If you go through a door and a duck watches you do it, it may follow you through the door.

     

    - The snakes now inch up or down towards you, and don't leave the room you're in (they will keep on winding back towards you until you leave the room.)

     

    - I was finally able to add JohnnyWC's excellent suggestion to let you struggle against the river currents and eventually free yourself. I've made this a difficulty setting: Choose "A" on the Player 2 difficulty switch for the old behavior (river is too strong to struggle against) or "B" for the ability to free yourself from the rivers.

     

    - I've added some more bad guys in various places.

     

    The feedback I've received so far has been very helpful, and I'm very open for more. What do you like about the game? What do you dislike? What might make it better?

     

    --Will

     

    EDIT: Here's another screenshot... PAL for a change.

    post-23222-125911191392_thumb.png

  6. Posted · Edited by e1will

    Hello everyone!

     

    I've been spending the last couple of months trying to cram 48k worth of code and graphics into 32k of ROM space, and I think I've succeeded. Attached is the latest version of Duck Attack! (v0.04). The changes since the last version have been too numerous to mention, but the big ones are:

     

    - Random mode: move the joystick right or left at the Game Select screen to turn random mode on (all objects will be scattered randomly throughout the game) or standard mode (objects are put in the same place every time you play).

     

    - Title cards: every time you complete a level, a title card appears showing the bonus item for the next level. (Sample screenshots attached.) There are 100 unique bonus objects.

     

    - The super outlet: this is a red recharging station (electrical outlet) that lets you stun a duck permanently (at least to the end of the level). The other (yellow) outlets only stun them temporarily (about a minute in the early levels, decreasing to a few seconds at the higher levels.)

     

    - More bad guys: there are two types of bees: a yellow one, which mostly minds its own business, and an orange one which is more aggressive. There are more snakes, and they're faster.

     

    - Meaner ducks: If you manage to collect 25 eggs, the ducks get much faster and more aggressive.

     

    - An easter egg: I won't say too much about it, but you'll know it when you see it. The one hint I will offer is that you'll need the blue balloon to find it.

     

    I need to update the manual to reflect the changes I've made; I'll be working on that over Thanksgiving break.

     

    What's here is pretty much all the functionality I'd originally envisioned. Let me know if you notice any bugs, or have any ideas for ways to improve the gameplay. So far everyone's suggestions and comments have been great.

     

    Enjoy!

     

    --Will

     

    EDIT: I found a bug relating to the random placement logic in v0.04. It's now fixed: v0.05 is now attached.

     

    EDIT 2: Noticed a couple of screen rolls in v0.05 and fixed those. v0.06 attached.

    post-23222-125884815589_thumb.png

    post-23222-125884816498_thumb.png

    post-23222-125885009312_thumb.png

    post-23222-125885010757_thumb.png

    post-23222-125885029084_thumb.png

  9. Posted

    Even without being a programmer I doubt it will be possible to do a giant boss

     

    Depends on how big you want it. If memory serves, the Arrangement boss took up about 1/5 of the horizontal space, and as luck would have it, that's exactly the size of a quad sprite: 32 pixels out of a 160-pixel wide screen. So that part of it shouldn't be a problem at all. Look at the bridge in Adventure for a good estimate of the width you'd get. And of course, you can make it as tall as you want.

     

    What you propose is quite doable. Doesn't mean it wouldn't take a long time (either making sense of the .asm or doing it from scratch), but it's definitely possible.

     

    --Will

  11. Posted

    Ok, I went back to school, and tonight I managed to score 1888. Anybody got that beat?

     

    Truly an excellent game, and the deadly abyss is not a bad ending to the game either - you can try to cheat it, but eventually random effects will get you! (I'm thinking at that point the game has wrapped past the rom and is scrolling from ram.)

     

    This post is also an excellent excuse to ask if anyone has heard from Alex, so I'm asking. :)

     

    I was able to get 2055 a couple of months ago, but that's the only time I've ever broken 2000.

     

    --Will

    post-23222-125535128545_thumb.png

  12. Posted

    I don't mean to sound so negative, but it seems that little detail added a perceived problem of "poor control" to Atari's game. The game doesn't have poor control, it just feels that way. Hacking the game to include upward and downward sprites made a world of difference. If the sprites were omnidirectional (as Lock'N'Chase uses), that also eliminates this perceived problem. So IMO it might be better to use something unique if 4 directions are not possible to display.

     

    No, you're right to point out the downside. I was certainly among the millions of people scratching their heads over the lack of up and down sprites in the original. (Although, as I learned more about the hardware/software limitations of the system, it occurred to me that maybe it was that way because Frye had been toying with the idea of making Pac-Man a ball or missile sprite. Obviously, before he decided to add the 'eye.')

     

    The Lock'N'Chase solution to the problem was pretty clever, although I obviously can't do that here. (Missile-ghosts would be pretty darn ugly.)

     

    Honesty, I think it can be done, even if it takes a convoluted mess of code and 20 separate kernels to accomplish it. As a worst-case scenario, it could always be accomplished by further restricting ghost movement, although I'd obviously like to avoid that.

     

    My only "rule" is no flicker. It's a perfectly appropriate technique to use, but with the high-quality Pac-Man versions out there that DO use the technique (i.e. yours!) there seems little point in me adding another version unless it does something that hasn't been done before. I think the gameplay differences between CE and the original are necessary but not sufficient to warrant another version, since there are already really good versions already.

     

    --Will

  14. Posted · Edited by e1will

    I've been giving some thought about what my second game should be once I finish my Duck Attack! homebrew, and I think I might like to tackle porting the XBox Live Arcade game Pac-Man Championship Edition to the Atari 2600.

     

    The most exciting part of it is that I've figured out how to do it with no flicker. Zero. None. Pac-Man and all four ghosts on the screen at the same time, on all frames. Even when there's a bonus item on the screen too. As best I can tell there haven't been any flicker-free Atari Pac-Man ports or clones before, so this should be a pretty neat addition to the roster of 2600 games.

     

    Here's how I'm planning to do it. Pac-Man uses the ball sprite. If you've played Duck Attack! and reached the arcade level (Level 3), you've seen a rough version of the ball-sprite-as-Pac-Man animation in action. The main limitation in using the ball sprite is that Pac-Man can only face left or right (like in the original 2600 Pac-Man port), not up or down, but I think that's a fair trade-off for avoiding the flicker.

     

    The second limitation in using the ball sprite is that the dots and maze walls will need to be yellow too... but only on the horizontal lines where Pac-Man is. This actually works well with the Championship Edition visuals, as the walls change color near where Pac-Man is. The yellow lines would fade to a different color going up or down from Pac-Man. The 4 ghosts will also influence the color of the playfield to match the CE visuals. For example, if the screen contains (from top to bottom) Blinky, Inky, Pac-Man, Pinky and Clyde, the playfield and dots will fade from red to blue to yellow to pink to orange going from top to bottom.

     

    Since Pac-Man is using the ball sprite, that frees the P0 and P1 sprites for the four ghosts. The ghost AI will need to be set up so that Inky and Clyde stay out of Blinky and Pinky's way as they pursue Pac-Man, which is not drastically different from what they do normally. Blinky and Pinky will have basically unconstrained movement (except when a bonus item is on the screen, in which case Pinky will make sure to avoid the horizontal area that Blinky is occupying IF it's the same horizontal area the bonus item is in. It helps that with CE there are tunnels at the top and bottom of the screen; if Blinky is "crowding" any of the ghosts toward the top or bottom of the screen, they can use the tunnels to loop around to ensure Blinky complete freedom of movement without worrying about a scanline collision.

     

    There will be a special, separate kernel for the initial moments of the game, where Pinky, Inky and Clyde are all bouncing up and down in the monster pen. Here, Inky and Clyde will share P0, using the "two copies" NUSIZ0 setting with the color changed in between them. Once Inky starts to leave the monster pen, it will switch to the regular kernel described earlier.

     

    One key thing the CE version has that the "old school" Pac-Man games lack is the background music. Would anyone be interested in designing the musical part of the game? I don't necessarily want the exact music that the XBox version uses; some original music with a similar feel to it would be fantastic.

     

    (And I'm also not planning on actually calling the game "Pac-Man Championship Edition." I haven't decided what yet, but I don't want to use any names that are already trademarked. I figure it's better to err on the side of caution and just call it "Championship Edition" or "C.E." or "Cruise Elroy" or something.)

     

    --Will

    • Like 2

  16. Posted

    Absolutely, some of the games haven't aged well. I used to love Dodge 'Em when I was young, but these days there's not a whole lot of replay value. Once you figure out how to beat it and you can do so without thinking, it's more like a chore than an adventure to keep beating it.

     

    A lot of the fun of any game, Atari 2600 or otherwise, is in discovering what it's all about, learning how to beat it, finding all of the hidden tricks and techniques that let you get the most of it.

     

    I'd encourage you to try some of the newer homebrews. Some of them are really, really, good, and almost all of them offer that new experience that's likely missing from the games you've already wrung all of the interesting bits out of.

     

    Thrust is an excellent game, Ladybug is simply brilliant (I loved the game in the arcade the port is flawless), Man Goes Down is wildly addicting, even in its unfinished state... I'm sure others could suggest more games.

     

    --Will

  18. Posted · Edited by e1will

    And you could use PlayerY as PF2_L, since PlayerY could be recalculated after the kernel is done by subtracting ENABL_PTR from ball_enable.

     

    EDIT: Looks like combining PF0_L and PF0_R into PF0_LR and pulling the bank # from PF_PTR only used up 4 cycles, leaving 21 cycles free including the WSYNC.

     

    --Will

  19. Posted

    What can I do if I want the check to reflect a specific register but I can't change it at that time?

     

    Not sure I follow... whichever register you want to check will have an associate 'compare' opcode: CMP for A, CPX for X, CPY for Y. You typically (but not always) will follow one of those compares immediately with a branch.

     

    The branch condition is based on whichever compare (or load, or add/subtract operation, etc.) last set or cleared the bit you're testing.

     

    --Will

  20. Posted

    Also, there might be just enough free cycles in that kernel to combine PF0_L and PF0_R, and/or combine PF_BANK with something.

     

    The best bet for merging PF_BANK would probably be to structure the PF data so that each playfield definition starts aligned with its bank number. For example, data in bank 0 would start at $Fxx0 or $Fxx8, data in bank 1 would start at $Fxx1 or $Fxx9, so you could just AND #$07 the PF_PTR to get the bank # for bankswitching.

     

    So that's another 2 RAM bytes saved (assuming PF0_L and PF0_R could be combined without using all the extra cycles; I have tried that yet.)

     

    And since bits 5-7 of the high bytes of OBJ0_GR_PTR, OBJ1_GR_PTR, PF_PTR and ENABL_PTR are insignificant, you could store a byte and a half in there, prior to entering the kernel, and that wouldn't use any kernel cycles. For example, CarryX and CarryY might fit nicely in there, if you can confirm that bits 5-7 of those will always be the same. You could then use CarryX and CarryY as PF1_L and PF1_R, and then restore their original values from the PTRs after the kernel's done. That frees up another 2 bytes.

     

    --Will

  21. Posted

    Thanks for the quick reply.

    Well, I was frustrated...

    I wasted a lot of time, because I thought it could be used with some wierd trick to test any bit of a byte (would save cycles).

     

    So I'm stuck with the typical coding:

      LDA Control_register
  AND #$08
  EOR #$08
  BNE Jumppoint
        ;Bit 3 is set
Jumppoint

     

    Is there any way to streamline this code?

     

    Well, you could drop the EOR and switch the BNE to a BEQ:

     

      LDA Control_register
  AND #$08
  BEQ Jumppoint
        ;Bit 3 is set
Jumppoint

     

    --Will

  22. Posted

    Is there something usefull you can do with it?

     

    Lots of things:

     

    - You can use it to set the V flag, since there's no SEV instruction analogous to CLV

    - You can use it to skip bytes (see this page for a helpful summary on how)

    - And most importantly, like cd-w says, you can test bit 7 or bit 6 of a memory location while keeping the A, X, and Y registers intact.

     

    Its usefulness may not be immediately obvious from its description, but I've found it to be extremely helpful in the coding I've done so far.

     

    --Will

  23. Posted

    The real downside is that it burns 7 bytes of temp ram above the original game. I'm currently trying to figure out a way to save ram among objects. Merging delta with state is one way (which saves 1 byte for each AI object).

     

    Saving romspace is not important. Saving ram is essential. Otherwise, there's little chance of putting in all of Indenture's objects without adding ram to the cart.

     

    Seems like there are probably still some opportunities for combining RAM bytes, at the expense of some outside-the-kernel cycles to manipulate them. For example, all 5 gate states could probably be combined into two bytes, freeing up 3:

     

    BYTE 1

    bit 7 = yellow gate open

    bit 6 = white gate open

    bit 5 = black gate open

    bit 4 = green gate open

    bit 3 = flashing gate open

    bits 0-2 = which gate is currently being opened or closed (000 = none, 001 = yellow... 101 = flashing)

     

    BYTE 2

    bits 0-2 = state for currently opening/closing gate (8 positions)

    bits 3-7 = free

     

    You could then use bits 3-7 of the second byte to store CarriedObj, since there are (I think) less than 32 objects that can be carried.

     

    Or maybe you've made some of these optimizations already... I'm just going off the Adventure(asymmetrical).asm.

     

    --Will

  24. Posted

    BEQ = brance on result 0 Z = 0: Result of what a compare? It says the flag is Z. I guess this means "Zero". Is this automaticaly based on Accumulator, X, or Y index or does one need to transfer the result over?

     

    A compare, or a load, or a variety of other things. For example:

     

    LDA #55         ; sets the Z flag to 0, since 55 is not zero
LDY #0          ; sets the Z flag to 1
LDX #33         ; sets the Z flag to 0
CPX #33         ; sets the Z flag to 1, since X=33
CPY #33         ; sets the Z flag to 0, since Y is not 33
BEQ Someplace   ; does not branch, since the Z flag is 0 (as set by the CPY immediately above.)

     

    Hope this helps.

    --Will

  25. Posted

    I really like the idea of Indenture on the 2600... Sounds like the idea of a using a 3-line kernel for it was a non-starter, so I took the liberty of trying a 2-line kernel that might work without having to interlace.

     

    It's actually a hybrid 4-line/2-line kernel: P1/P0/ball updates each 2 lines + PF updates each 4 lines (of course, 6 PF writes each line since it's asymmetrical.)

     

    The pros are it works, and there are actually 20+ cycles free each loop for additional logic. And it's not TOO much of a RAM hog (doesn't require a PF index, for one thing.)

     

    The cons are it requires a page per graphic image, which is a huge waste of ROM. On the upside, those 20+ cycles might be used to re-work it so it doesn't have to do that.

     

    Thoughts?

    post-23222-125247249724_thumb.png

    asymtest.zip

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...