Ms Pacman
 

I was surprised that there is no Ms Pacman port for the Amiga. (or that I totally missed it?)

And then, I started wondering, what it would need if you were to try to port it.

Levels (excluding, lines of text on top for score/hiscore and bottom number of lives and fruit level) are with width 224 and height 248.

Levels (excluding the ghosts' house door-line) are with three colors+black. Two colors for walls, one for dots/superdot and black. So, four in total. 2 bitplanes.

Game sprites are 16x16 which can comfortably be addressed with hardware sprites. 1 for MsPacman + 4 ghosts + 1 for ghost scores (200,400,800,1600) which stay for a little when you eat a ghost. Probably would be easier to have that line on ghost's house as a sprite as well. 6 so far. 1 more for the fruit. 7. Might need one for the fruit's score when you eat it. 8.

So all is plain and simple. Let's go to the hard parts now.

I'll start with the most difficult one. How to make ghosts behave _exactly_ like the original? I don't see any other way than studying the disassembly of the original. (z80) This is _very_ critical. Fans of the game wouldn't consider a game with altered behavior. It wouldn't be a port. Just some random pacman.

Problem number two. The original plays at 60Hz. Pal amigas are at 50Hz. I read that Ms Pacman moves a pixel every 1/60th of a sec. So, 60 pixels per second. Pal would give 50 pixels per second smoothly. (-16.67% speed) Not good. I guess one could have timer interrupts at 60Hz (or each 5 vblanks call update_game() two times) and the screen at 50Hz would have some hiccups on the smoothness of motion. Not good. Ntsc amigas would be ok, but then can you have 248 height even with overscan on Ntsc amiga? And what to do with Pal?

Problem number three. Aspect ratio. So, the levels are 224x248 and can be placed within 320x256 but the aspect ratio is horribly wrong. Feels like the level is wider than it is taller and should be the other way around. Could go for 640x256, but that would leave almost two thirds of the width unutilised for the level.


Thoughts?

Yeah, without the game logic, the game is nothing. You'd need to reverse engineer it or be very good at replicating. This should be the #1 thing to get right . everything else is secondary.

As for 50/60 Hz, any Amiga with a Fat Agnus or above can do 50 and 60 Hz. Limiting the game to 60Hz is not a bad idea. Dynablaster does this.

This disassembly of Ms. Pac-Man has quite detailed comments:
http://umlautllama.com/projects/pacdocs/mspac/mspac.asm

I looked at the disassembled code for the Sega Genesis and that wasn't very helpful.

The task of creating an Amiga version would quite similar to what the original Ms. Pac-Man engineers did -- they reversed engineered Pac-Man to create this game.

I confirm that you have to get everything right or this won't feel right (speed, A.I.). Not only the graphics.

I love those projects. I remade "Bagman" (another Z80 game) by reverse engineering it. And the result is very satisfactory because the A.I and the speed of the characters match.

A shame no-one ever ported those gems at the time (Moon Patrol, PacMan, Galaga) because they would have been perfect on the miggy.
Publishers were interested in "newer" games, which were a lot more difficult to port right. Only a few were successful, the rest was ... US Gold :)

Taking problems two and three first...

I don't think the difference between 50 and 60fps would be a big deal when the Amiga game is played in isolation. Someone can correct me if i'm wrong but I think i'm right in saying that most(?) Mega Drive and SNES games run at different speeds on PAL and NTSC. But if you've only played on one system and have never experienced the other, you're not missing anything.

If you're sticking to PAL and OCS, you could tune the speed of the enemies so they move slightly more than one pixel per frame using a fractional part added to their screen coordinate. That way they will move the same distance over a second, let's say, but then you impair the game's smoothness as every so often it will have to move something two pixels over one frame. Not a huge deal, but certainly noticable.

Taking a quick look in MAME, the game's play area is 224x248 which isn't so bad. I'd just move the score text to the side, instead of up top and bottom.

A bit like this...

