Pacman - the Amiga conversion from the arcade game

[mcgeezer]

Originally Posted by jotd

okay, back to Pacman after all.

We'll see the AI later on.

Decided to go 100% asm. 4 planes.

1 plane for maze
1 plane for pacman using blitter (1 plane)
1 plane for dots
1 other plane (to be able to blit bonuses with proper colors)
sprites for ghosts (4 different color palettes preventing to use a sprite for pacman)

hoping to avoid double buffering and getting 50Hz with only 1 blit on 1 plane. That should be doable.

I'm not too concerned about the AI ATM.

Good stuff.

Can u not get away with only 3 bitplanes? 2 colours for the maze and dots, 1 for pacman and 4 for the fruits?

Defo possible without double buffering.

[jotd]

Maybe 3 planes if the colors of the fruits allow it. But anyway only the fruits will be blitted with full bitplanes, so 3 or 4 isn't going to make a big difference.

The sprite palette will have to change when the ghosts are iin "frightened" mode.

Also there isn't going to be needing to store the background, as the ghosts are sprites and pacman eats the dots. The beauty of it: the maze boundaries can have color 1, pacman can have color 2 and both can coexist on separate bitplanes without any interaction.

[jotd]

ok, worked a bit to produce some small proof of concept. Everyone knows that it's doable, but you still have to do it.



maze is one bitplane only
pacman has been drawn on another bitplane (only 1 bitplane is needed)
ghosts are sprites

using 16 colors but 32 with sprites. All sprite palette is used by all 4 ghosts, even if colors are repeated.

[jarre]

Originally Posted by jotd

ok, worked a bit to produce some small proof of concept. Everyone knows that it's doable, but you still have to do it.

Attachment 72760

maze is one bitplane only
pacman has been drawn on another bitplane (only 1 bitplane is needed)
ghosts are sprites

using 16 colors but 32 with sprites. All sprite palette is used by all 4 ghosts, even if colors are repeated.

i don't know much about converting, but it seems to me more easy to write a converter / resource / emaulator for all those Z80 arcade games, or is this a too simple thought and has it to do with resolution and add-on chips..??? i think once you know how the code must be translated to 68000 more and more z80 amiaga conversions can be released.???!!!! or maybe CPU power is the bottleneck...as is a z80 is max 8 mhz

[pink^abyss]

Originally Posted by jotd

ok, worked a bit to produce some small proof of concept. Everyone knows that it's doable, but you still have to do it.

Attachment 72760

maze is one bitplane only
pacman has been drawn on another bitplane (only 1 bitplane is needed)
ghosts are sprites

using 16 colors but 32 with sprites. All sprite palette is used by all 4 ghosts, even if colors are repeated.

Certainly the minimum use hardware resources

I once was tempted to remake it too. I planed a triple buffer 16 color screen (all assets are only 13 colors) and everything just BOBs for simplicity.

[saimon69]

Originally Posted by pink^abyss

Certainly the minimum use hardware resources

I once was tempted to remake it too. I planed a triple buffer 16 color screen (all assets are only 13 colors) and everything just BOBs for simplicity.

While jotd is doing the arcade pacman i can suggest to work on this bootleg-ish super variation of the original concept that came out in the half 90s

[ Show youtube player ]

or this pill free super fast indie variation
[ Show youtube player ]

[Havie]

Originally Posted by pink^abyss

Certainly the minimum use hardware resources

I once was tempted to remake it too. I planed a triple buffer 16 color screen (all assets are only 13 colors) and everything just BOBs for simplicity.

Agreed - I looked at Ms Pacman recently and noted that it only need 16 colours so with 4 ghosts, Ms Pacman and bonus (bounces around in Ms Pacman), 4 bitplanes is all that is needed and 6 blits maximum shouldn't tax any language.

Got as far as displaying the maze (double buffered) from tiles and started adding Ms Pacman but wasn't really a serious attempt (in Blitz).

[jotd]

I use a 1 bitplane bitmap of the maze (no tiles). I'm planning to use it for display collision as well, maybe as array of bytes, not bits.

And also use a table to compute sprite positions, but my calculations make it 256k of table data to cover most of X and Y range (0-255) and with 1 longword per position. Sounds a bit big for a precomputed table.

[jarre]

