Jugglemaster for Pocket PC (JMPocket)

[Per Johan Groland]

Hi,

Since this is the first time I'm posting to the JuggleMaster mailing
list, I'll start by introducing myself. I'm Per Johan Groland, the
original author of jmlib. (along with Palm OS and Pocket PC ports)


Anyway, I recently spent some time updating the Pocket PC version
(JMPocket) to work with the new directory structure and changes made
to jmlib. There were as expected no (serious) problems getting it up
and running, so I'll be ready for inclusion in CVS soon(ish). I just want
to spend some time checking everything to see if I can't eliminate a bug
or two while I'm at it. It requires Microsoft eMbedded Visual Tools to
compile, which is available free of charge from Micorosft's web page.

I also noticed that the license of jmlib has changed to BSD. Does
this mean that someone were able to contact Ken?

I'm not familiar with the BSD license, and I seem to remember us
discussing GPL earlier. What is the reason BSD was chosen over
GPL? Also, I don't mean to sound grumpy, but since my copyright
is also on the code, it would be nice to have notified me before
changing the license...


I also thought I'd make a few comments on the changes done to jmlib:

#define BMAX 630		     // max number of balls

This was originally 35. Since the arrays in jmlib are all declared
statically, this adds something in the area of 32 kB to the static
memory requirement of jmlib. This doesn't matter on a PC of course,
but it does matter on some of the platforms I've been trying jmlib
on. Is it possible to add a typedef (e.g. JMLIB_BMAX_630) to make
jmlib chose 35 balls as default rather than 630?

the JMLib::initialize function seems to have changed quite a bit.

This breaks the Pocket PC version:

  srand(time(NULL));

There is no time.h defined for the Pocket PC API. I'm not exactly
sure why you want to use srand anyway, jmlib doesn't use any random
number, right?

>I've been fixing lots of bugs recently, mostly type-related because of
>jmlib's preoccupation with using typedef'd JML_* types. Grrrr.

I originally added this stuff for portability reasons. I wanted to make
sure that jmlib got a 32-bit type where it was expecting 32-bit and a
16-bit type where it was expecting a 16-bit type etc. (see jmlib_types.h)
Just writing "int" gives you no guarantee as to the data size. I remember
fiddling with a Game Boy version several years ago, where an int is 16-bits.

I'm curious though, as to what kind of bugs this is causing. I always use
this typedef system when I write something I want to be portable...

Finally, how to I get an account so that I can commit to the CVS repository?