e1will
-
Content Count
364 -
Joined
-
Last visited
Posts posted by e1will
-
-
Hello all,
New version attached: v0.15.
The biggest change in this version is that it is MUCH easier. Specifically:
* The ducks appear more gradually: only 1 duck in Level 1, 2 ducks in Level 2, etc.
* The recharging station is now available starting in Level 1.
* The blue balloon is now available starting in Level 2.
* The game no longer speeds up both the ducks and projectiles (fireballs, tanks, etc.) on Level 13; now the projectiles speed up on Level 28 but the ducks do not.
To compensate I've changed the right difficulty switch to control the speed of the ducks: Set to B for normal-speed ducks, set to A for fast ducks. This difficulty switch previously controlled whether you could successfully struggle against the current in a river. The "yes, you can struggle" setting is now permanently on.
I've also added an idle/screensaver mode. If you don't move the joystick for about 8 minutes, the screen will turn off. To turn it back on just move the joystick.
I've also implemented Nostalgic's suggestion to pause after losing a life before the game returns you to the score room. Now when you lose a life, the screen will stay up for about a second and a half before switching to the score room.
Enjoy! Please keep the comments and suggestions coming!
--Will
-
This looks pretty neat. I especially like the sprite graphics. Good work! I look forward to seeing more of this as it develops.
(I do agree with cd-w and the others about the death-by-falling-off-the-screen, though.)
--Will
-
Sounds cool.
I like Duck attack, but it would still be cool to see the fire, shield, and torch added in Adventure. Think that will ever surface?
Quite possibly. Maybe I'll call it Dragon Attack!
--Will
-
Is it possible to throw the zapper up and down, in addition to just left and right?
Right now it's just left or right. Would adding up and down be a useful feature?
I think so... quite often there's a duck above or below me that I'd like to zap, and can't.
OK, I wasn't sure if I could find enough spare ROM bytes to pull this off, but somehow I did.
Version v0.14 attached: the zapper can now be thrown up (there's probably a better way to phrase that) or down.
--Will
-
Apparently nobody has the time to add the line counter and score counter in ASM. That's too bad. Are there any other suggestions?
You could make the different shapes different colors!
(Just kidding. I mean, you could, but that would definitely be an ASM project. And even then, it would be a pain to code.)
Regarding the score, I'm not 100% sure you couldn't do that in bB. If putting them side by side isn't doable, you could always do something like this:
P1SCORE P2SCORE P1LINES P2LINESI don't know enough about how bB works to say for sure, but one of the bB experts might be able to comment.
I'd offer to code some ASM for it, but I've got too much on my plate right now as it is, unfortunately.
--Will
-
New version, v0.13, attached.
Just some minor tweaks in this version:
1. Per Nostalgic's request, I have made it possible to escape the "wide" river room in Level 1. There is now a door in that room that you can use to exit if you get stuck there (see screenshot).
2. Per Nostalgic's request (and a poll which seems to confirm this would be a popular change), I have removed the light gray bars from the top and bottom of rooms.
3. Per Nathan Strum's comment that the zapper was getting stuck in walls, I have moved the location of the magnet so that it now appears starting in Level 2. The magnet can fish just about anything out of walls.
Keep the feedback coming!
Thanks,
--Will
-
I finally found the flashlight in level 3.
That's fun!Is it possible to throw the zapper up and down, in addition to just left and right?
Right now it's just left or right. Would adding up and down be a useful feature?
Also, can you make it so that the zapper doesn't get trapped irretrievably inside of walls? That gets pretty frustrating.
Yes. Stay tuned...
--Will
-
Funny thing is I never owned this game when Atari was in its heyday. Never even played it until the early 90's when I started collecting.
Same here... I never had a copy back in the day (and none of my friends did either), so the first time I played it was in an emulator in the 90s. It's super-addicting.
--Will
-
You know when, in Adventure, you're eaten by a dragon, then the bat picks up the dragon with you in it, and takes you on a tour of the kingdom? Back in the early '80s, I thought that was the coolest thing in the world.
The only problem was, while you could sometimes pick up the bat and move it around, it was difficult to really control where to go, especially at the edge of the screen. I thought the perfect addition to the game would be an object you could pick up that would let you float above the walls and explore the kingdom. So my first try at a hack, back in 2003 or so, was to add a hot-air balloon to the game. If you found the hot-air-balloon and pick it up, you could float above the walls.
While I was at it, I tweaked a couple of the room layouts and added a room in the white castle (it always bugged me that there was an "exit" in there that didn't lead anywhere.)
Now, this was back before I figured out how to actually assemble, so the changes I made were extremely tedious: instead of just disassembling, adding some code and reassembling it, I was actually using a hex editor to hack in the instructions using machine language (e.g. $4C $7E $F6 to jump to a patched-in subroutine).
So even though I came up with some more ideas after that (like having the dragons breathe fire at you; adding a shield the player could use to defend against the fire, adding a torch to see better in the catacombs), the idea of hacking in all those instructions, byte by byte, was so daunting I just shelved the idea.
I did submit the hot-air balloon hack here a few years ago, but I made a fairly dumb rookie mistake in making the hot-air balloon so darn hard to find that it wasn't obvious to a casual player that it was even in there.
So tonight I'm finally fixing that mistake. Attached is the new-and-improved Adventure hack, with a much easier-to-find hot-air balloon. Enjoy.
(On a related note, a few months ago, I figured out how to compile assembly, and wrote a whole new game to make use of the fire-breathing, shield and torch (flashlight now) ideas. Except they're fire-breathing ducks, instead of fire-breathing dragons. If you like this hack, you might like that game too.)
--Will
-
Hello everyone!
I wanted to get some feedback on a couple of aesthetic issues, and was also curious how far you've gotten in Duck Attack! if you've played it.
Here are the pictures the poll questions refer to.
--Will
-
I suggest using Stella in OpenGL mode with vsync enabled and phosphor mode turned off. On my system at least, this more accurately simulates what you'll see on a real system (a quite irritating flicker, in this case). The phosphor effect is really meant to make things nicer on a computer monitor, and it has no relation to how things look on a real system (ie, it makes things look better than they really are).
I meant to reply to this earlier... Thank you for that tip, I will give that a try. My development computer doesn't have OpenGL, unfortunately, so I'll have to find one that does.
--Will
-
Yes, that will be difficult with your kernel, particularly as you probably have to reposition both P0 and P1? This technique is used in the 24 character text routines, but the distance for repositioning is fixed. Is the sprite position for the fruit always the same? It might be possible to draw the fruit using a single sprite by hitting RESP0 mid line? In any case, your kernel looks very nice!
Chris
Thanks. The fruit/key/pill position does change between zones. Right now I'm doing all the repositioning in the 2-line gap between fruits.
The problem with firing RESP0 midline is that in about half the cases it's fruits + something else (keys, power pills, super pills), and I don't think there's enough time to both switch graphics and reposition. The super-pill line, for example, takes 72 cycles to do this:
1. Load fruit graphic/color into P0
2. Load pill graphic/color into P1
3. Load pill graphic/color into P0 (now that the P0 fruit has been written)
4. Set left vertical door color (on or off) in PF
4. Set right vertical door color (on or off) in PF
5. Restore normal maze color in PF
6. Load fruit graphic/color into P1
7. Increment/loop to step 1
Squeezing anything else in there will be tricky.
I may have to resign myself to making this an emulator-only game if non-interlaced 30Hz won't look decent on real hardware. Finding enough cycles to interlace might be beyond my programming capabilities. :/
--Will
-
Hello everyone!
Here's the latest version: v0.12.
This version has another feature for SaveKey and AtariVox users: a high score table. Now, whenever you finish a game, your score is automatically added to the high score table (if it's good enough, of course) and saved to the SaveKey or AtariVox. The high score screen appears after a game (once the "game over" screen disappears).
You can clear the high scores by holding the joystick "up" and pressing Reset while the high score screen is being displayed.
When a game is not being played, the program will loop through Title Screen > Demo > Game Over screen (last game's score and level reached) > High Score Screen > Title Screen. If you don't have a SaveKey or AtariVox, the High Score Screen will be skipped.
Another SaveKey-related change: the "save game state" feature is now invoked when you press the fire button in the credits room (previously it was the egg shelf room). Similarly, to load a saved game, press "reset" in the credits room. If the save or load is successful, you will be moved to the score room, if unsuccessful you will be moved to the egg shelf room.
In addition, all the game/score save/load screen rolls should be fixed: there shouldn't be a frame in the game that's not a constant 262 or 312 scanlines. Please let me know if you see otherwise.
I have a couple more tweaks and minor bug fixes to make, but that's probably it as far as major features are concerned. I have almost completely filled all 8 banks of the 32k, with just a handful of bytes free, and the remaining tweaks and fixes will probably use up the rest.
Enjoy! Let me know if you notice any bugs or have any other questions/comments.
Thanks,
--Will
-
I thought I'd make a feature request...
When Stella encounters an unknown ROM, I believe it performs some heuristics to determine the bank-switching method used.
Could it also perform some heuristics to determine what type of controller(s) should be used? For example, the presence of LDA/LDY/LDX INPT2 would suggest paddles, the presence of STA SWCHA would suggest a SaveKey, etc.
Ideally there could be a configuration option to turn off the heuristics and just assume joystick as it does now.
Thanks,
--Will
-
The best way to minimise the flicker is probably the venetian blind effect (drawing alternate rows on each frame), although it can be difficult to reduce the flicker this way. Reducing the luminance can help, but going below 30Hz is probably a bad idea. Have you got a Harmony cart to test on real hardware?
Chris
Hmm... would that even be possible with Super Pac-Man? I'm trying to think of how to reposition (for example) the P0 sprite from the arbitrary Blinky location to the fruit location and back within 2 lines. Are there any examples of games that do something similar? If so I can look through the debugger and see how they do it.
Unfortunately I don't have a Harmony cart yet... it's on my wishlist, though.
--Will
-
I played some rounds of Duck Attack over the past couple of weeks. I like the quirky story and characters and my fondness for the original Adventure helps me appreciate this game, its spiritual descendant, or perhaps a second cousin.
Here are some comments about the game. I hope that they help you out in developing future builds.
I like how within a few screens you can create the feeling of a large maze by placing walls strategically. However, the series of rooms with only exits at the top and bottom, doors, and walls that change color between rooms had a disquieting resemblance to Earthworld.
The robot sprite is a well-constructed figure. I like that the antenna, legs, and eyes all change when you change direction. I did notice that the antenna and boots are white during the game but black in the score screen, egg shelf, and credits screens. It took me a little while to figure out that collisions are only focused upon the robot's body. That would be a good tip for newer players.
Thanks for all the feedback! That's a good suggestion about the collision logic... I'll add that info to the manual. I'll also make a note in there that when the robot's antenna and boots are black, that means you're in a safe room, when you can rest without fear of any enemies coming along. (The actual reason they're black is so that I can use an all-black missile sprite on the right side of the screen to make those rooms symmetrical.)
The duck sprite is also impressive. I noticed there are different-colored ducks - will they have different names and personalities? I do think at times that the ducks are almost too large, since they can fill a quarter of a screen and there are some tight spaces to move through. However, I'm not sure you could shrink them vertically much and still have them look right.
I haven't named them, but they do have different personalities. Aside from having different vertical and horizontal speeds, they actually have different AI logic, although it's hard to notice in the game, since they just seem to come at you. I may add something about their personalities in the manual now that you mention it.
The robot also tends to get overly large when he is carrying two items, stacked one atop another. However, to have them side-by-side on the robot's head would require even more flicker, so I'm not sure if you'd want to do that.
Yep, they're stacked like that precisely to avoid adding flicker.
It confused me at first to see walls that change color when the robot moves! I eventually figured out that it's because the missile used as a wall has to be the same color as the player sprite, but someone not versed in 2600 technical issues might not know that. Maybe it can be explained away as a "mirror wall."
Good suggestion! I'm a big fan of fanciful explanations for technical limitations.
On level 1, even if you save yourself from the river, you may be stuck. If you go to the screen with the small river, then let it take you to the medium river, then escape, you're above a screen that has a barrier at the top. You won't be able to pass the barrier. On earlier levels it would be kinder to the player to not make such a deadly trap.
Yeah, I've gotten stuck there myself a few times. On the other hand, avoiding getting trapped is part of the challenge of the game... maybe I'll just stick a duck in there. I'll have to give that some thought.
I noticed in some rooms there's a light gray wall where colored barriers might appear, but the light gray wall is still passable. I think it would be better if these matched the color of the floor so that it's immediately apparent the robot can pass through. There shouldn't be a question as to whether you can go on to the next room.
Good suggestion... I may get rid of the light gray walls... they were originally a coding accident that I happened to like the look of, so I kept them, but I may drop them if they're confusing.
I finished level 2 by having the robot touch the black door with the black egg even though I couldn't move the robot to the door. (This is in the all-purple room with invisible walls.) Is this a good playing technique or something the level design shouldn't have allowed?
Yep, that's by design... I wanted to have it so when the robot held items, it extended its reach. Similarly if you have the zapper and something else, it will let you touch the outlet from a greater distance (at less risk of getting shocked.)
I saw that when there are a lot of objects flickering, it looks like the door sprite moves up and down by a pixel or two. I noticed this in a dark room when I wasn't carrying the flashlight and there was a snake and a door both in the room.
Good observation! Yep, that's because the object display logic cycles the player sprites as robot/snake, robot/door, door/snake. I may reverse that so that it's the snake that wiggles and not the door.
When the robot loses a life, it is immediately bounced back to the score screen, and you can start moving immediately after that. It would be better to have a bit of a transition, so the player doesn't start wondering why he is suddenly back at the score screen. Pausing for a couple of seconds on the screen in which the robot loses a life could help that. So could a death animation and having the player press the trigger to go back to the score screen.
I had originally designed a complicated "death animation" where the duck ate and swallowed the robot, but thought that it would irritate the player having to wait for it, so I dropped it. I know in (for example) arcade Donkey Kong, it is extremely frustrating for me whenever I lose a life because it won't let me jump back in there immediately.
When the robot is super-charged and/or shielded, in addition to changing the color of the body, I suggest having an icon at the bottom of the screen. This would make it so a player wouldn't have to remember what color body is associated with super-charging and shielding, as well as having both, and would help in cases in which another object overrides the color of the robot's body.
Interesting idea... unfortunately I probably don't have enough ROM left to squeeze that in.
There's good humor in here, with the punctuation marks above the angry duck and the homages to other games.
Thank you for including a manual with these early builds! For an adventure game this is particularly important, since it lets testers know how to use items, navigate, and so on.
This is a fun game and it will be interesting to see later builds and later levels. Please keep up the good work!
Thanks again for your feedback, you've given me a lot to consider!
--Will
-
hi e1will
the flicker is alot better. but I noticed after about a minute, I get this slow screen roll. and It repeats itself. I'm using stella 3.0
Is it rolling, or just flickering? If turning on phosphor mode makes it stop, it's probably the CPU not having enough cycles to update every frame.
--Will
-
It looks better than before, but it still rather flickery on a real TV. Also, I don't think you will be able to draw pac-man using the ball on the other rows?
Thanks for testing it out. My plan was to turn off PF0-2 in Frame 1 for the rows where the ball was enabled, and to possibly increase the luminance of those rows in Frame 2 to compensate somewhat (if I could find the cycles.) That would of course increase the flicker on those rows, but I wanted to get an idea if the "best-case" flicker was good enough before coding that, since there wouldn't be much point in coding it if even the best-case was unacceptable.
Do you know about the mid-kernel repositioning approach?
That looks very handy! I'll give that a try if the consensus is to go forward.
As best I can tell, the only way to further reduce flicker would be to run the Frame 1 logic on those rows where there isn't either a ghost or Pac-Man, and possibly tamp down the luminance on the fruits and doors that are being drawn on both frames. I wonder if that would be an improvement, or if it would be a more distracting visual artifact than a consistent 30Hz flicker on those elements?
--Will
-
OK, here's (I hope) an improved version. I've rewritten the kernel so that the blue maze does not flicker at all. The doors (and everything else) flicker at 30Hz. I've included screenshots of the 2 alternating frames.
Is this better? Worse? Better but still too flickery?
--Will
-
I just finished playing this. It's brilliant, but more than that, it's a re-imagining of Adventure with better graphics and slightly different play mechanics. There's so much about this game that's reminiscent of Adventure it's nuts, right down to the curlicue dead ends and the level design that defies the laws of space and physics. Look carefully at the mascot, too... underneath him is a simple dot, just like the one in Adventure. It even jitters a bit when you hug walls!
It's really well done, and I imagine these graphics would have been a massive challenge on the Atari 2600 hardware. Kudos!
Thanks! Yes, this was very much inspired by Adventure... it's long been my favorite 2600 game and I used to play it so often I'd actually dream about it.
--Will
-
Looks just like your screenshot on a real Atari.
The flicker is pretty bad though because it's the entire screen flickering.
Thanks for testing that. Yeah, that's what I was afraid of... I'll have to play around with the playfield drawing some more, it seems.
As for Lady Bug, the fact that JohnnyWC was able to pull it off so brilliantly for the 2600 is my main encouragement for thing Super Pac-Man might be possible too. But as you point out, getting colors that blend the way they need to is going to be mighty tricky.
--Will
-
1
-
-
Thanks. Good idea on the playfield... I may do that once I get the kernel straightened out. That may also enable a way to patch together up and down sprites with the ball sprite using an alternate frame/venetian blind approach for the left and right halves.
--Will
-
1
-
-
Hello,
I'm toying with the idea of writing a Super Pac-Man conversion for the 2600. Can someone with a Harmony cartridge or similar setup give this a test on real hardware and tell me how bad the flicker is? It looks OK in Stella if the phosphor effect is enabled (Alt-P) but it looks horrible if it isn't.
Also, I'm doing some funky things with HMOVE timings to cut down on the HMOVE bars so I'm curious if that breaks anything on a real 2600. Here's what it SHOULD look like...
--Will
-
2
-
-
I wonder if anyone would like to program three screens in ASM for me. I'd really like to appease people's want for a second score, but I don't know what to do. Even if I have a line counter and a score counter in one-player mode only, bB can't handle two scores, can it?
You may be able to get it to do that in bB (I don't know very much about bB) but you can definitely do it in assembly, with some flicker.
If you write Player 1's score and line count on the left in frame 1, then Player 2's score and line count on the right in frame 2, you could get something like this.
--Will
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Duck Attack! - new Atari 2600 homebrew (NTSC & PAL)
in Homebrew Discussion
Posted · Edited by e1will
Something like one of these? I tried a few different animations (well, just color changes) but I'm not sure which of these I like. What do you think?
--Will