is the sega genesis/megadrive version "Better" than the amiga version..??? seems to me this is much easier to convert..???? that idea was in my mind for some time to look if someone can write a converter to get megadrive games on our amiga (except music). just read sega code and convert it to amiga code, start with a simple game and make it better everytime. So look in the code for joy moves, sounds, screen modes and convert it directly to amiga code. But hey, maybe i'm thinking to simple...

[jotd]

the CPU is really not the hardest part. Else we'd already have perfect X68000 conversions.

the custom chips are different, the image formats are different (sprites, bitplanes, interleaved) ...

[jarre]

Originally Posted by jotd

the CPU is really not the hardest part. Else we'd already have perfect X68000 conversions.

the custom chips are different, the image formats are different (sprites, bitplanes, interleaved) ...

Oke, seems my dream is gone… it seems too cool to convert games from Sega to Amiga….Sonic or herzog zwei on Amiga

[mcgeezer]

Originally Posted by jotd

I use a 1 bitplane bitmap of the maze (no tiles). I'm planning to use it for display collision as well, maybe as array of bytes, not bits.

And also use a table to compute sprite positions, but my calculations make it 256k of table data to cover most of X and Y range (0-255) and with 1 longword per position. Sounds a bit big for a precomputed table.

I have a table that is 2kb if you want it which covers 512x512 and sets up the control words for a defined y size sprite.

Let me know if u want it.

[jotd]

I'll take it. But explain me something: how can something like that can be so small?

512x512x4 = 1048576

2kb seems small.

[mcgeezer]

Originally Posted by jotd

I'll take it. But explain me something: how can something like that can be so small?

512x512x4 = 1048576

2kb seems small.

My apologies, it is 4kb.