http://eab.abime.net/picture.php?alb...pictureid=3078

Problem one, however, is something i'm a bit stuck on myself. At least as far as my own game programming effort is concerned...

Very true. And, if I can ever get Bombjack finished, i'd like to have a crack at something like that. :cool

B

This isn't the best way to handle it I think. Remember you have the same set of 4 colors for each pair of sprites (3+1).... each ghost in Ms Pacman has 3 colours (Main color, blue and white for eyes).. none of them match with the colors of Ms. Pacman. You could use one of the sprites channel with matching colors for fruits, but then some fruits have green on them and none of the ghosts have green.

Also, I see no reason to make that line in the "Ghost Castle" a sprite since it has the same priority as the dots. Also, sprite with sprite collision is kinda messy on amiga, each sprite channel make collisions shared, so if you check a colision against sprite 0 you are also checking against sprite 1, unless you do it "manually" (i.e. check by position instead of sprites overlapping).

I'd use sprites 0, 2, 4 and 6 for the ghosts... change their pallete when they are scared and it works pretty well. Ms Pacman, fruit and all dots (including blinking ones) are Bobs. You'd have at most 6 16x16 updating bobs on screen (with no need to redraw background except with the fruit since they are always black... this actually can make erasing the dots "automatic" since when you erase Ms.Pacman bob to redraw it at other place you also erase the dot underneath it). Using sprites just for the ghosts you can basically test sprite collision against unique Ms.Pacman color and it will be fair.

Yeah, you'd need 3 bitplanes for that but, honestly, you can even use 4 bitplanes to get all fruits color 100% accurate if you want it, add some color to the game and it still would be fine. Heck, you could even use dual-playfield and add some background to the game if you want it :D

And move the score/lives panel to the side would work wonderfully for the resolution problem, it's how it was done in most of the 8 bits conversions of Pacman / Ms.Pacman anyway :) It fits nicely.

EDIT: No need for extra sprite to show score when eating ghost either. The game freezes and both Ms. Pacman and the eaten ghost dissapear while the game is frozen and the score is only shown while the game is frozen. So you can either use the same sprite channel of the ghost or just blit the score at the screen and delete it when the game resumes.

About Pacman, check Pucman a nice shareware pacman clone for the miggy. Looks really neat

http://hol.abime.net/1174

@Old Bob I did the same "move the score trick" in my Bagman remake. And check Elite "effort" on Bombjack! what a waste...

Attachment 54080

I had it finished, but that was slightly easier to do: using C++ & SDL on a "modern" PC gives a perfect rendering. I tried to port it on amiga, and it was darn slow even on a 68060. Probably runs ok on Vampire but what a waste. Dropping SDL is then a big step ahead in trouble, doing it old-style in assembly with blitter (maybe now with modern gcc it would be fast enough to use C++ code).

I really wonder how hard it would be to drop SDL for hardware banging but keep C++ code with all the A.I. etc, and how fast it would be. Not a job for me as I don't know enough about blitter & sprites & audio on the miggy.

