was late at night and it was early in the morning as I was
cycling through the last Make, then test sessions before
I was to release the beta version of Morris. Morris was
my first attempt at developing a game application and it
was my introduction to eVB and development for the Pocket
PC. I was reaching the point where I had been up too long
and new fixes may have been creating more new problems than
they were solving. Even still, out of the corner of my eye
it seemed that Morris was getting fat. Each flurry of typing
and testing was more about commenting the complexities I
was unraveling, than the creation of new code, and, Morris
kept getting bigger.
The next day, or maybe the one after,
I finally got the sense that Morris was ready. Not for the
official 1.0 release, but for a solid second beta release.
This time, however, I was going to release it to a much
bigger audience than the handful of people that had seen
the game so far. I set Morris free on a couple of these
new hand held software distributor sites, namely Handango
in hopes that Morris might get to play with some new folks.
Getting the software set up on the site for distribution
was surprisingly straightforward, the most time consuming
part was reading the legalese. It was a beta, a solid beta,
but a beta nonetheless so I priced it as freeware for its
Of download counters and feedback
Well, Morris had barely got out the
door and the download counters started to tick. I think
they were at ten already while I was still fine-tuning the
descriptions and graphics that appeared for the different
versions of files for each of the Pocket PC processors.
The speed of response from Pocket PC'ers made me a little
giddy as I refreshed the pages to see the current download
counts move along throughout the afternoon. The thing I
was most concerned about though was the speed of Morris.
All of the extra sophistication of my last round of enhancements
to the computer players in the game certainly made playing
the computer more challenging but the advanced players were
sometimes very slow on my Cassiopeia 115.
On the Pocket PC, some of the computers'
moves were taking too long for my liking, upwards of 10
seconds or more, and I was probably more forgiving than
most of the 250+ people who had downloaded Morris on his
first day on the streets. I was expecting speed to be the
number one issue reported back from Morris's new friends.
The difference in performance of the eVB version compared
to the VB 6.0 version that I developed in parallel was astounding.
The two versions actually shared about 90% or more of the
exact same code. The only difference was in the form files,
the actual code module files were common between the two.
The VB 6.0 version was created for debugging purposes only,
since I found the debugging environment of eVB 3.0 to be
too, too... well you know, you've used it. So if anything
the VB 6.0 project was a little dumbed down as far as VB
6.0 projects go. It only made use of the basics of the language
that were supported by eVB, no classes, simple select statements
and light on fancy features. Yet, when I set two computer
players at each other for an overnight (morning till noon
actually) tournament they might polish off 10,000 games
on a desktop machine running in debug mode in the VB 6.0
IDE. The players on the version installed on my Casio were
lucky if they finished off 100 games in the same amount
of time. What a difference!
By day two, feedback started to trickle
in. People looking for a version that would work on their
particular processor initiated most of the early email.
After I pointed them to the right location, they often responded
with thanks and included a few words of praise along with
an idea or thought about Morris. Contrary to my fears, speed
wasn't mentioned in the early feedback. Size was. Understandably
so, as Morris.vb was now weighing in at close to 300 KB.
I saw the issues of size and speed as possibly related since
eVB runs as interpreted Pcode. I figured if I could get
a few KB off of that .vb file Morris was bound to run a
little faster. I then recalled that during the sunrises
of the previous week it seemed that every comment I added
to the code seemed to make the make file bigger. No, that
seemed silly. The good men and women of Microsoft would
surely write code to strip that kind of stuff out when creating
a .vb file for distribution. Wouldn't they?
So I started to play and experiment.
I made a version of Morris.vb, recorded the file size and
then went back in to the code and added a new procedure.
This procedure held nothing but 1000 lines of pasted comments
containing a few copies of the letter "A". I rebuilt
Morris.vb and sure enough the darn thing went up by 1,000
bytes. So I thought about the many verbose comments that
I had added to project during the last stages of development
and felt the heavy weight of frustration pushing me back
from my development machine. Comments are good, I thought
to myself, years of coding and re-coding and trying to pick
up code where others have left off have made me a believer.
So, off I went to register for the forums on deVBuzz.com.
Lurking wasn't enough, I needed to post a message about
The thread that developed and my experimentation
and research touched on a number of issues. First confirmation
from other developers that when they tried my experiment
they too experienced growth in their .vb files. The experiments
by others on the thread quickly lead to a suggestion that
a separate VB utility could prepare the eVB code for compiling
by backing up the source and then stripping the offending
material out. After the new "low fat" .vb was
made you could copy back your backed up source so that you
don't lose the comments and formatting that you have worked
so hard to create.
So, after a little fiddling with the
find & replace features of Word, I then decided that
the way to go was definitely a little VB 6 utility. I created
a utility that simply starts with an array of hard coded
file names of all the frm and bas files in the project and
processes each file in a couple of loops. To process a file,
I opened it up and then read line by line. I also opened
up a new file with the same name and tacked on three extra
letters (tmp) onto the end of the file name. Writing to
this new file meant that I didn't have to worry about writing
to the file I already had opened, I could simply create
a new version of it and swap it later. I trimmed each line
and checked to see if the first character was equal to either
the comment apostrophe symbol (') or if the trim lined is
actually equal to an empty string (""). If either
were true then that line would not be necessary in the new
file since it was either white space or a comment. If neither
of those was true I then wrote the line to the new file.
As a result my new frm and bas files included just the lines
with code in them and they were now stacked tightly one
on top of the other without white space. The routine was
quick and easy to make and to run. The routine was also
relatively inert to my code after testing each step in the
process to make sure it worked as expected.
Meantime, through other efforts with
a code analyzer I had removed deadwood code and I had also
made an effort to remove many larger sections of white space.
My make file had slimmed down to 246,608 KB. Now after running
my new routine and doing another compile, the .vb file was
down to 232,296 KB, an additional savings of about 14,000
bytes. That was all wasted space! The effort seemed worth
while considering the target platforms limited resources
and the idea that your .vb file in a sense uses not just
storage space on the device but also memory space for running
applications. I ran another tournament or two to make sure
that this Low Fat version of Morris still worked, as it
should. Fortunately, there were no nasty surprises and the
smaller vb file worked just fine. Unfortunately, whatever
the performance gains were from this reduction in size,
they were too small to speed up the computer players to