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

    Hello again!

     

    I'd like to thank everyone for your kind words and helpful suggestions. I've been able to incorporate several of the suggestions into version 0.03. I really appreciate the feedback!

     

    v0.03 has several significant improvements, including:

     

    - An arcade-style "attract mode" where the computer controls the robot to demonstrate how the game is played.

     

    - A pause feature: use the TV Type switch to pause the game (B&W position) or unpause it (Color position) I also incorporated 7800 detection code (thanks to Nukey Shay for posting how to do this) to handle the 7800 Pause button.

     

    - Most importantly, you can now win the game! All the levels are in place, as are all 25 eggs. If you somehow manage to complete Level 12, the egg count resets and the ducks speed up.

     

    - The scanline counts should be (mostly) stable now. Thanks to Nukey for pointing out one case where they weren't... a little digging let me to discover that there were a lot of other places too. I've had to do a major overhaul of the code to get rid of the timing problems, but it should now be a constant 262 scanlines for NTSC and 312 for PAL. (There are three exceptions I know of where it does roll: pressing Reset from the Select screen, pressing Select from within the game, and a serious jitter if you pick up a bonus item while carrying both the zapper and an egg. I know why it's doing this, but fixing it is going to be a major task, and may take a while. In any case the first two cases (Reset & Select) may not be visible on an emulator, and the third does not occur in the PAL build. If you see any other jitters or rolls in the game, please let me know.)

     

    - The "arcade" zone, behind the pink door, has some new (yet familiar) characters to attack you.

     

    - The "warp of death" is now present. You can sacrifice your current life to advance to the next level if you can't figure out a way to finish it.

     

    - I've added some levels where the river actually helps you rather than just sweeps you to your death. You'll have to jump in at least one river to get an egg, and doing so will take you someplace useful. Don't just hop into rivers indiscriminately, though, they are still (mostly) deadly!

     

    - You no longer have to re-collect eggs you collected in the previous level. Each level from 1-11 now only requires you to collect 2 eggs to advance to the next level. You need to collect 3 eggs on Level 12, and 5 on Level 13 and higher.

     

    - The magnet behavior is now different: if you're carrying objects, the magnet ignores them and attracts "uncarried" objects. This should make the magnet much more useful.

     

    I'm really excited about the new version... I hope you enjoy it! Let me know what you think.

     

    --Will

  3. Posted

    In fact, sometimes you have to remove a WSYNC so you can squeeze in one more instruction! :)

     

    Michael

     

    Yep, the main kernel in the game I'm working on takes exactly 228 cycles, and the WSYNC was the first thing that got dropped once I started needing to squeeze more code into it.

     

    Granted, you have to be much more careful about branches that cross page boundaries (and branches in general, since they have to "meet up" in both the same point in code AND the same elapsed cycles without WSYNC) and any indexed data (without a WSYNC you'll usually be able to tell really quickly if something's unexpectedly crossing a page boundary since the screen will be completely out of whack from that line down, especially if you use HMOVEs.)

     

    But it definitely can be done.

     

    --Will

  4. Posted

    A few more interesting notes:

     

    SPOILER

     

    Loving it!

    Thanks!

     

    The thing the magnet is most attracted to is the egg, followed by the balloon, so if you're holding those things it won't attract anything else in the room. I may change that though, now that you mention it... it should be easy enough to code it so the magnet only attracts things you're not already carrying, and more intuitive too.

     

    There are a few doors that will take you back to the beginning, or to various other places that you might not expect. There are a couple of really nasty doors in a later level, but I'll leave those for you to discover (they're not visible in v0.02).

     

    I'm putting the finishing touches on v0.03 now; I hope to post that by Monday. It's got more levels, along with an arcade-style attract mode (demo mode that shows you how to play) and a pause feature.

     

    --Will

  5. Posted

    Any chance you can give the player a chance to swim to shore with enough time? For example, have the player's movement only happen once every second or so (or faster)...

    Or maybe even being able to use the river to your advantage. But very risky!

     

    I like this idea. I think I'll include a level where you have to hop in a river to get to a certain egg. It could sweep you into the egg, then into an exit door if you time it right.

     

    --Will

  6. Posted

    Played through all five levels tonight (once I remapped the button :) ). Very fun game, lots of stuff to do and places to explore! I can't decide if playing through the previous level as part of the subsequent level is part of the charm, or if it gets redundant. So far it is still pretty fresh, though. I LOVE recharging the zapper in the electrical outlet! Genius!

     

    Couple of SPOILER level questions though:

     

    I agree, having to playing through the previous level is redundant; I've changed that in v0.03 (which will be posted once I work out some bugs in the attract mode.)

     

    You need either the balloon or super-speed (from picking up the pink balloon) to complete the level you mention. Since you'll no longer have to get through the previous levels, you should be more likely to have super-speed by the time you get to that level in the next build. At any rate, I will be putting more pink balloons around to pick up, probably in v0.04.

     

    I know there are a couple of rooms with borders that are too thin, that let you peek through to the next room without actually being able to get in. That'll get fixed too.

     

    The golden egg has a better location in v0.03. Where it is now is just an artifact of it not having a "location" at all (e.g. it's in room 0, horizontal location 0, vertical location 0).

     

    The flashlight will be required in later levels, but you can use it on earlier levels too (e.g. the room with the black door, and the rooms behind the black door.)

     

    As for the shield, pick it up and run into a tank for a good demonstration of what it does.

     

    Hope this helps!

     

    --Will

  7. Posted

    This is all kinds of fun. But I am having all kinds of trouble firing the zapper at the Ducks. It just sits there atop my head doing nothing that I can determine. Also, if I hold the joystick button and press the joystick in a direction, I am sometimes transported to a different room??

     

    I love how big the world gets after level one! There seems to be a lot to see and do in this game. Very fun! Please keep up the good work, I look forward to the eventual release!

     

    Ah, you have stumbled on the 'debug key'! The right joystick fire button does what you describe (switches to the next room), but the left joystick button should throw the zapper. Perhaps you have your fire buttons mapped to the opposite joysticks?

     

    --Will

  8. Posted

    Looks pretty good, but... huh? This looks more like a parody of a 2600 game than the genuine article. Mallards invading Pac-Man? That reminds me of one of those weird random jokes from Family Guy.

     

    Well, if weird random mash-ups aren't your thing, you probably won't like these screens either. :)

     

    The vast majority of the screens are entirely new, but I do slip in a few homages to my favorite games behind the pink door. Everything outside the pink door is (mostly) homage-free.

     

    --Will

    post-23222-125140920867_thumb.png

    post-23222-12514092164_thumb.png

  9. Posted

    Just tried this out for a few minutes. Will play some more later.

     

    Very original game and design! Also, a unique concept! I like it! :)

     

    I am curious about the screens with text ( game select, credits, etc ) Did you write a minikernel for that section of the screen? It appears you are using the 6 player sprite "score" trick to display text like that?

     

    Thanks!

     

    Yep, the text is done using the standard 6-digit score logic. There isn't any "text" logic per se, it's all just 8-bit-wide sprites put next to each other.

     

    --Will

  10. Posted

    The remaining lives screen is only 261 scanlines. The rest appear to be 262.

     

    Hmm... which emulator/version are you using? I'm seeing 262 scanlines for all of them in Stella 2.8.4.

     

    Z26 version 2.13 (I dunno if it appears in more-recent versions). The scanline difference does not show up immediately. The way that I'd seen it was to go to the tank screen to the left, pick up the balloon, and get killed by the tank. The player returns to the lives screen with a high probability that the scanline count will be short by 1. When this difference is active, it appears to give a slight jitter when moving between other screens as well. Running out of time in overscan?

     

    Ah, I see it now! How weird. It must be the values I'm stuffing into TIM64T for the vsyncs... I'd been fiddling with them to get the scanline count right for PAL. I'll have to take a closer look.

     

    Thanks!

     

    --Will

  11. Posted

    I just gave it a very brief play at the office (PAL version). Looks good so far, I definitely will try it out later.

     

    BTW: The manual mentions the hot air ballons starting at level 4, but the appear in level 1 already.

     

    Ah, I need to clarify in the manual that only the blue ones give you the ability to coast over the walls... other-colored balloons will indeed appear in earlier levels, but they do different things.

     

    --Will

  12. Posted · Edited by e1will

    Any screenshots?

     

    There are some on the manual page, but here's another.

     

    I like this one because it demonstrates one of the things I was trying to do: get three interesting-looking sprites on the same line at one time (robot, tank, duck) without flickering. The tank is drawn using the ball sprite, which is resized and moved every third scanline. The poison arrows are done the same way.

     

    Here's another example, with the robot, a chomper and a bonus item (key) all on the same scanline. This is from a room behind the pink door... there are a few more rooms that should look familiar behind that door.

     

    --Will

    post-23222-125129879873_thumb.png

    post-23222-125130011338_thumb.png

  14. Posted · Edited by e1will

    2010-09-02 update: Duck Attack! is now complete: you can now find it in the Atari Age store.

     

     

    Hello everyone!

     

    First off I want to thank everyone on these forums (especially Nukey Shay, batari and supercat) for being so helpful whenever I've had questions. And I'd especially like to thank stephena for the work he's put into Stella; it's really a phenomenal emulator and a simply indispensable development tool.

     

    I've been programming for many years, and I finally decided to take the plunge and attempt a homebrew game for the 2600, written in assembly from scratch. It's far enough along that I think it's ready to show people... I'd love to get some feedback on it, good or bad.

     

    The game is called Duck Attack! and its premise is simple: collect radioactive duck eggs for points while avoiding giant, mutant, fire-breathing ducks.

     

    I've written the first draft of a manual for it here, with some screenshots: http://willnicholes.com/duck

     

    The game is about 60% done: 81 of the 135 planned rooms are in place, and you can get as far as Level 5. A few of the features listed in the manual aren't done yet (e.g. the pause feature) and I've still got a lot more features to put in (the big one is 'demo mode') but the basics are in place and (I think) working pretty well.

     

    It's been a lot of hard work, but it's been pretty fun too. I hope you like it.

     

    --Will

     

    EDIT: Adding some screenshots. The latest binaries are here.

     

    post-23222-126418690096_thumb.pngpost-23222-126473230676_thumb.pngpost-23222-126473239614_thumb.png

  15. Posted · Edited by e1will

    Without wasting ANY additional ram or relying on illegal opcodes, an asymmetrical playfield is possible (with panels and variable line counts) by blanking every other line. About the only drawback would be that objects cannot be hidden behind walls. Here's a pic of the latest binary I'm editing.

     

    Looks nice! Another option would be to switch to a 3-line kernel; the playfield could be solid, and identical to the original if you change the frequency of playfield updates, although the player sprites would be stretched vertically.

     

    --Will

    post-23222-125104723508_thumb.png

  16. Posted

    My question is, would it be sufficient to have fixed colours for P0/M0, P1/M1, PF/BL and BK, or would you prefer separating the colours that share a register? The latter is probably more informative, but it requires quite a bit of reworking to the TIA core (since it doesn't model 7 colour registers, only 4).

     

    IMO 7 would be neat but 4 is probably sufficient if the ability to toggle each one on and off individually remains. (And is available from 'pause' mode.)

     

    Unrelated, is there a way to "unfreeze" the CPU after it runs over a "KIL" opcode (e.g. $02)? 'reset' sends the program counter back to where the reset vector points but I can't figure out if there's a command to "really" reset the CPU and get the PC moving forward again without exiting and reloading the ROM.

     

    --Will

  17. Posted

    I just ran into this same issue. I had some code at $FEF6 that I was trying to jump to from $FF42, and kaboom! It switched banks from #5 to #2. I sure wasn't expecting that.

     

    I'm glad somebody posted about this so I'd know what's going on. I presume this means that for F4 and similar bankswitching schemes, there's a certain chunk of ROM space in each bank where it's unsafe to put branching code, say around FF00-FF80?

     

    --Will

  18. Posted

    A stack write would modify location $1F4. It is mirrored at $F4, but trapping seems to only trap the literal address and not all of the mirrors.

     

    EDIT: from a programming perspective, it would be nice to be able to trap all mirrored locations as an option, but I wouldn't want that to be the default behavior.

     

    I put in a trapwrite for $01F4, and that caught the writes to $F4 that were from the stack. So this might just be a case of the user (i.e. me, in this case) needing to trap for both $nn and $01nn when trying to catch modification of those zero-page RAM locations.

     

    But I agree, it would be a handy option to trap all writes that end up changing zero page memory, whether it's the stack or some errant code that's trying to store to some weird address that ends up mirroring to $80-$FF.

     

    --Will

  19. Posted

    So ideally I'd like to get a test ROM with the error occurring, a description of how to reproduce the error, and a description of how you'd like it to work.

     

    Sure, no problem. I'm attaching the version of the bin (in-progress homebrew) where I noticed this.

     

    Load the bin, then press reset. Enter the door on the left.

     

    A new screen will appear: the player will be carrying two objects, a lightning bolt and a flashlight. At this point you can see in the debugger that memory location $F4 (which holds a pointer to what object(s) the player is carrying) contains $E3. Put a trapwrite for $F4.

     

    Toggle out of the debugger and press the fire button to drop the two objects. Dropping the objects resets the "carrying" pointer at $F4 to zero, and triggers the trapwrite.

     

    Toggle back out of the debugger, and then press Select. The trapwrite will again trigger as the STA $00,X in the "clear all variables" logic is called. It's essentially replacing the zero in $F4 with another zero.

     

    Toggle back out of the debugger. Toggle back in, and you'll see $F4 now contains $B5, even though the trapwrite was never triggered for that change.

     

    --Will

    DUCKNTSC.BIN

  20. Posted · Edited by e1will

    The main question would be: how do you detect whether a memory modification is due to stack activity?

     

    I suppose I wasn't so much concerned with Stella telling me why the memory modification occurred (since I could figure that out based on what the code is doing) as long as it would break when the modification occurred for addresses I'd set up watches/trapwrites for, which it wasn't doing.

     

    I can get around the problem by putting in a "breakif { *$F4 != 0 }" since I know the value should be zero unless it gets tromped by the stack or by some other bug elsewhere in the code, but it just seemed odd that the watch and trapwrite diddn't catch the modification.

     

    --Will

  21. Posted

    Don't forget the stack is always in page 1 not page 0. It exists between $0180 and $01FF on the 2600. Its only the hardware's address decoding that folds it into $0080 to $00FF range. Maybe you should see if trapping a write to $1F4 works.

     

    Interesting, I hadn't considered that. So that raises the question that if I had a bit of code that writes to $0180 (for example), would that change the contents of $0080 but not trigger a trapwrite or condition on $80?

     

    --Will

  22. Posted

    Not sure if this is a bug or by design, but I thought I would mention it...

     

    I was trying to trap whatever code was modifying the memory in $F4, and neither "watch $F4" or "trapwrite $F4" would cause the debugger to break, even though it kept getting changed.

     

    It turns out it was a stack-too-deep problem, and the return addresses getting pushed onto the stack were trashing the value in $F4. Is there any way to trap modifications to memory addresses that are due to stack activity?

     

    --Will

  23. Posted

    Here are my maps btw, no reason to wait for someone to ask for them. :)

     

    Thank you for posting these! I was seriously addicted to that game when it came out. I was so bummed that I never got a T-shirt!

     

    --Will

  24. Posted

    Sounds like you have the "Sticky-Keys" feature turned on in Windows.

     

    Nope, this is a sporadic thing. Only seems to happen about every 10th or 20th time. Open up Stella and Notepad, and Alt-Tab between them enough times and you'll see it too. From Notepad, Alt-tab to Stella, hit Enter to load whatever game is selected, exit the game, Alt-tab back to Notepad, and repeat.

     

    (And I long ago disabled Sticky Keys and some other "helpful" Windows features.)

     

    --Will

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...