Re: [hatari-devel] optimizing for speed

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 16 joulukuu 2012, Laurent Sallafranque wrote:
> I did think about packing at one time, but not for loading reasons (I
> think the game loads quite quickly, in comparison to modern games where
> you have to wait sometimes 1 minute).
> 
> No, it was just to be able to add one more enemy in a level.
> But I thought : 4 different enemies per level + the main player is
> already nice on a standard Falcon.
> Else, I would have had to remove one enemy and unpack the other one on
> the fly (there's not enough room for 5 enemies simultaneously in memory).
> And I think it would have stopped the game during a little time and I
> didn't want this.

lz77 assembly version seems to do unpacking pretty fast.

I tested it (68000 version) under Hatari WinUAE Falcon emulation
and it unpacked maxima.bin within 2s.  This is >0.5MB / sec.
I assume that to be fairly accurate compared to real Falcon
(worst emulation inaccurations are currently in FPU code).
Assumably 030 version gets a bit more speed.

The attached code can be used to do packing on x86 and in your
Falcon code you can just load packed file into memory, allocate
enough memory for the unpacked result and call the asm code.

(There's also 68000 binary in case you want to test it right away
on real machine to see whether it reports there different timings
from Hatari. :-))

As to how much it can compress:
	$ for i in $(find -type f); do lz77 p $i $i.lz; done
	$ cd data
	$ ls -s bgs/[0-9]* chars/ misc/images/ players/|cat
156 bgs/1
 56 bgs/1.lz
156 bgs/2
 60 bgs/2.lz
156 bgs/3
 48 bgs/3.lz
156 bgs/4
 56 bgs/4.lz
156 bgs/5
 40 bgs/5.lz
156 bgs/6
 44 bgs/6.lz
156 bgs/7
 60 bgs/7.lz
156 bgs/8
 56 bgs/8.lz
156 bgs/9
 48 bgs/9.lz

chars/:
total 9624
484 angel.bin
244 angel.bin.lz
448 billy.bin
224 billy.bin.lz
292 eiji.bin
148 eiji.bin.lz
904 heavy.bin
428 heavy.bin.lz
352 jhun.bin
184 jhun.bin.lz
392 joe.bin
200 joe.bin.lz
332 punk.bin
160 punk.bin.lz
300 ralf.bin
152 ralf.bin.lz
512 robert.bin
252 robert.bin.lz
856 rugal.bin
380 rugal.bin.lz
428 shermie.bin
220 shermie.bin.lz
684 yamazaki.bin
316 yamazaki.bin.lz
488 yashiro.bin
244 yashiro.bin.lz

misc/images/:
total 1080
156 credits.bin
 68 credits.bin.lz
156 hallfame.bin
 32 hallfame.bin.lz
156 menu.bin
 72 menu.bin.lz
156 title.bin
 40 title.bin.lz
156 win.bin
 88 win.bin.lz

players/:
total 4420
 612 kula.bin
 292 kula.bin.lz
 220 kula_m.bin
 108 kula_m.bin.lz
 628 mandy.bin
 316 mandy.bin.lz
 132 mandy_m.bin
  68 mandy_m.bin.lz
1076 maxima.bin
 524 maxima.bin.lz
 300 maxima_m.bin
 144 maxima_m.bin.lz


> So, it was a lot of work and I still had to write many things for the
> game (IA management, level's building, ...).
> 
> I' think there'll probably be a V1.2 for the background flickering
> problem + inversion of the throw animation as someone asked on the atari
> forum (this is already done in my dev code).

If you're still thinking about compressing, it doesn't seem too
much of extra work.  Attached source can do the compression and
extra code needed for integrating the uncompressing code doesn't
seem that much.

But is 1/2MB per sec on Falcon fast enough decompression speed
for you and does the compression save enough memory?


	- Eero

PS. If you're interested to do that, I could do some tests to see
that at least all the files you select for compression are uncompressed
correctly by the assembly code and without any memory overwrites
(by adding some canary bytes at the array ends in the lz77.c which
I would use for testing).

Attachment: lz77.zip
Description: Zip archive

Attachment: lz77.ttp.gz
Description: GNU Zip compressed data