So call this to build the tables, remember to set d4 accordingly (your sprites are probably 16 pixels high). Also, check the attach bit if you need it (see the or.w #$80 in the code)

; d4=Sprite size Y
agdBuildHardwareSpriteXY:
	moveq	#70-1,d4	; Set value for Y Size

        lea     HWSPR_TAB_XPOS,a0
        lea     HWSPR_TAB_YPOS,a1

        move.l  #512-1,d7
        moveq   #0,d0
        moveq   #0,d1
        moveq   #0,d2
        moveq   #0,d3

        moveq   #0,d6           ; counter

.loop:
        move.w  d6,d1           ; vstart
        move.w  d6,d2
        lsr.w   #8,d2
        and.w   #1,d2           ; vstart high bit
        lsl.w   #2,d2           ; into bit position 2
        and.w   #$ff,d1         ; vstart low bits
        lsl.w   #8,d1           ; Word 1
        move.w  d1,(a1)+        ; store SPRPOS word

        move.w  d6,d1           ; vstop
        move.w  d6,d3
        add.w   d4,d1		; Sprite size Y
        add.w   d4,d3
        lsr.w   #8,d3
        and.w   #1,d3           ; vstart high bit
        lsl.w   #1,d3           ; into bit position 2
        and.w   #$ff,d1         ; vstart low bits
        lsl.w   #8,d1           ; Word 1
        or.w    d2,d1
        or.w    d3,d1
        or.w    #$80,d1         ; set Attach bit (or not?)
        move.w  d1,(a1)+        ; store Y SPRCTL word
; Now do horizontal

        moveq   #0,d0
        moveq   #0,d1
        move.w  d6,d0
        move.w  d6,d1
        and.w   #1,d0
        lsr.w   #1,d1
        move.w  d1,(a0)+        ; Store Hstart High bits
        move.w  d0,(a0)+        ; Store Hstart Low bits

        addq.w  #1,d6
        dbf     d7,.loop
        rts

HWSPR_TAB_XPOS:	
	ds.l	512			

HWSPR_TAB_YPOS:
	ds.l	512

Then to get your control words out based on a co-ordinate into d2 use this.

;d0.w Xpos 
;d1.w Ypos 

        lea     HWSPR_TAB_YPOS,a2
	add.l	d1,d1
	add.l	d1,d1
        move.l  (a2,d1),d2
        lea     HWSPR_TAB_XPOS,a2
	add.l	d0,d0
	add.l	d0,d0
        or.l    (a2,d0),d2

Hope this helps! let me know if you have trouble.

Geezer

[jotd]

that's damn great. Thanks.

[jotd]

errr I'm not able to generate anything valid from this table.

If I hardcode a value I know that works like dc.w $3080,$4090 I get something (see attached pic)

If I put 10,10 I get 0A05 1900 from your table (with D4 = 17-1 = 16) and nothing is displayed.

Note that I have a macro that computes the pos which also doesn't work...

SPRITE_POS:MACRO
    DC.W ((\2&$FF)<<8)|(((\1-1)&$1FE)>>1)
    DC.W (((\2+\3)&$FF)<<8)|((\2&$100)>>6)|(((\2+\3)&$100)>>7)|((\1-1)&$1)
    ENDM

some page says you have to use X-1 and not X... whatever. It doesn't work either.

This is making me crazy. I made that work on a version of my Bagman game. But here no dice.

I found a thread where it was generated with assembler directly. Seems to work properly with that... go figure... http://eab.abime.net/showthread.php?t=81835

[mcgeezer]

Originally Posted by jotd

errr I'm not able to generate anything valid from this table.

If I hardcode a value I know that works like dc.w $3080,$4090 I get something (see attached pic)

If I put 10,10 I get 0A05 1900 from your table (with D4 = 17-1 = 16) and nothing is displayed.

Note that I have a macro that computes the pos which also doesn't work...

SPRITE_POS:MACRO
    DC.W ((\2&$FF)<<8)|(((\1-1)&$1FE)>>1)
    DC.W (((\2+\3)&$FF)<<8)|((\2&$100)>>6)|(((\2+\3)&$100)>>7)|((\1-1)&$1)
    ENDM

some page says you have to use X-1 and not X... whatever. It doesn't work either.

This is making me crazy. I made that work on a version of my Bagman game. But here no dice.

Did you try settinng a value of x=200 and y=200?

Remember anything below x axis 128 will probably be in the left border.

[jotd]

nevermind. With a REPT table I got it working. So I didn't use your table generation or mine or my macro (neither of those worked, the REPT table did...). Well I don't care now. It works, I'm not touching that again.

BTW I used something like this for the lookup

        lea     HWSPR_TAB_YPOS,a2
	add.w	d1,d1
	add.w  d1,d1
        move.l  (a2,d1),d2
        lea     HWSPR_TAB_XPOS,a2
	add.w	d0,d0
	add.w	d0,d0
        or.l    (a2,d0),d2

you don't need add.l, add.w does the job. And on 68020 you can use (a2,d0*4) instead (for your AGA games )

thanks for the help. I'll need more along the way I thought about clipping on the right when ghosts cross the tunnel. With bobs it's easy (BLTFWM) but with sprites it's more difficult. You can't even use a high priority black sprite since all 4 palettes are taken. I may have to provide 15 different shifted & clipped pics of ghosts sprites instead. Left and right makes 32 pics. Just for that.... and repeated 4 times since all ghosts can cross at the same time....

or use dual playfield just for that... could lead to more palette problems in the maze...

[mcgeezer]

Originally Posted by jotd

nevermind. With a REPT table I got it working. So I didn't use your table generation or mine or my macro (neither of those worked, the REPT table did...). Well I don't care now. It works, I'm not touching that again.

BTW I used something like this for the lookup

        lea     HWSPR_TAB_YPOS,a2
	add.w	d1,d1
	add.w  d1,d1
        move.l  (a2,d1),d2
        lea     HWSPR_TAB_XPOS,a2
	add.w	d0,d0
	add.w	d0,d0
        or.l    (a2,d0),d2

you don't need add.l, add.w does the job. And on 68020 you can use (a2,d0*4) instead (for your AGA games )

thanks for the help. I'll need more along the way I thought about clipping on the right when ghosts cross the tunnel. With bobs it's easy (BLTFWM) but with sprites it's more difficult. You can't even use a high priority black sprite since all 4 palettes are taken. I may have to provide 15 different shifted & clipped pics of ghosts sprites instead. Left and right makes 32 pics. Just for that.... and repeated 4 times since all ghosts can cross at the same time....

or use dual playfield just for that... could lead to more palette problems in the maze...

Indeed, it's built for 68000 and I know about the scalar stuff on 68020... I actually had to modify it.

I'm always wary of using any adding in data registers. I had a bug in Rygar for weeks due to it. My advice is when doing games make sure your adding Apples to Apples and not Apples to Oranges.

Glad you got it working though.

[jotd]

oh it seems we're going to be in the ports competition btw I decided to have a serious take on Pacman the day they announced it, and you started to work on KungFu master at the same time IIRC.