Another Galaga thread

[rensoup]

 

Very nice demo, seems like a lot of pixels are pushed around!

 

On 2/11/2020 at 10:43 AM, playsoft said:

Thank you. It's really nice to see someone being proactive like this. They sound great and normally I'd jump at any RMT music on offer, but in this case I am up against it with both CPU cycles and memory.

 

Have you considered dmsc' LZSS player ? It's basically compressed SAPR. Most of the time the files are usually the same size or smaller. The player is tiny but the buffers can be expensive, up to 9*256 bytes (depends if you want good or average compression on the tune ).

 

Speed is where it really smokes the RMT player, about 8-10 scanlines.

 

I don't know if you need to play sfx and music at the same time, which might be a problem?

 

[Synthpopalooza]

On 2/11/2020 at 8:09 PM, Jaden (JRH) said:

Sure, I'd love to work on some music for you. I'm not super familiar with RMT, but I can definitely spend more time practicing with it to help with your project. Send me the details whenever you feel comfortable to.

 

As for Galaga, I personally hope that this one gets finished. You don't have to do it right away, of course. But the Atari 8-Bit line is definitely in need of a proper Galaga port. And your demo is pretty great. So, I hope that this one gets finished eventually. I tried out your demo and a lot of the music was very off-key. I'll keep working on mine, but I'll have to find ways to make smaller files. Good luck on your projects and thanks for responding.

I can try to do up some non-RMT music if you like.  I got a few ideas for mimicking that WSG Namco sound chip ... 

[playsoft]

 

11 hours ago, rensoup said:

 

Very nice demo, seems like a lot of pixels are pushed around!

 

 

Have you considered dmsc' LZSS player ? It's basically compressed SAPR. Most of the time the files are usually the same size or smaller. The player is tiny but the buffers can be expensive, up to 9*256 bytes (depends if you want good or average compression on the tune ).

 

Speed is where it really smokes the RMT player, about 8-10 scanlines.

 

I don't know if you need to play sfx and music at the same time, which might be a problem?

 

Thanks, being a space game I was able to make a couple of good optimisations with the sprites; (a) when drawing over a blank character just write the new data straight out, (b) replace any ANTIC 4 display list entries with blanks if nothing is drawn on those rows.

 

I haven't picked this back up yet and I'm not sure I will (a bit too much pressure for me). I was aiming for a 32K cart - and there is about 8K ROM free and about 4K RAM free. There are times when it can't maintain 60Hz so I flicker one of the sprites. It's barely noticeable as it's 1 sprite in 10 and doesn't happen very often or for very long. I can speed up the sprite drawing but that costs another 5K ROM.

 

I don't know if the remaining 8K ROM/4K RAM would be enough for everything else. It probably is a bit tight, so if it did need a bigger cart that might be the time to consider a more sophisticated music player, although to my non-musician ears I'm not sure the music in Galaga needs it - like Synthpopalooza says above, it might be more a case of mimicking the Namco sound chip.

 

[rensoup]

8 hours ago, playsoft said:

Thanks, being a space game I was able to make a couple of good optimisations with the sprites; (a) when drawing over a blank character just write the new data straight out, (b) replace any ANTIC 4 display list entries with blanks if nothing is drawn on those rows.

 

Oh, you're variably blanking in the middle of the screen?... a daring move ?. The screen seems pretty full at times though... Plus a whole bunch of DLis for repositioning the PMG stars... ouch!

 

It's pretty rare that mode4 is useful but this is a good showcase for it !

 

8 hours ago, playsoft said:

I haven't picked this back up yet and I'm not sure I will (a bit too much pressure for me). I was aiming for a 32K cart - and there is about 8K ROM free and about 4K RAM free

 

You're dealing with some pretty severe constraints but you could use LZSS with a 256 bytes buffer and bad compression
 

LZSS is compressed raw Pokey data so any player can be used... Out of curiosity I tried compressing one of @Jaden (JRH)'s tunes:

 

