Idea for homebrew title that 7800-homebrew dev. may consider to produce: Pac Land 1984

[TIX]

3 hours ago, Synthpopalooza said:

Also to me, 16x16 is a non-starter.  He looks like a pancake.  ?  24 or 32 high is best.

I just played C64 version and it's uglier than I remembered..

Pacman is restricted to a small 12x21 square with very small feet and no hop in his stride..

 

Edited October 2, 2019 by TIX

[Giles N]

So here is anyway a go at PacMan 16x16:

 

 

 

Edited October 2, 2019 by Giles N

[Giles N]

ahem...
 

[Roy]

You could take it a step further and make both the eyes and hat separate sprites to mimic what is displayed in the arcade game. The eyes would be drawn last to overlay any foreground graphics.

[Giles N]

1 hour ago, Roy said:

You could take it a step further and make both the eyes and hat separate sprites to mimic what is displayed in the arcade game. The eyes would be drawn last to overlay any foreground graphics.

Thanks, I’m going for ‘minimalism’ first: as small as 16x16 and only three colours.

 

The other graphics provided here are already very good: the 32x32 almost arcade perfect, so I just want to experiment with lower-performance need-sprites.

 

But I appreciate input and interest!

[Giles N]

Problems with posting videos... hmm..

 

 

Edited October 3, 2019 by Giles N

[Giles N]

 

[Giles N]

 

[Giles N]

 

[Giles N]

8 hours ago, Synthpopalooza said:

Also to me, 16x16 is a non-starter.  He looks like a pancake.  ?  24 or 32 high is best.

How would different sprite-sizes impact the performance of the game, as to processing power?

[Synthpopalooza]

I'm not a pro by any means when it comes to programming for the MARIA chip ... but here's what I do know.

 

Sprite size isn't as big of an issue really as much as making sure you don't display too much on one scanline.  You can always doublebuffer the screen if you run out of render time, but it will make the screen jerk.

 

160A only allows for 4 colors, but allows for more render time.  160B has 12 colors per sprite, but eats up more real estate with MARIA.

 

I had to figure this out on my own when I went to programming my first game on the 7800 (a project that is actually still in the works).  It's ok to try with minimalism ... but don't be afraid to stretch a few limits too to see what can be done.

[TIX]

6 hours ago, Giles N said:

ahem...
 

not bad,

but try the same with wide pixels and you got instant pancake

look at my 16x16 (pancake) example with square pixels instead.. looks good !

 

Edited October 3, 2019 by TIX

[Giles N]

 

Ok, so I tried to ‘thin him out’ a bit^

 

(and I keep learning, which is important to me).

Edited October 3, 2019 by Giles N

[Synthpopalooza]

Which software do you use?

[Giles N]

17 hours ago, Synthpopalooza said:

I'm not a pro by any means when it comes to programming for the MARIA chip ... but here's what I do know.

 

Sprite size isn't as big of an issue really as much as making sure you don't display too much on one scanline.  You can always doublebuffer the screen if you run out of render time, but it will make the screen jerk.

 

160A only allows for 4 colors, but allows for more render time.  160B has 12 colors per sprite, but eats up more real estate with MARIA.

 

I had to figure this out on my own when I went to programming my first game on the 7800 (a project that is actually still in the works).  It's ok to try with minimalism ... but don't be afraid to stretch a few limits too to see what can be done.

Would you say there are some typical thumb of rules(besides the above)?

 

For example 

- sizes of sprites that often used in certain genres of games?

- limited number of 32x32 objects,

- if parallax-effects are to be used on the background, does either number of sprites, types of sprite-set (a or b), number of colors used to draw background come into question?

 

Or do ‘platformer typically’ use two 16x16 sprites on top of each other)?

 

All such stuff is of interest.

 

Anyway, thanks for the info you’ve shared already.

Edited October 3, 2019 by Giles N

[Giles N]

1 hour ago, Synthpopalooza said:

Which software do you use?

Right now I only want to ‘get started’, and create template-grfx in grids.

 

I use Apps in ios.

 

None of my things here are from any 7800-emulator, only from ios-Apps.

 

This is where I thought it easiest to start.

 

And having them in grids, I can ol’ school-like, implement the pixels into 7800-painting/drawing program later.

 

But TIX is the pro here.

 

I only wanted to contribute actively, not just whine around.

 

—

And I also thought; why not play around with these things at idea-stage...?

 

If the 7800 is powerful to do main-objects in 32x32 and all, and we have here, - in the process - also been through lots of 16x16, 3 color takes, perhaps, who knows, if some 5200-programmer would like to have a go at an installment on that system?

Edited October 3, 2019 by Giles N

[Jaden (JRH)]

