[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Ballerburg sources



Hi,

On Tuesday 11 July 2006 00:23, Eero Tamminen wrote:
> On Sunday 09 July 2006 12:32, Odd Skancke wrote:
> > > Btw. Is anybody interested about ansified, cleaned up & translated
> > > (to English) Ballerburg source e.g. to make it work better with
> > > XaAES?
> >
> >  Yes!

Did you get anything out of the Ballerburg source code I sent?


> Attached is the latest version.  Compiles nicely with Pure-C and SozobonX
> except for warnings (if GEMlib header has been pre-compiled).  With
> SozobonX there are some strange things, the explosions happen maybe 10
> pixels below where the cannonball actually hits.

Does anybody on the list know why this could happen with SozobonX?


> Mr. Eckhard Kruse has kindly allowed the sources to be distributed now
> under GPL.  The original code is here:
> 	http://www.eckhardkruse.net/en/atari_st/baller.html
>
> My current changes are listed in baller/doc/changes.txt. I'm still going
> to do some work on the code.  At least move some of the strings that I
> temporarily moved to texts.h should be moved to resource file and some
> hardcoded string offset stuff should be converted to sprintfs.  I also
> intend to run the code through indent once it's ready, working and
> debugged.

Haven't had time for this so of course I forgot to publish the source code I
had ANSIfied and translated.  Others on the list can get it from here:
	http://koti.mbnet.fi/tammat/hatari/devel.shtml

Btw. I haven't coded GEM stuff in 10 years.  How do I access free strings
in the resource file?  (currently there are quite a lot of strings within
the source code but I would like to move them all to the resource file)


> The problems you're going to encounter are:
> - GOBJECT pointers are longs (earlier they were ints!), not pointers,
>   and there's some funny arithmetic with them. Arithmetic is also done
>   with char variables (and the original LATTICE chars were signed)
> - In some places the code draws directly to the screen memory
>   (at least cls()). Mostly everything uses VDI though
> - Sizes are hardcoded, there are no defines for them


	- Eero