Commit 719a220c authored by David Bruce's avatar David Bruce

adding tuxtype-new (instead of tuxtype-reorg)

git-svn-id: svn:// 47d30e19-490b-0410-9d18-e851f4e465b3
David Bruce <>
Jesse Andrews <>
Calvin Arndt <>
Sam Hart <> --- Sam started it all with TuxType 1!!!
Jacob Greig <>
Sreyas Kurumanghat <>
Sreerenj Balachandran <>
Vimal Ravi <>
Prince K. Antony <>
Mobin Mohan <>
Packaging & Ports:
Holger Levsen <> - (Debian packager, project maintainer)
David Bruce <> - (Windows crossbuild using Linux host)
David Marshman <> - (BeOS port/packages)
Calvin Arndt <> - (Red Hat 7.1+ RPMs)
Olivier Dagenais <> - (Windows port/packages)
Jesse Andrews <> - (Mac OS port)
Special thanks to:
Rich Bellamy <> - (for several image patches)
Frank Ellis <> - (for many submitted bug items and feedback)
Nicolai Beier <> - (for Danish work in TuxType 2)
Martin Moeller <> - (for Danish word files in TuxType 1)
Martin Rioux <> - (for French translation in TuxType 1)
Karl Ove Hufthammer <> - (for Norwegian Nynorsk translation work for Tuxtype 2)
Trond Mæhlum <> - (for Norwegian Bokmål translation work for Tuxtype 2)
Sreyas Kurumanghat <> - (for Indic language support)
Sreerenj Balachandran <> - (for Indic language support)
Vimal Ravi <> - (for Indic language support)
Prince K. Antony <> - (for Indic language support)
Mobin Mohan <> - (for Indic language support)
Ralf Wildenhues <> - (for Autotools help via mailing lists)
Note: ConvertUTF.c/.h are from Unicode, Inc. and are released under a very free (BSD-like) license:
"Unicode, Inc. hereby grants the right to freely use the information
supplied in this file in the creation of products supporting the
Unicode Standard, and to make copies of this file in any form
for internal or external distribution as long as this notice
remains attached."
Note: The Andika,Doulos, and Charis fonts are from SIL International and are licensed under the Open Font
License, Version 1.1 (see "OFL.txt" in this directory for the full license text).
\ No newline at end of file
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Quick Installation
Tuxtype should compile out of the box if you have a sane tool chain
and the following SDL libraries:
freetype2 is required for SDL_ttf
SDL_2.0.6 is known not to compile on RH9
For most people using Linux
./configure --prefix=[your prefix here]
make install
if you run into problems rerun:
autoreconf --install
We want this to work for everybody, everywhere, if it doesn't
work for you please contact
While I've made every attempt to get build system right,
I am an autoconf/automake newbie. If you encounter issues
please feel free to contact me directly at:
Calvin Arndt <>
Basic Installation
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `' is used to create `configure' by a program
called `autoconf'. You only need `' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes a while. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Type `make install' to install the programs and any data files and
4. You can remove the program binaries and object files from the
source code directory by typing `make clean'.
5. You can uninstall the program by typing `make uninstall' (trust me
this really does work ;)
Compilers and Options
Some systems require unusual options for compilation or linking that
the `configure' script does not know about. You can give `configure'
initial values for variables by setting them in the environment. Using
a Bourne-compatible shell, you can do that on the command line like
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
Or on systems that have the `env' program, you can do it like this:
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
Compiling For Multiple Architectures
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
If you have to use a `make' that does not supports the `VPATH'
variable, you have to compile the package for one architecture at a time
in the source code directory. After you have installed the package for
one architecture, use `make distclean' before reconfiguring for another
Installation Names
By default, `make install' will install the package's files in
`/usr/local/bin', `/usr/local/man', etc. You can specify an
installation prefix other than `/usr/local' by giving `configure' the
option `--prefix=PATH'.
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
give `configure' the option `--exec-prefix=PATH', the package will use
PATH as the prefix for installing programs and libraries.
Documentation and other data files will still use the regular prefix.
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
Optional Features
Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.
For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.
Specifying the System Type
There may be some features `configure' can not figure out
automatically, but needs to determine by the type of host the package
will run on. Usually `configure' can figure that out, but if it prints
a message saying it can not guess the host type, give it the
`--host=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name with three fields:
See the file `config.sub' for the possible values of each field. If
`config.sub' isn't included in this package, then this package doesn't
need to know the host type.
If you are building compiler tools for cross-compiling, you can also
use the `--target=TYPE' option to select the type of system they will
produce code for and the `--build=TYPE' option to select the type of
system on which you are compiling the package.
Sharing Defaults
If you want to set default values for `configure' scripts to share,
you can create a site shell script called `' that gives
default values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/' if it exists, then
`PREFIX/etc/' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.
Operation Controls
`configure' recognizes the following options to control how it
Use and save the results of the tests in FILE instead of
`./config.cache'. Set FILE to `/dev/null' to disable caching, for
debugging `configure'.
Print a summary of the options to `configure', and exit.
Do not print messages saying which checks are being made.
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
Print the version of Autoconf used to generate the `configure'
script, and exit.
`configure' also accepts some other, not widely useful, options.
Tux Typing for Windows
Updated Aug 25 2007
2006-present Lead Developer:
David Bruce <>
Previous Project Manager:
Sam Hart <>
Jacob Greig <>
Jesse Andrews <>
Original Windows Port by:
Olivier Dagenais <>
Windows Crossbuild by
David Bruce <>
(based on TuxMath Windows crossbuild by Yves Combe)
To install the binary package for Tux Typing for Windows:
1. Run the nsis installer file (e.g. tuxtype-1.5.11-win32-installer.exe)
2. Click to accept the terms of the GPL
3. Click OK to install in default path (C:\Program Files\TuxType) or
select alternate location (perhaps if you are logged in as a user
without privileges to write to C:\Program Files).
4. The installer will create menu entries and a desktop icon for Tux
Typing if permissions allow.
Please read the COPYING.TXT file for the copyright for Tux Typing,
and read the SDL-COPYING.TXT file for the copyright information for
SDL. Basically, this software is open-source and free-software.
# Modified to include support for NSIS Windows installer - David Bruce <>
SUBDIRS = data doc src
EXTRA_DIST = AUTHORS COPYING ChangeLog INSTALL README TODO tuxtype.lsm tuxtype.spec config.h autorun.inf tuxtype.ico
$(MKDIR_P) $(DESTDIR)$(prefix)/doc/$(PACKAGE)
$(INSTALL_DATA) $(srcdir)/ChangeLog $(DESTDIR)$(prefix)/doc/$(PACKAGE)/ChangeLog
$(INSTALL_DATA) $(srcdir)/tuxtype.lsm $(DESTDIR)$(prefix)/doc/$(PACKAGE)/tuxtype.lsm
$(MKDIR_P) $(DESTDIR)$(prefix)/share/$(PACKAGE)
$(INSTALL_DATA) $(srcdir)/tuxtype.ico $(DESTDIR)$(prefix)/share/$(PACKAGE)/tuxtype.ico
$(INSTALL_DATA) $(srcdir)/autorun.inf $(DESTDIR)$(prefix)/share/$(PACKAGE)/autorun.inf
-rm -f $(DESTDIR)$(prefix)/doc/$(PACKAGE)/ChangeLog
-rm -f $(DESTDIR)$(prefix)/doc/$(PACKAGE)/tuxtype.lsm
-rm -rf $(DESTDIR)$(prefix)/doc/$(PACKAGE)
-rm -f $(DESTDIR)$(prefix)/share/$(PACKAGE)/autorun.inf
-rm -f $(DESTDIR)$(prefix)/share/$(PACKAGE)/tuxtype.ico
-rm -rf $(DESTDIR)$(prefix)/share/$(PACKAGE)
# Now doing this in preferred way via AM_INIT_AUTOMAKE in
# Rule to build tar-gzipped distribution package
$(PACKAGE)-$(VERSION).tar.gz: distcheck
# Rule to build RPM distribution package
rpm: $(PACKAGE)-$(VERSION).tar.gz
rpmbuild -ta $(PACKAGE)-$(VERSION).tar.gz
# Rules needed to cross-build nsis Win32 installer under Linux
# Taken from tuxmath's - David Bruce
# This rule probably kludgy (hardcoded)- DSB
install-nsi-local: all
$(INSTALL) -d $(top_srcdir)/$(NSI_INSTALL_DIR)/data;
$(INSTALL) -d $(top_srcdir)/$(NSI_INSTALL_DIR)/docs;
(cd $(top_srcdir)/tuxtype/data ; tar cf - --exclude "" --exclude "*.in" --exclude "*~" --exclude \ "Makefile" --exclude "" --exclude CVS --exclude .xvpics --exclude "1[1-9].ogg" --exclude "2?.ogg" --exclude "*.svn*" * ) \
| ( cd $(top_srcdir)/$(NSI_INSTALL_DIR)/data ; tar xf -) ; \
(cd $(top_srcdir)/tuxtype/docs ; tar cf - --exclude "" --exclude "*.in" --exclude "*~" --exclude \ "Makefile" --exclude "" --exclude CVS --exclude .xvpics --exclude "1[1-9].ogg" --exclude "2?.ogg" --exclude "*.svn*" * ) \
| ( cd $(top_srcdir)/$(NSI_INSTALL_DIR)/docs ; tar xf -) ; \
cp $(top_srcdir)/COPYING $(top_srcdir)/$(NSI_INSTALL_DIR)/docs/COPYING.txt ; \
cp $(top_srcdir)/AUTHORS $(top_srcdir)/$(NSI_INSTALL_DIR)/docs/AUTHORS.txt ; \
cp $(top_srcdir)/INSTALL $(top_srcdir)/$(NSI_INSTALL_DIR)/docs/INSTALL.txt ; \
cp $(top_srcdir)/README $(top_srcdir)/$(NSI_INSTALL_DIR)/docs/README.txt ; \
cp $(NSI_DLL_DIR)/*.dll $(top_srcdir)/$(NSI_INSTALL_DIR) ; \
cp $(SUBDIRS)/tuxtype.exe $(top_srcdir)/$(NSI_INSTALL_DIR)/TuxType.exe ;
# cp $(NSI_DLL_DIR)/*.ttf $(top_srcdir)/$(NSI_INSTALL_DIR)/data/fonts ;
## Bundle in fonts for distribution tar.gz to be used without package manager:
## i.e. to make tarball to post for individual download - use 'make distcheck' for Debian.
## (thanks to Ralf Wildenhues <> for automake help!)
$(MAKE) $(AM_MAKEFLAGS) distdir=$(PACKAGE)_w_fonts-$(VERSION) dist_fonts='AndikaDesRevG.ttf DoulosSILR.ttf lohit_hi.ttf Rachana_w01.ttf' dist
install-nsi-am: install-nsi-local
nsis: install-nsi-local
$(MAKENSIS) -NOCD nsis/tuxtype.nsi
if test -d $(NSI_INSTALL_DIR); then \
rm -fr $(NSI_INSTALL_DIR); \
\ No newline at end of file
This diff is collapsed.
\ No newline at end of file
Building TuxType for Windows on a Debian System:
David Bruce <>
TuxType can be cross-built for Windows on a Debian (or probably nearly
any Linux or Unix) system. The process closely follows the work done
by Yves Combe <> for a cross-build of TuxMath. I adapted
the TuxType svn source as follows to get this to work:
- Copied and from tuxmath unmodified.
- Modified to check for mingw32 build.
- Copied nsis/ from tuxmath's nsis/ with
very minor modifications (basically different program name).
- Modified by adding code from tuxmath's to
support nsis installer as makefile target, with some modifications.
- Minor changes to tuxtype's C source code:
- Added local function prototype for print_at() in practice.c.
- Several additional debugging output statements added.
- int_rand() as defined in playgame.c did not work correctly in
Windows, replaced using rand() % in several locations.
- WORD_qty counter didn't work right under Windows (could not
figure out why!), added simple code to count words in list
within WORDS_use() rather than rely on counter.
Before the crossbuild can be done, you need to get the environment prepared.
(Below taken from Tuxmath docs with very slight editing)
To set up a crossbuild environment:
1. Install mingw32 (apt-get install mingw32) and makensis (apt-get install nsis)
NOTE: the versions of the mingw32 packages in Etch work fine, but the newer
ones currently in Sid (specifically mingw32-binutils 2.17.50) fail, at least
on my amd-64 host.
2. Create directory structure:
- mkdir /usr/local/cross-tools
- mkdir /usr/local/cross-tools/i586-mingw32msvc
- mkdir /usr/local/cross-tools/i586-mingw32msvc/lib
- mkdir /usr/local/cross-tools/i586-mingw32msvc/include
3. Install precompiled win32�dev files (lib and includes) for SDL, SDL-image
SDL-ttf, and SDL-mixer in the lib and include directories you just created.
You can get all of these from I had some trouble with
this step as the SDL libs have varieties intended for both mingw32 and MSVC -
I was able to build successfully using the mingw32 ones. I also had to put
all the lib files directly under /usr/local/cross-tools/i586-mingw32msvc/lib
to get it to work. My /usr/local/cross-tools/i586-mingw32msvc/lib contains:
dbruce@debian:/usr/local/cross-tools/i586-mingw32msvc/lib$ ls
asprintf.lib jpeg.dll SDL_image.dll SDL_ttf.dll zlib1.dll
charset.lib libgw32c.a libSDLmain.a SDL_image.lib smpeg.dll
iconv.lib libpng12.dll libtiff.dll SDL_mixer.dll vorbis.dll
intl.lib libSDL.dll.a ogg.dll SDL_mixer.lib vorbisfile.dll
(asprintf.lib, charset.lib, iconv.lib, and intl.lib are definitely not needed.
Some of the others may not be needed, either, but I guarantee that everything
that *is* needed is on this list - DSB).
The header files can be in their own folders as long as they are under
4. Install libgw32c (the dev file): in the same directory.
This gives you the file "libgw32c.a" that you need to have in the lib directory.
5. You need to have a directory containing all of the dlls that will need to be
packaged into the installer. The Makefile expects them to be in NSI_DLL_DIR,
which is set to ~/tuxtype_dll. On my machine, I have:
dbruce@debian:~/tuxtype_dll$ ls
jpeg.dll ogg.dll SDL_mixer.dll vorbis.dll
libpng12.dll SDL.dll SDL_ttf.dll vorbisfile.dll
libtiff.dll SDL_image.dll smpeg.dll zlib1.dll
(Note - this has mostly the same files as the cross-tools lib directory - it is most
likely possible to eliminate this redundancy in some way.).
6. If you have done a native (Linux) build in the same source tree, run "make clean"
and "make distclean" to get rid of the autogenerated files.
7. From the trunk dir, run:
./autoreconf --install
./ --with-sdl-prefix
./ nsis
You should now have the installer (something like "tuxtype-1.5.11-win32-installer.exe")
in the trunk directory. Execute the installer on the target Windows machine to install
the program.
\ No newline at end of file
Tux Typing :
An Educational Typing Tutor Game Starring Tux, the Linux Penguin
20 August 2007 - NOTE: the below instructions are very old, and I
do not know if they work. I do not use nor have access to MSVC. The
recent Windows builds of Tux Typing have all been done on my Debian
machine using the mingw cross-tools (see "README-CROSSBUILD.txt").
My earlier attempts to set up a build environment under Windows using
either Cygwin or mingw32/msys were not successful. If anyone works
out a successful way to build Tux Typing (or TuxMath) on Windows,
please let me know and I will post it here.
David Bruce <>
You need to have the development versions of SDL, SDL_Image and
SDL_Mixer, that is the .lib, .h and .dll files. They also need to be
in VC's search path:
Under "Include Files", add the directories where the include files for
all three projects are.
Under "Library Files", add the directories where the .lib files for
all three projects are.
Olivier Dagenais (Win32 Port)
Sam "Criswell" Hart (Tux Typing project manager)
-Clean up this TODO and reflect the current status!
-Replace the five remaining files which are non-free accoring to
Debians Free Software Guidelines with free ones. click.wav and
kmus(1-4).wav are only free for non-commercial use.
-check that SVN is free of generated files. create release-script,
keep release tarballs (after is run) in SVN?
-Test it under MacOSX and windows
-make the code use UTF8 internally
-fix the font handling issues
-Clean up code! (Someone beat it severely with the "oogly stick"!)
o SOUND: I think the way laser.c handles sound playing should
be adopted by the rest of the app (via a function so we don't have
all these "if (sys_sound)" all over the place
o COMET ZAP: clean up the way text is generated... right now
it is being generated every time! -- plus maybe switch to the
AA text
--- idea: once the player gets "done" with a wave, they can
continue playing on the wave until they are ready
to move on. They do so by hitting a key
(ENTER/SPACE ??) which causes TUX to destroy all
comets at once!
o OBJECTs: ClearObject, EraseObject, ... needs to be reworked.
while these are "objects", I think we should retitle these
sprites, as clearobject, eraseobject does not do what one
might think (removing from memory)... Plus we can probably
simplify the "realeraseobject" vs. "eraseobject"
o LOCALE: gettext & locales... enough said
o MAKE STUFF: Cal is working on it for *nix. We need to make
sure we can build for others (win, mac).
o THEMES: after gettext is set up, a way to specify font,
fontsize, and other graphical options for the theme...
(on top of the already supported images)
--- Currently when we are loading a image, it will first
search through all the theme paths, and then it will
search through all the default paths, which is nice
except when the theme has "icons" for the menu. Then
the program will try to load as many icons and since
a theme may use fewer images than the default images,
the theme will have EXTRA frames that shouldn't be
o INPUT: can TT2 determine if the user presses "fancy" latin
characters such as n~, ... I don't know... a way to test
exists now though :)
o TRANSLATION: once we have gettext working, TT2 will be less
of a moving target for translators...
o Tux Recommend: add tux giving friendly reminders about proper
hand location, erogomics, ...
The following is a mail with a list of ideas, this is not really a todo (yet).
From: Steve McCuen <>
Date: Wed, 16 May 2007 20:25:15 -0700
Message-Id: <>
Subject: [Tuxmath-devel] tuxtype: feature request list, for comment
This is the list of requests that came from students using tuxtype. In
looking at the list, some are very possible to do.
* More kinds of games
* Some suggested maybe a racing game
* Some suggested pinball typing the right letters would make the
flippers work
* Space wars, and battle games with space ships
* Different background music
* Different colors
* Different backgrounds
* Practice typing letter groups (finger exercises like Mavis)
* In fish arcade, when you type the letter it highlights in Red, which
is hard to see.
* Too much repetition within the games there are
* More short words, and generally more variety in words and letters
* High score list
* More diversity in difficulty, not just speeding up
* Bonus points, and get more weapons, and rebuild cities
* More then just comets that come down
* Younger grades suggested the following:
* Fish Cascade to go slower
* Say the letter as they come down
* Not only saying the words, make the words tell a story
* Stops when you miss a letter and gives you a chance to get it right.
* More levels in Fish Cascade and Comet Zap
* Ability to choose whether one comet will destroy a city, or several
* Levels to be longer and harder before switching
* In Space Cadet, get points for hitting target, and takes away if you
miss, and if a city is destroyed it doesn't take away points.
* More shields
This diff is collapsed.