Honestly, a Pac-Land homebrew would be fantastic on 7800. That was what should have been the pack in game for the system. I do have some programming knowledge and I have 7800Basic. So, I would love to help with this homebrew project if I could.

[Synthpopalooza]

The more hands the merrier.  I will keep working up the music then ... still got some ideas.

 

Next pieces will be the homeward theme, and the castle music.

Edited October 3, 2019 by Synthpopalooza

[Jaden (JRH)]

I'd like to help with graphics if that's cool.

[Synthpopalooza]

Sure.  There was a sprite resource up in the thread ...

[Giles N]

1 hour ago, Jaden (JRH) said:

I'd like to help with graphics if that's cool.

 

 

Edited October 4, 2019 by Giles N

[Jaden (JRH)]

I drew up some sprites in Atari Dev Studio. I don't know how helpful these are, since they're just items. But hopefully these will help out. And I'm definitely open to doing more sprites for the games. Maybe I could even draw backgrounds. All of these sprites are 12 by 12 and use 3 colors.

strawberry.spe cherry.spe melon.spe apple.spe orange.spe power pellet.spe

Edited October 4, 2019 by Jaden (JRH)

[Synthpopalooza]

Slight modification to the pacland theme ...

 

The bass still uses $Cx, but it is now in what I have termed "Distortion 12b" ... i.e. we are dealing with frequencies in multiples of 3.  These produce less buzzy and screamy tones than the ones in the earlier example.  Downside:  The timbre is unstable, one of three timbres are randomly output.  There is a way to control this, but I have yet been unable to implement this yet.  It invloves doing a polycounter reset at the beginning of each note.

 

Binaries below.  As before:  Real hardware only, not emulation.  If you must use emulation, Prosystem comes the closest to it, A7800 makes it sound horrendous.  ?

 

Also included are @$450 binaries too.  Please test this on real HW.

 

I think I prefer this version, once I can get the random timbres under control.  What do you all think?

 

Also, here is the code which must be implemented to stabilise those timbres.  How would I go about adding this to trigger before each note plays?

 

sE10Ch1 = 14 ; it's safer to use selector values increased by 15
sE8Ch1 = 0
sE6Ch1 = 1
sE6Ch3 = 0
; begin setting channel 1 timer with 0
lda #0
sta AUDF2 ; put 0 to AUDF2
lda #$C0
sta AUDC2 ; set channel 2 volume to 0
lda $60 ; clock channel 1 with phi2/1.79MHz
sta AUDCTL
; wait at least 259 phi2 cycles so that timer counts down to 0
jsr wait260Cycles
; restore AUDCTL desired value, i.e. clock channel 1 with div28
lda $70
sta AUDCTL
; wait at least 112 phi2 cycles so that timer counts down to 0
jsr wait112Cycles
; now channel 1 timer is set to 0
; each div28 clock pulse loads channel 1 timer with AUDF1 = 0
; reset POKEY polynomial counters
lda #0
sta SKCTLS
; the period of resetting POKEY (SKCTL = 0) should last for
; at least 17 cycles to clear the longest 17-bit polycounter
; set AUDF1 register with selector value needed to reach desired E6
; poly4 element by channel 1
lda #sE6Ch1 ; 2 cycles
sta AUDF1 ; 4 cycles
nop ; 2 cycles
nop ; 2 cycles
nop ; 2 cycles
; finish resetting
lda #3 ; 2 cycles
sta SKCTLS ; 4 cycles
; wait for first div28 clock pulse to load timer with selector
:12 nop ; 24 cycles
; set AUDF2 register with desired frequency divisor
lda tmpAudF1
sta AUDF2
; setting AUDF2 register with desired frequency divisor must complete
; before next sampling based on selector (next loading a timer)!
; set AUDC2 register with desired volume (restore volume)
lda tmpAudC1
sta AUDC2

Also ... going to attach the .pdf here that explains the whole setup.  It was written with $Cx in 8-bit mode, but I think it will work in the 16-bit mode here, with modifications.

 

 

pacland2.A78 pacland2.asm pacland2.bin pacland2-450.A78 pacland2-450.asm pacland2-450.bin pokey-c-distortion-en.pdf

[Lost Dragon]

This thread reminded me of another once planned 7800 conversion..

 

Eliminator by Hewson. 

 

It converted very well to the C64:

 

 

Peter Pachla (7800 Jinks) was the assigned coder back then, but a deal couldn't be worked out with Hewson.

 

Anyone fancy trying something similar to it on the 7800 in this day and age?

 

[Giles N]

19 hours ago, Jaden (JRH) said:

 That was what should have been the pack in game for the system. 

Methinks you are very right here...