Galaga - Perfect!.rmt         (670 bytes)

 

Galaga - Perfect!.lzs8      (345 bytes)
Galaga - Perfect!.lzs12        (298 bytes) 
Galaga - Perfect!.lzs16     (264 bytes)

 

Even at the worst setting it's half the size, so all those tunes would probably take just 1KB of ROM.

 

galaga_perfectLZS.obx requires less than 300 bytes of RAM (ZP is optional and speed dif is minimal) and the player takes around 128 bytes of ROM.

 

I've included the test files, now compare the CPU usage for LZS and RMT and laugh all the way to the bank...if you ever decide to pick that project up again of course ?

 

galagaLZS.zip

[BIGHMW]

I have picked up another Atarimax SD multicart (remember I sold my previous one last year due to unemployment back then) and have downloaded Galaga and can't wait to try it once I get the multicart, as I already have the SD card from the previous unit.

[Jaden (JRH)]

On 3/27/2020 at 7:29 PM, rensoup said:

LZSS is compressed raw Pokey data so any player can be used... Out of curiosity I tried compressing one of @Jaden (JRH)'s tunes:

 

Galaga - Perfect!.rmt         (670 bytes)

 

Galaga - Perfect!.lzs8      (345 bytes)
Galaga - Perfect!.lzs12        (298 bytes) 
Galaga - Perfect!.lzs16     (264 bytes)

 

Even at the worst setting it's half the size, so all those tunes would probably take just 1KB of ROM.

 

galaga_perfectLZS.obx requires less than 300 bytes of RAM (ZP is optional and speed dif is minimal) and the player takes around 128 bytes of ROM.

So, with the compression, the game should be able to fit all the music, right? The wording makes it almost sound like no matter the compression, the music files are still too big. But they seem small enough.

 

I don't know if there are any other tools for the POKEY that can produce smaller files. I'm sure there's something out there, but I haven't found it. I'd love to still do music for this, if playsoft wants to pick it up again.

[kiwilove]

Nice to know that someone's keen to help out with the music (and SFX?) side because sound is so important in these iconic games.

Tezz is the most likely person to work on a conversion - as he has some good personal connection with the arcade game.  But with him being busy with other projects? We can only hope he now knows what to do on it when he has the time - thanks to Paul.

It will be a surprise to everybody if a 5200 conversion will end up surpassing the 7800 conversion?  Or at least equal to it.

So that we can all enjoy what I think is the most wanted of the missing games for this hardware platform. (of course - also there being an 8-bit Atari 400/800/etc conversion too).

 

Harvey

[playsoft]

On 3/28/2020 at 12:29 AM, rensoup said:

Oh, you're variably blanking in the middle of the screen?... a daring move ?. The screen seems pretty full at times though... Plus a whole bunch of DLis for repositioning the PMG stars... ouch!

 

It's pretty rare that mode4 is useful but this is a good showcase for it !

 

No nothing daring - both the screen map and the display list are double buffered, so with the off-screen buffer erase the old sprites, draw the new ones and create the display list so that it only has ANTIC 4 rows for those on which sprites were drawn.

 

You are right, there are single line incoming waves where there may only be a couple of ANTIC 4 rows empty but I think that's enough to cover the overhead of doing this. I roughly estimate there are 100 cpu cycles available on a blank scanline and 50 available (averaged) on a scanline that is part of an ANTIC 4 row. So each one omitted claws back around 400 cycles (minus the overhead).

 

In this case where the sprites are spread out vertically the other optimisation kicks in; because of that spread they tend not to overlap much, so the blank character optimisation gets used a lot.

 

The opposite scenario is when they are all grouped together moving to their formation positions. Here the blank character optimisation isn't used much but removing the ANTIC 4 rows is.

 

The two optimisations work so well together I could probably convince people it was all planned out like this in advance... ?

[rensoup]

12 hours ago, Jaden (JRH) said:

So, with the compression, the game should be able to fit all the music, right? The wording makes it almost sound like no matter the compression, the music files are still too big. But they seem small enough.

Well I don't know, you'd have to ask Playsoft ?  

 

But the numbers are pretty good, I just meant that even with the worst compression setting, the compression is good enough (for that tune at least)... plus the LZS player is several times faster in terms of CPU usage.

 

From my bystander's pov, it's all good!

 

[rensoup]

27 minutes ago, playsoft said:

No nothing daring - both the screen map and the display list are double buffered, so with the off-screen buffer erase the old sprites, draw the new ones and create the display list so that it only has ANTIC 4 rows for those on which sprites were drawn

I'd never heard of games dynamically blanking parts of the screen before. 

 

I used to think that blanking was for the top and bottom part of the screen and if you started messing with it dynamically, the screen would lose its sync or something.

(Now that I'm thinking about it, Antic blanking may be different from screen blanking ? otherwise the sprites would vanish ?)

 

34 minutes ago, playsoft said:

The two optimisations work so well together I could probably convince people it was all planned out like this in advance... ?

indeed ?

[playsoft]

On 3/28/2020 at 12:29 AM, rensoup said:

You're dealing with some pretty severe constraints but you could use LZSS with a 256 bytes buffer and bad compression

 

LZSS is compressed raw Pokey data so any player can be used... Out of curiosity I tried compressing one of @Jaden (JRH)'s tunes:

 

Galaga - Perfect!.rmt         (670 bytes)

 

Galaga - Perfect!.lzs8      (345 bytes)
Galaga - Perfect!.lzs12        (298 bytes) 
Galaga - Perfect!.lzs16     (264 bytes)

 

Even at the worst setting it's half the size, so all those tunes would probably take just 1KB of ROM.

 

galaga_perfectLZS.obx requires less than 300 bytes of RAM (ZP is optional and speed dif is minimal) and the player takes around 128 bytes of ROM.

 

I've included the test files, now compare the CPU usage for LZS and RMT and laugh all the way to the bank...if you ever decide to pick that project up again of course ?

 

galagaLZS.zip 6.31 kB · 3 downloads

 

Thanks, that's fantastic, it certainly makes a difference to the cpu and memory overhead.

 

As a comparison I tried 3 different versions of the start tune; the 7800 one, a midi file conversion and Jaden's RMT using LZSS (I used the 12 bit one for this).

 

In terms of what they sound like, Jaden's is obviously by far the best.

 

In terms of cpu cost, the 7800 is cheapest, then midi, then LZSS - appears to be a little over double the 7800 cost.

 

In terms of song size, the 7800 is 100 bytes, midi is 180 bytes, LZSS is 344 bytes.

 

In terms of player size, LZSS is the smallest although the 7800 does have other things in there for sound effects which are not used by this tune.

 

I can't say there would be the resources available for it in a 32K cart but it definitely makes it more viable.

 

vcs.xex midi.xex jaden_start_lzss.xex

[playsoft]

41 minutes ago, rensoup said:

I'd never heard of games dynamically blanking parts of the screen before. 

 

I used to think that blanking was for the top and bottom part of the screen and if you started messing with it dynamically, the screen would lose its sync or something.

(Now that I'm thinking about it, Antic blanking may be different from screen blanking ? otherwise the sprites would vanish ?)

 

Ah yes, blanking with DMACTL would be daring, I just put the blank scanline codes in the display list ($00..$70).

[rensoup]

6 hours ago, playsoft said:

As a comparison I tried 3 different versions of the start tune; the 7800 one, a midi file conversion and Jaden's RMT using LZSS (I used the 12 bit one for this).

 

In terms of what they sound like, Jaden's is obviously by far the best.

 

In terms of cpu cost, the 7800 is cheapest, then midi, then LZSS - appears to be a little over double the 7800 cost.

 

To add to your comparison:

vcs.xex sounds like it's not using all channels ? you could use 3 channels with LZS and the decoding would be faster.

midi.xex is wildly variable, sometimes a lot slower than LZS.

jaden_start_lzss.xex: It is possible that LZS12 is the slowest of all 3 version of LZS (although just slightly), I'm not 100% sure.

 

I don't know if any of the tunes gets played when the screen is really busy though, so perhaps that's not even an issue ?

 

6 hours ago, playsoft said:

I can't say there would be the resources available for it in a 32K cart but it definitely makes it more viable.

Hopefully that'll tempt you to give it a shot ?

 

6 hours ago, playsoft said:

Ah yes, blanking with DMACTL would be daring, I just put the blank scanline codes in the display list ($00..$70).

I'll still add it to my bag of tricks?

 

Edited March 29, 2020 by rensoup

[Jaden (JRH)]

The midi one sounds pretty good and the CPU cost and size are right in the middle of the other ones. So, if you good sounding music that doesn't take up much space or CPU time, midi might be the way to go

[Synthpopalooza]

Here's mine ... what do you think?

 

 

galaga-intro.asm galaga-intro.s galaga-intro.xex

[Synthpopalooza]

The notes at the end might not be perfect, but I think they can be tweaked ...

 

Setup:

 

AUDCTL=$60

 

0 - $2x @1.79 mhz

1- $Ax (square wave - same notes as 0 but an octave down)

2 - $Cx @1.79 mhz

3 - $Ax (Square wave - same notes as 2 but an octave down)

 

I have custom note tables for channels 0 and 2 @1.79 mhz

[rensoup]

just checked vcs.xex in Altirra audio debug and it only uses 2 channels so not a super fair comparison with LZS...

 

 

[Synthpopalooza]

Also, mine is about 272 bytes plus the code for the music player.

[rensoup]

2 hours ago, Synthpopalooza said:

Here's mine ... what do you think?

Wicked sound! 

 

A little slow perhaps and like you said some notes seem a little off but an interesting take for sure!

[Synthpopalooza]

Also:  The $Cx 1.79 mhz setting is 100% suited to doing that G f# E D tractor beam sound.  ?

[playsoft]

13 hours ago, Jaden (JRH) said:

The midi one sounds pretty good and the CPU cost and size are right in the middle of the other ones. So, if you good sounding music that doesn't take up much space or CPU time, midi might be the way to go

I much prefer your RMT one over the midi (plus that was the only midi file I could find, so the other tunes would be missing) and with the LZSS compression it's much more viable to include them.

 

I really don't know if the remaining functionality will fit in a 32K cart anyway - and if I do target a bigger cart I can turn the other sprite drawing optimisations on.

[playsoft]

12 hours ago, Synthpopalooza said:

Here's mine ... what do you think?

 

 

galaga-intro.asm 11.9 kB · 2 downloads galaga-intro.s 19.01 kB · 2 downloads galaga-intro.xex 1.69 kB · 6 downloads

Yes interesting, a sort of harpsichord vibe to it.

9 hours ago, Synthpopalooza said:

Also, mine is about 272 bytes plus the code for the music player.

I think the 4 duration tables are the same, so more like 170!

[playsoft]

I generated builds using the two tunes. There's not really much in it, Synthpopalooza's is slightly smaller and requires less cpu cycles although it is not as consistent.

 

I did try the sap/lzss process on Synthpopalooza's but it did not compress as well as Jaden's, presumably because of the 16-bit values.

jaden_5200.bin synth_5200.bin

[Synthpopalooza]

16 -bit actually isn't used at all.  It's 4 8-bit channels.  1 and 3 have a standard square wave, 0 and 2 are $2x and $Cx respectively but hit with a 1.79 mhz clock to transpose them up into a playable range.

[Synthpopalooza]

Also ... I am going to go into it today or tomorrow and try to fix those bum notes in it too. 

 

I also have ideas for sound effects too.  Not sure how they will all work.  I think the arcade version uses 3 channels only.  That $Cx channel at 1.79 does the tractor beam sound perfectly.