451 replies to this topic

[Nukey Shay]

Skip that one
Trying again...

Geez, if this keeps up, I'll just do a string of 16 comparisons!!

[Nukey Shay]

Nope...that didn't work either

How about this? What I did here was check for illegal movements (either X or Y should be in the middle of a corridor...if neither are, the program bumps up both). It does so "unintelligently"...so there is still the possibility of a monster going through a wall. But it will eventually correct itself, I hope...finding it's way back into a corridor. So if you see a monster suddenly jump to a spot, it happened.

Attached Files

•  hack_em_hanglyman.zip   4.91K   198 downloads

[SS]

Nukey Shay said:

So if you see a monster suddenly jump to a spot, it happened.

I saw what I think you're describing a couple of times. It wasn't exactly a "jump", however. More of a "stutter". It looked as if the ghost was going to get of track and then the program immediately corrected the problem and placed the ghost to where it should have been. Weird but it works.

[Nukey Shay]

I don't like it (because it's bad programming), but it seems to work. Now if I could just correct that timing issue

[Nukey Shay]

Haven't noticed any problems with them actually jumping -across- walls Anyone have?

Saved another 30 cycles here...chances of screen flicker should be a bit lower

Attached Files

•  hack_em_hanglyman.zip   4.91K   195 downloads

[SS]

Nukey Shay said:

Saved another 30 cycles here...chances of screen flicker should be a bit lower

It did. Down to only seeing them once or twice a game a game now. They're generally minor too.

Nukey Shay said:

Haven't noticed any problems with them actually jumping -across- walls  Anyone have?

I haven't seen any occurrences of the ghosts moving through walls. I caught sight of a couple of the "stutters" but they now seem to be happening when the ghosts are exiting the center box. I don't know if I'd even notice that it was happening if I didn't know to be looking for it. I haven't seen them do it in any other portion of the maze. I'd call this problem fixed.

- - - - -

On a side note, I FINALLY broke 100,000 on the game! 'Bout friggin time too, considering how much I've been playing it.

4th key maze and 114,300 points. Wahoo!

[Nukey Shay]

Not fixed...just fudged. The underlying problem as to why it happens is still there - I just can't find it.

Corrected a bug that kept the Galaxian+higher mazes from flashing (it would just stay light).

Attached Files

•  hack_em_hanglyman.zip   4.91K   226 downloads

[SS]

Nukey Shay said:

Corrected a bug that kept the Galaxian+higher mazes from flashing (it would just stay light).

OK, here's something new. I was on the 4th or 5th key level, the one where the energizers don't make the ghosts change but only make them reverse direction. When I ate the energizer, the maze suddenly switched to the green "+" color. It stayed green until the end of the round, flashed white and blue, and then started the next level blue. When I ate an energizer again, the same thing happened. I died this round, so I can't say for sure that the effect continued past this point. I also haven't gotten this far into the game before so I can't say if this is new to this build or if the bug fix is somehow related.

[Nukey Shay]

