Implementation details.- Each game is itself an unmodified starkit. Each starkit's vfs resides as a subdirectory of the main directory of the Game pack starkit
- Each game is launched in its own slave interpreter.
- Most of the starkits were pulled unmodified from sdarchive. I found a couple of dozen more games on the wiki and at tclapps that I starkitified and added in. Some of these needed a "package require Tk" added.
- I did have to modify one game dots and boxes because it was trying to do some things with the console that didn't work in a slave interpreter.
- The interface for selecting games is an outline from tkoutline. The full functionality of tkoutline is also available (see the miscelleneous category) just because it is there.
- I find the interface to be a bit cluttered, but using an outline was the easiest way for me to get this working (and I am motivated to make use of my own code).
- Adding a new game involves adding a new description to a text file and adding a new .vfs directory for that game.
applauncher.tcl - loads descriptions from applauncher text file into an outline
applauncher - Tcl formatted list of application descriptions
tkoutline.vfs
contents of tkoutline starkit
app1.vfs
contents of app1 starkit
app2.vfs
contents of app2 starkit
.
.
.
appn.vfsWay cool! I've wondered for a long time when someone would take the initiative on this ;) -jcwOther bundles could easily be created. Some ideas:
- iGamePaq - Bundle of games that fit well on the iPaq
- DeveloperPack - ramdebugger, tkinspect, tkcon, tkreplay
- EditorPack - collection of Tcl editors
Error reports[Removed information about package require Tk error that has been fixed]UKo 2005-02-23: What are these fixed errors about? There still is an error can't find package Tk every time a game is launched -- if wishkit (8.4.9) is used on Mac OSX. The problem is in the initial auto_path of a slave interpreter. This doesn't contain an entry for the path where the Tk-shared-library can be found (it's not the same place as for the Tcl-shared-library). A workaround is to set the complete path after cloning a new interp in function runSlaveKit:
+ $s eval [list set auto_path $::auto_path]
$s eval [list set argv $args]Brian Theado - 2005-02-24: Thanks for this report. I made the change to runSlaveKit as you suggested. Let me know if it works for you.It seems to me that this may be a bug in wishkit. I would expect a brand new slave interpreter to look identical to the main interpreter upon startup. If the main interpreter has a certain auto_path at startup, then why wouldn't a slave interpreter have the same? The variables argc, argv, and argv0 don't get set in a slave interpreter, but I think those are different from auto_path and it is reasonable to not set them. I guess there could be an argument either way for auto_path, but IMO the overriding argument should be consistency. Since tclsh and tclkit set auto_path in the slave, then why not wishkit.BTW, the other package require Tk error [1] was due to a missing package require Tk, not an error when package require Tk executes.Discussion about keysym error (which has been fixed) moved to Cross platform keysyms.
If you get an error like "couldn't open setup.tcl, no such..." when launching a game like Felipe Voloch reported, then try getting the latest version of tclkit. Any tclkits built in 2004 or later (and probably some in 2003) contain the fix for launching starkits in slave interpreters.
JSI 25feb05 Concerning further updates: I'd propose to keep a current copy of tkgamepack.kit on sdarchive, so SDX.KIT update could keep my local starkit current, updating only changed content. Having it on sourceforge may provide more visibility, but why not use fantastic work already done in the distributed deployment arena? (insert applause!) :-)Brian Theado - I plan to make future versions available to sdx update. I just initially put it somewhere where I could have quick turnaround time for making new versions as I worked out the initial bugs.Update 23Mar05 - I haven't uploaded to sdarchive yet, but I did add starsync capability to the download. The following will work to update your starkit:
sdx update -from http://tkoutline.sourceforge.net/cgi-bin/sync.cgitkgamepack.kit
LV Brian, I dropped a note on comp.lang.tcl and this response was posted:It's a really cool thing, but there is a little bug (that should be quite easy to fix): The embedded hyperlinks (both games and internet-addresses) of the main window fire on *any* mousebutton, which also includes the scrolling wheel (mapped to buttons 4 and 5). So when I scroll down with my wheelmouse, it "randomly" opens games and mozilla instances.Have a look at <http://avl.enemy.org/TclTk/
> there are some games (among other stuff) lying around there. Some are one-file scripts, that might be quite easy to integrate... I'm happy to accept patches to make them or the others better integrateable.Brian Theado - Thanks. The bindings have been fixed and now only button-1 launches anything.MG March 27 2005 - Not sure if this should go here or on Tk Game Pack, but most seem to be here. I was just playing "Patience", and when I closed it (the game, not the bundle), Wish crashed. (Didn't get a Tcl error.) This was playing it in ActiveTcl 8.4.9, on Win XP SP2. I've put the data Windows gave me when it asked to send an Error Report below, though I don't know how much help it'll be, if any.
AppName: wish84.exe AppVer: 8.4.2.9 ModName: unknown ModVer: 0.0.0.0 Offset: 00c708b8Brian Theado - Thanks for the report. I also see the crash when I close Patience. I will take a look at the patience code sometime and see if I can figure it out. Other problems:
- convolutions exits with "attempt to call eval in deleted interpreter" error
- bubble swap exists with an error due to an attempt to write a high score file within the readonly starkit. Maybe the high score file should be written to the home directory.
- many of the games don't set the title of their window and the title ends up being "main." I should have tkgamepack automatically detect this and change the title to be the same as the starkit name.
