Nukey Shay Posted August 25, 2004 Author Share Posted August 25, 2004 The answer is that it's not playing the same way that it was at a faster pace...it's moving the player 2 pixels at a time at the same pace (that's why it's not as smooth). So all I needed to do was change the 4 routines for each of the directions... ldy #<Pacright;2 load "right" sprite inx ;2 move player right ;added bit DifSw ;3 check difficulty switches bmi Slow1 ;2 if R switch is "Expert", branch inx ;2 move player right again Slow1: Once all of those were in place, I removed the branch that forced the game to update on every frame...and just used part of the same conditions that exist for the slow game - read the stick and move 3 out of 4 frames, and check for all collisions on the remaining frame (the difference being that the player doesn't slow down when eating dots in the fast game). Since in the worst case the player can be 6 pixels from a monster before collisions are checked, the possibility of moving through a monster still exists in the fast game (in the slow game, the player only has a 3-pixel "safety" zone, or 2 pixels when eating dots...so collisions are more accurate). Quote Link to comment Share on other sites More sharing options...
SS Posted August 26, 2004 Share Posted August 26, 2004 Does the motion look too jerky in the fast game? Not at all. I played this one back to back with yesterday's version and can't say that I see any really noteworthy differences at all. More importantly, the screen jumps seem to be pretty much gone. They are completely non-existent in relationship to the "GO". I played three fast/smart games (up through the bell or key levels) and maybe one or two tiny jumps each time. I'd say that this is easily the best build yet. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 26, 2004 Author Share Posted August 26, 2004 Cool...that was definately the culprit then - using too much time by checking collisions on movement frames. Sounds like I just need to cut a very small amount more. A couple of slight changes... The game select now allows you to go up to the 10th key so I could add correct bluetimes for all boards (& fruits in the plus version). In the arcade game, the difficulty stops being adjusted on key#9...I made it #10 so that Hangly Man will flip boards correctly (when you beat #10, it goes back to #9...both #9 & #10 have the same difficulty). In order to squeeze this in in one area, I had to rob a byte (which is why on the Hangly Man boards, there is a pixel missing from the lower corner). When using the game reset button, the logo will appear first as you flip the switch instead of the score. When monsters are in the box during bluetime, their "wait" value has been lowered. This seems to be consistant with the arcade game...which bumps the monsters out frequently when they are blue...and help insure that a monster (particularly the brown one) won't be stuck in the box when bluetime begins just when it's due to leave. The death sound data table (53 bytes) has been eliminated and changed into a routine (13 bytes). Sounds virtually the same except for the "thud" that was in the old version. The fruit and monster eaten sounds have been stretched a bit...and the bonus player beeper has been reduced. This helps the sounds match up better if the game is paused due to a monster being eaten when the beeper plays...and helps it "feel" less distracting due to differing pause times. hack_em_.zip Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 26, 2004 Author Share Posted August 26, 2004 BTW there's only a few cycles' difference between this one and the last one...so any jitters in the previous version will still be there Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 26, 2004 Author Share Posted August 26, 2004 Going back over the display kernal again, I found what appears to be an unnecessary HMOVE line just above the extra players/lower fruit display. I eliminated that. In addition, each of the 3 screens were loading absolute values not indexed from the maze data to create the upper line of the playfield...during periods that monsters existed in the upper row. I just changed those to immediate values (which were already being used). In short, I saved enough kernal time to be able to eliminate one blank scanline just above the maze, and bump up the time available to the program. That should fix any bumps Note: because these values are being reused from other data, the player's sprite is a bit duller in hue (changed from color $1A to $EA...in order to use that "E" to create the edge of the maze as well)...and when a monster is in the upper row, the maze color comes just a bit too late (so a part of the first corner pixel may disappear). The time savings made these small glitches acceptable tradeoffs Also, I changed the very end of the death sound. Trying to get the "wa-wop" sound And the fruit sound is now closer to the real thing. 64 bytes free hack_em_.zip Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 26, 2004 Author Share Posted August 26, 2004 Forgot to mention... Eating dots now only slows you down half as much in the slow game (1 frame dropped out of 8 movement frames). This appears to be closer to the arcade as well. 1 out of 4 was a bit too slow. Quote Link to comment Share on other sites More sharing options...
SS Posted August 27, 2004 Share Posted August 27, 2004 That should fix any bumps I must be in slow-mo tonight because I couldn't get past the bell level in ant of the three games I played (fast/smart). Still, I don't think that I saw even one small screen jump at all! And the fruit sound is now closer to the real thing. Sweet! Quote Link to comment Share on other sites More sharing options...
SS Posted August 27, 2004 Share Posted August 27, 2004 Got up through the 3rd key this time. Still haven't seen any screen jumps! Quote Link to comment Share on other sites More sharing options...
Pixellated Ghost Posted August 27, 2004 Share Posted August 27, 2004 Wow, I died in a cheap way... was playing hackem 2 and followed a ghost rather closely when I went to get the orange. Ate it, that ghost was the only one that didn't turn blue. It reversed direction and nailed me. Haven't seen anything screwy aside from some really minor graphic glitches. So far the apple level is the best I can do. I'll probably get better at it once I can play it on full hardware. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 27, 2004 Author Share Posted August 27, 2004 Yeah, it's risky to be following the monsters if there's a chance that they won't change. The real game also features monsters that will double-back on you, but I've had problems getting that in. What graphic glitches? The "halos" above monsters? Nothing I can see to get rid of those, I'm afraid (short of expanding the game to 16k so that the kernal can be unrolled). I could -almost- reuse the data sent for the edge dot info...which would leave just a tiny dot above monsters that are moving in just a few lines (the rows that feature dots on the outer edge of the maze). This would be worse than it already is IMO...since at least the halos aren't always there. With the current time savings, the jitters should be non-existant...or at least I hope so. No other big gainers that I can find to increase available cycle time (short of reducing the size of fruits or the score....those are already at 6 and 5 lines (kind of the minimum to keep them recognisable). A few more tweaks here... hack_em_.zip Quote Link to comment Share on other sites More sharing options...
WildBillTX Posted August 27, 2004 Share Posted August 27, 2004 It's better at fast mode since your updated roms yesterday - I only had one blue monster pass through. Anyone playing this on a Supercharger? I also played the original Pac-Man on Mame and noticed there's about a half second delay before the dying sound and death animation after Pac collides with a monster. Too late/complex or not enough space to work that in? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 27, 2004 Author Share Posted August 27, 2004 Sort of. I'd need some other way of keeping track of time. Right now, the pauses work by having something in the sound table counter. I still have a few spare bits of ram in the #lives counter...so I could use one of those. Right now, the program has the "inactive game" value being sent the moment a collision occurs. Rather than do that, I could: Collision -> flip an unused bit & reset the timer. During the program...bit flipped = all motion and sound paused. Timer reaches zero again -> flip the bit back and then send the "inactive game" value. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 27, 2004 Author Share Posted August 27, 2004 Here's that routine... hack_em_.zip Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 27, 2004 Author Share Posted August 27, 2004 Oops...that wrecks havok with eating a monster Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 27, 2004 Author Share Posted August 27, 2004 Fixed: hack_em_.zip Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 27, 2004 Author Share Posted August 27, 2004 Current source code... hack_em__source_.zip Quote Link to comment Share on other sites More sharing options...
SS Posted August 28, 2004 Share Posted August 28, 2004 Fixed: Fast/smart; 5th key. The slight pause between the character death and the death-sound seems to be working well. Still not seeing any screen jumps. Don't have any issues to report back about at all, in fact! Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 28, 2004 Author Share Posted August 28, 2004 Excellent...I'm working at getting the intermissions a bit more polished Quote Link to comment Share on other sites More sharing options...
SS Posted August 28, 2004 Share Posted August 28, 2004 Excellent...I'm working at getting the intermissions a bit more polished I wasn't gonna mention it but since you brought the subject up ... :wink: The blue ghost on the first intermission is really dark. It's not so much of an issue on Z26 but it is awfully hard to see on my TV. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 28, 2004 Author Share Posted August 28, 2004 There's a number of things that I ended up doing differently in the game vs. the intermissions (which have been virtually unchanged since I threw them together). The monster colors used to be darker Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted August 28, 2004 Share Posted August 28, 2004 Hi Nukey I had something happen to me on two different emulators... being that nobody else brought it up I thought it might have been what I was playing it on... Starting the first board on Hack'Em (Blue) - both difficulty switches set to 'b' - when I ate the fruit, I stopped dead. One time I was able to eventually move again, another time I wasn't (probably because the monster got to me before I could). I can get it to happen almost every time. As soon as you load the rom, start a game without changing any levels/game type. It should happen the first time you eat a fruit. Hope this helps Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 28, 2004 Author Share Posted August 28, 2004 I always hold the stick in the direction I'm moving (which I try not to do in public BTW), so I never noticed it. Thanks for the info! Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 28, 2004 Author Share Posted August 28, 2004 Corrected... (141 bytes free) hack_em_.zip Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted August 28, 2004 Author Share Posted August 28, 2004 It's better at fast mode since your updated roms yesterday - I only had one blue monster pass through. Anyone playing this on a Supercharger? The fast game is using the same collision detection scheme as the slow game now. The only risk of moving through a monster should be in the tunnel or trying to eat monsters that are really close together (once a collision is found with one monster, the program skips over checking any more for that frame). I'm not sure if I can correct the tunnel problem...since you are moving 2 pixels in the fast mode, the player might jump over to the opposite side just as a monster is going to opposite way - missing out on colliding. Chances of this happening are pretty minimal tho. BTW it's an 8k game...so it won't work with a Supercharger Quote Link to comment Share on other sites More sharing options...
PacManPlus Posted August 28, 2004 Share Posted August 28, 2004 Very Cool Nukey One final thing before I shut up... In Pac-Man Plus, the fruit will always turn all four monsters blue and never make the maze disappear. It doesn't have the same effects as the power pellets in that respect. The monsters are the only things that disappear (or no color) from the fruit when it is eaten. Is that possible here? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.