Celtic Heart full source code

[phx]

For anybody interested, the following archive includes the complete Celtic Heart project, to build everything from scratch. It includes sources texts, graphics, music, tools, etc.:
http://server.owl.de/~frank/CelticHeart.lha

As usual for my games, the build process should be portable, so you can build it on many different host systems. Initially the only dependancy is a working ISO-C99 compiler. The rest can be built from source.

Other tools needed (build from source):

• GNU-make
• vasmm68k_mot
• vlink

And the AmigaOS NDK 3.x assembler include files would be good to have. Makefile uses vbcc and Makefile.unix uses gcc to build the tools. The only variable you might have to change in your Makefile is ASINC, which defines the path to your AmigaOS assembler includes.

Have fun!

[mcgeezer]

Great PHX, will take a look at this!

Massive respect!

[phx]

Thanks.

BTW, I forgot to include any kind of license in the archive. So I want to state here that everything in it is public domain and may be freely reused in other projects.

[roondar]

Awesome, I'll be taking a look for sure!

[ross]

Great!

[clenched]

It was mesmerizing to watch the tmx tools build process work. Nicely done.

[ascp]

Originally Posted by phx

For anybody interested, the following archive includes the complete Celtic Heart project, to build everything from scratch. It includes sources texts, graphics, music, tools, etc.:
http://server.owl.de/~frank/CelticHeart.lha

As usual for my games, the build process should be portable, so you can build it on many different host systems. Initially the only dependancy is a working ISO-C99 compiler. The rest can be built from source.

Other tools needed (build from source):

• GNU-make
• vasmm68k_mot
• vlink

And the AmigaOS NDK 3.x assembler include files would be good to have. Makefile uses vbcc and Makefile.unix uses gcc to build the tools. The only variable you might have to change in your Makefile is ASINC, which defines the path to your AmigaOS assembler includes.

Have fun!

[clenched]

Some Amiga testing here: Latest aos3 VBCC and Target software. Instead of having to stand watch for hours, this is the way time was measured. Time stamp of bmptoraw[.exe] (first compiled) is subtracted from that of CelticHeart.adf (last) to get elapsed time close enough.

Windows (MinGW):     00h 01m 57s
WinUAE + JIT:        00h 13m 59s
Amiga 500 + A530:    13h 17m 42s

Trap Runner has over twice the levels, two more worlds of gfx (three if Pacman counts), an intro, maybe more music. I wonder how long would that take on the Amiga?

[Zener]

Just found out about this game and played it. It's great! I love the music

[phx]

Originally Posted by clenched

Amiga 500 + A530:    13h 17m 42s

Wow! 13 hours. A530 has an 68030?
I remember that I have once built everything on my A3000 with 68060/50. It took clearly more than an hour. Usually I'm building it on my Pegasos G3 in a few minutes. Fortunately I rarely have to rebuild everything.

Trap Runner has over twice the levels, two more worlds of gfx (three if Pacman counts), an intro, maybe more music. I wonder how long would that take on the Amiga?

A little longer. Source text will be available soon.

The time-consuming part is the lz-compression of all the files. Johan Forslöf's portable lz probably needs some optimizing...?

[clenched]

A530 has an 68030?

It is the 68EC030 to be exact. 40MHz. One thing is it has only one 4mb fast ram stick. With WinUAE increased to 8mb the time fell to 11 minutes and change.

The time-consuming part is the lz-compression of all the files. Johan Forslöf's portable lz probably needs some optimizing...?

I looked in on the Amiga from time to time and lz was always the bottom line.

This may need looking at. Between compiling and play testing it almost slipped my mind.

vasmm68k_mot -Fvobj -quiet -x -DSDATA -I include -I :NDK_3.9/Include/include_i -o obj/sprites.o sprites.asm

fatal error 5 in line 1 of "REPEAT:sprites.asm:line 272": internal error 0 in line 1082 of expr.c
        included from line 272 of "sprites.asm"
>       move.w  (a0)+,D(a1)
aborting...
vasmm68k_mot failed returncode 20
make: *** [obj/sprites.o] Error 20

REPEAT sounds like something to do with the stack so it was increased from 4096 to 20000. After that it was OK because the ADF exactly matches yours.

[phx]

Originally Posted by clenched

REPEAT sounds like something to do with the stack so it was increased from 4096 to 20000. After that it was OK because the ADF exactly matches yours.

Yes, 4K stack is not sufficient. For vasm and vbcc you need at least 8K, better 16K.

[clenched]

Freak discovery: A timer is added to lz.c and makefile adjusted to print statistics. Rebuild on Windows and log to a file. Count all occurrences (71) of "lz -o". The sorted chart shows the distribution. See a lone file with a leap from 5 to 9 seconds. That is mntsnow_plx.bin so it will be test subject. It takes my Amiga 1h 16m to pack this one file.

sec   files   total sec
  0 * 34       0 
  1 * 11      11 
  2 * 05      10 
  3 * 11      33 
  4 * 05      20 
  5 * 04      20 
  9 * 01       9
-------------------  
      71     103

[phx]

I noticed that lz is especially slow when packing files which have a high pack-ratio. The algorithm probably needs some optimization in that case.

Example: Packing mod-samples is fast. Packing mod-tracks is slow.

[Bruce Abbott]

Originally Posted by phx

I noticed that lz is especially slow when packing files which have a high pack-ratio. The algorithm probably needs some optimization in that case.

That might be the understatement of the year.

I compiled your bmptoraw and lz tools with SASC 6.58. On my 50MHz 030 lz took over 1 hour to pack mntsnow_plx.bin. Packing it with lzx took less than 2 seconds, and the result was smaller. I noticed that the original 128x96 bmp image only had 4 colors, so I converted it to a 2 bitplane ILBM brush and the result was much smaller! Here are the file sizes:-

mntsnow_plx.bmp 12470
mntsnow_plx.bin 25088
mntsnow_plx.lz 3303
mntsnow_plx.lzx 2812
mntsnow_plx.ilbm 1130

According to my calculations a raw 128x96 2 bitplane image should only take up 3072 bytes, which is smaller than the lz packed file.

[clenched]

Originally Posted by Bruce Abbott

According to my calculations a raw 128x96 2 bitplane image should only take up 3072 bytes, which is smaller than the lz packed file.

Take into account mntsnow_plx.bin is 8 times larger in area than mntsnow_plx.bmp.

tools/bmptoraw gfx/mntsnow_plx.bmp 16 96 2 SPRITE2 0-63 gfx/mntsnow_plx.bin

What is happening is 64 16*96 sprites are made from the small picture. SPRITE2 mode is in use so 4 control words must be added to each sprite.
(2bytes*96lines*2planes+8)*64 = 25088

[phx]

Originally Posted by Bruce Abbott

That might be the understatement of the year.

I compiled your bmptoraw and lz tools with SASC 6.58. On my 50MHz 030 lz took over 1 hour to pack mntsnow_plx.bin.

I don't know if Johan Forslöf is reading this forum. But complaints about his lz-packer should go directly to him.

I was just happy having found a packer which is portable and much better than Bytekiller.