Yeah...the program is supposed to branch over if no bluetime exists (so the maze won't go dark in "plus" mode). I forgot to double-check for a regular blue maze game being played.

BTW thanks for all the playtesting

Attached Files

•  hack_em_hanglyman.zip   4.91K   184 downloads

[SS]

Nukey Shay said:

BTW thanks for all the playtesting

I gotta get out more.

[Nukey Shay]

Damn...now the maze won't go dark at all

[Nukey Shay]

Corrected

Attached Files

•  hack_em_hanglyman.zip   4.91K   248 downloads

[Nukey Shay]

I expanded the number of levels to 20**...and added a seperate bluetime table for the green maze (so that it matches closer to the arcade time). I dunno for sure, but I think that the fruit bluetime is slightly different than energizer bluetime in arcade Pac Plus. Anyone confirm this? In either case, this current program doesn't allow it.

**The 20th level is the 8th key. Not really necessary to go up to the 9th key, because monster attributes don't change in this hack anyway...just bluetimes.

Attached Files

•  hack_em_hanglyman.zip   4.91K   168 downloads

[Nukey Shay]

Trimmed out another 100 cycles...
The game used to adjust all 4 monster colors (to be blue or flashing) on every frame. Rather than do that, I cut it out of the main loop and just did one monster per frame. This won't affect gameplay at all (when energizers are hit, they will still all turn blue...and when it runs out, they will still all change back). You shouldn't even notice a difference unless you pause the game just when they are flashing white.

Attached Files

•  hack_em_hanglyman.zip   4.91K   194 downloads

[Nukey Shay]

Dropped the collision detection down to 25% again
I also made some changes to the boot screen...does this fix the startup roll? At the point of jumping out of that screen, it was outputting 275 scanlines. By changing the jump destination, it now looks to be steady (261 on the boot screen, 262 for everything else).

Attached Files

•  hack_em_hanglyman.zip   4.91K   163 downloads

[Retrofan]

if the game has an uneven number of scanlines it do not run in color on PAL (60) TVs in Europe, or does it?

[Nukey Shay]

I dunno anything about what PAL "forgives"...but the game itself appears to be running at a constant 262 scanlines...just the boot screen is at 261. If this causes a problem, I could reduce the boot screen to a lower number. If rolls are still present during the game, I suppose I could reduce the lower characters to 5 scanlines instead of 7 (the extra men + the board fruit indicator). The score font is as small as I'd care to make it already

[PacManPlus]

Hey Nukey:

The 'Fruit' Blue time in Pac Man Plus is different than the power pellet times.After you get to the board that is the equivalent of the 4th key (the first level where they don't turn blue at all, which in Plus is the third pancake), the fruit still makes them turn blue. It's a number of boards later where nothing (fruit or energizers) make them turn blue. I have included an input file (for use with MAME .56) where I get pretty far on it. This (hopefully) should show you when you need to see)

Hope this helps!

Attached Files

•  pmp.zip   25.06K   158 downloads

[Nukey Shay]

I thought it was. In any case, this program won't allow it (unless I added a seperate routine for the fruits only - and that would take more romspace than I have).

Tried something different here...I lowered the number of lines required by the fruits to be 6 instead of 7...this change allowed me to bump up the delay counter for the 2nd bank twice. Bumps should be virtually unseen, I hope. Number of scanlines shows a steady 262 including the boot screen.

Attached Thumbnails

• 

Attached Files

•  hack_em_hanglyman.zip   4.9K   175 downloads

[Nukey Shay]

I found out that there was a real possibility of the game bankswitching in the middle of the program...or being stuck in 1 routine for 256 loops (that might explain why some frames used an inordinate amount of cycle time when others didn't). The rom posted above might crash out when monsters are having trouble "deciding" which way to move next. I corrected that problem here (I think):

       and    #$03         ;2 use the accumulator...

       tay                 ;2 ...to set a "random" value for Y

MoveAngle:

       sty    PrintTemp+11 ;3 ...and store it temporarily


;Note: possible bankswitch if Y > $D4!

       lda    Bit_chk_5,y  ;4 note: Y must be 0-5 only



       clc                 ;2 

       adc    MonsterDirs  ;3 add a bit of "randomness"

       and    #$03         ;2 keep only the lowest bits

       jsr    CheckDirA    ;6 check if valid move

       bcs    NewDir       ;2 branch (keep the move)

       ldy    PrintTemp+11 ;3 otherwise, try again

       iny                 ;2 Y always 0-5?


;old branch:
;       bne    MoveAngle    ;2 possible to loop 255 times!
;bugfixed branch:

       cpy    #$05         ;2 

       bcc    MoveAngle    ;2 branch if 5 or less only

The table Bit_chk_5 is only 6 bytes long...and was located in the last page of rom. So if the Y counter got too high, it would attempt to read past $FFF7 (which the 2600 would interpret as a bankswitch instruction)...placing it in the middle of bank 1. In the bugfix, I just made sure that Y was never allowed to go higher than 5 in the loop.

I sure hope that this was the cause of those rolls!

Attached Files

•  hack_em_hanglyman.zip   4.9K   196 downloads

[atwwong]

Hi Nukey! It's still doing a bit of the halo and rolling, but it's less noticeable than before. I'm counting 32 bin's plus the source code. Must be some kind of record!

[Nukey Shay]

Nothing I can do about the halos (because I needed 2 cycles to implement indirect jumping - essential to be able to fit in 3 mazes)...but I trimmed out a bunch of cycles from the score display...and swapped a bit of extra time in bank1 to bank2. Any rolls here?

Attached Files

•  hack_em_hanglyman.zip   4.9K   162 downloads

[SS]

Nukey Shay said:

Any rolls here?

Jeez, Nukey, you are hard to keep up with!

Give me a couple of minutes to eat my dinner and I'll give it a spin. I just finished testing the 8/16 version. The rolls are very minor on that one.

9th key and 124,420 pts, BTW.

[Nukey Shay]

After a few games, I got a flicker when playing "smart" monsters (the routine takes just a bit longer when they are actively hunting the player). I didn't notice any when playing with random monsters

Little more trimmin' to do

[Nukey Shay]

Added some more redundancy (rather than using generic routines).
Last one for the night...getting really close now

Attached Files

•  hack_em_hanglyman.zip   4.9K   187 downloads