Those kind of projects are unlikely to be a one-man job. One has to resource/code the exact behaviour of the arcade game (Mrs Pacman uses random for Ghost moves, even in "chase" mode, Pacman doesn't, only uses random when ghosts are scared BTW), and one has to code using the most efficient method on the miggy.

I know about Codetapper trying to re-code Gyruss old-style for ages... Lots of projects, but very rare complete releases (maybe Rygar?).

Yep, the port that Elite released is nothing short of a disgrace. My own early efforts show that an A500 is easily capable of an almost perfect reproduction of the coin-op. As soon as I can figure out how to control that damned mechanical bird. Much like the Pacman ghosts, it's central to how the game plays but i'm damned if I know what that code looks like.

I'll get back to you on that... :spin

Having a brief look in MAME, it seems like something that an A500 should be able to do without too much trouble. I've got no idea at all about this mysterious SDL, C++ business but a mixed code sort of thing where you could call asm routines controlling the blitter and stuff might be possible?

Indeed. As it quickly became apparent to me when hacking away at even a fairly simple game like Bombjack, beyond the merely mechanical aspects of getting the graphics engine going and stuff, there is a order of magnitude more work in doing everything else.

B

Sooo to sum it up: the status on your Bombjack clone is

running on A500 with correct framerate but
not able to figure out how enemies move. Right?

would reverse engineering the original Z80 game help?

SDL is a system where you're drawing the whole screen, then it's refreshed. On a PC it's not an issue, but it's too much effort for an amiga. Most emulators are built by refreshing the whole screen, which is too slow for our beloved machine (I had written an emulator a long time ago, and it had to use "dirty" zones to only refresh what had changed, a bit of a nightmare...)

I wonder if it would be possible to reuse the existing C++ code, but use custom blitter code for displaying gfx & playing audio, so it would run on maybe not A500 but A1200.

For Bagman (note: exists on the miggy as "Bagitman" but with inferior C64-like graphics), that would mean not blitting the background everytime (using sprites for characters would be doable since they're small) and using the blitter only for objects.

Yep. I haven't intergrated the enemies in to the engine yet, but test programs reveal that 50fps should be easily attainable with everything going. The A500 blitter can cope with pretty much twice the amount of stuff that the coin-op has going at its busiest periods. Even using ZX Spectrum style, CPU based sprite routines would, I think, be fast enough.

Exactly why Elite's version runs like a lethargic snail, is a complete mystery to me. Except to point out that the ST version seems more or less identical, albeit quite a bit faster. I propose that we may simply put this down to the usual reason when it comes to this sort of thing... :mad

I've uploaded my current WIP to The Zone.

Sure, that would be a huge help. :cool

This sounds incredibly wasteful. If you've got 4000mhz worth of CPU to throw at it, I guess it's no big deal, but a selective screen refresh and double buffer approach would be far more efficient. And, I guess, easily within the Amiga blitter's abilities.

As far as anything C, or C++ goes, i'm not the person to ask, sorry. But I guess it sounds reasonable? Anybody else with more knowledge than me care to comment?

B

@Old_Bob
In the Zone you can find arcade bomb jack disasm which I found somewhere on internet. I don't remember when I found it. Should be helpful.

Asman, looks like a lot of work is already done. Very interesting.

Doesn't mean it's going to be easy to figure out how the bird moves.

I found this on youtube yesterday.

https://www.youtube.com/watch?v=ZMnMMxqHN-E

Trully awfull ports.(with the exception of c64 and atari 7800 maybe)
I mean, cover your ears in AppleII's port.

Also, this looks very well documented
[z80 disassem]
https://github.com/BleuLlama/GameDoc...mble/mspac.asm

Thanks, dude. :great

Agreed. Even with the work that's already been put in to the disassembly, it's still a huge task.

B

Now, that's a bit more like it. :)

B

https://github.com/BleuLlama/GameDoc...spac.asm#L8000

;; #2a23 random number generator, only active when ghosts are blue.
;; n=(n*5+1) && #1fff. n is used as an address to read a byte from a rom.
;; #4dc9, #4dca=n and a=rnd number. n is reset to 0 at #26a9 when you die,
;; start of first level, end of every level. Later a is anded with 3.

They REALLY didn't want anything portable ;)

That looks like a newer version of the disassembly that I posted earlier.

Code a Z80-emulator, that will take care of the logic. Rewrite graphics-related parts to be more Amiga-specific.
Probably easier said that coded. :)

oRBIT: what I did to emulate Oric games was to disassemble 6502 code and transform it so it's legal C language (with macros for the opcodes). Then compile, debug, add real C wherever you need.

The same trick can apply to convert to 68000 asm of course. (for some parts it's even simpler)

Works very well. I have adapted 4 or 5 games like this (pure asm) for windows. But that's more emulator-like, and you still have graphical refresh issues.