[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Ballerburg sources
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:
> 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
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:
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