-
6.
Alright, maybe I'll try this thing. How do I get started?
-
a.
Other Glulx/Glk References & Library Add-Ons:
infglk Wrapper Reference
- Attached to this guide is a summary of Glk functions as they appear wrapped
in infglk.h. Covered are their: purposes, arguments, and return values.
So essentially, it is a brief "reference manual" to all Glk functions.
Interpreter & Color Charts
- Two charts are also attached to this guide. A chart of interpreters, showing
the Glk capabilities each currently supports. And a color chart with their
corresponding hexadecimal
notations.
unglklib
I have also written a demo Glulx Inform multimedia game, "Just a
Dream," that comes with an
easy
add-on Glk library for those who want to
get "up and running" with Glk quickly. Also included is
"briefglk," A Brief Overview of Glk for the Inform Programmer, with
some examples from unglklib, and "Dream's" source code. "Just a
Dream" also functions as an interpreter "tester," because the
score is a test of what Glk capabilities (except the ability to play MODs) the
player's interpreter supports.
3/2009
- "Vistas," a demo of glk screen transtitions has also been added.
dunno-bp.h
and
phtalk-bp.h
are dunno.h and phtalkoo.h altered for Glulx Inform (the first altered by
Zarf, the second by me). Dunno by Neil Cerutti apes the Infocom response
"I don't know the word ____." Phtalk by David Glasser simulates Adam
Cadre's menu system from Photopia.
Roger Firth's
Just Enough Glulx
provides a header file for some basic Glk functions.
The Game Author's Guide to Glulx Inform
- Andrew Plotkin's guide covers all the new routines added to Inform, including
Glk entry points, but it does not really detail Glk.
Gull
- Adam Cadre's guide focuses on how to actually use Glk to write multimedia
Glulx Inform games. Several excellent demo games with source code are included.
Glk API Specifications
- Andrew Plotkin's Glk specifications are not a users' manual. They are
designed for interpreter C-language programmers (remember, Glk is an API for
interpreters) -- so great deal of information is not pertinent to Informers.
However, a full explanation of window trees is given.
Note that the following section about iblorb has not been updated.
Evidentially the Window Glulxe interpreter now supports combining a separate
game file (.ulx) with a separate blorb archive (.blb). However, I am not aware
that any other interpreter currently supports that, so the below remains as is.
-
Using iblorb
-
Iblorb
is a Dos/Windows blorb file maker written by L. Ross Raszewski. It packs graphic
images and sound
files
into an
archive file. Currently, Glulxe does not support having a blorb resource file
separate
from the game file. So the game file is also packed into the archive. While
this done, your Inform source code (.inf) is also complied.
The iblorb.zip file contains four executables: Front End (the users'
front end) - front.exe, Bres.exe - the blorb control block creator which also
calls
the Inform compiler, Blc.exe - the blorb file packer, and Bpal.exe - a blorb
palette manager. However, you only need to
run front end, the rest is done for you.
Steps:
-
If you are using Windows, open a Dos window or exit to the Dos prompt.
-
Create a resource file with the same name as your game and the extension of
.res -- mygame.res. This will list the
pictures and sounds you want to use in your game. For all but the source code,
each item is preceeded by a bres identifier: CODE, PICTURE, or SOUND.
The next word is the Inform constant that you will use in your source code to
refer to
that particular image or sound. Last is the path to each item.
Identifier Constant Path
mygame.res
CODE drive:\path\mygame.ulx
PICTURE Mypic drive:\path\mypic.jpg
SOUND Mysnd drive:\path\mysound.mod
Use the extension, .ulx, for the source code (not .inf), even though it hasn't
been compiled yet. You may also put on the last line HIGHCOLOR to include
directions for a 16-bit palette, or TRUECOLOR for 32-bit.
-
Create a file called infb.rc, telling Front End the name of the inform
compiler you are using and the path to the
Bres executable. This works best though if you unzip all iblorb's
executables into the same directory as your source code and compiler. If you do
put them in
the same directory, you can drop the last line.
infb.rc
INFORM informbp -G or informg
BRES drive:\path\bres (no extension)
The g switch tells the bi-platform compiler to generate a Glulx Inform
g-machine game file,
not an Inform z-machine game file.
-
Now put this line in your source code: #include "mygame.bli" (this is created
by Bres,
telling Blc which blorb to combine with the source code).
-
Run front end by entering: front mygame mygame.inf mygame.ulx. The first
argument is the resource file (.res) without the extension. Viola! Front end
complies your source code
(calling the Inform compiler) and creates the blorb file all at the same time.
The new file
is called mygame.blb and can be loaded into a Glulxe interpreter.
-
Necessary Programs & Files:
Inform compiler
|
Bi-platform Glulx Inform compiler
(or single platform Glulx compiler)
|
Inform library
|
Bi-platform Glulx Inform library
|
Inform interpreter
|
Glulxe interpreter
|
|
infglk.h
|
|
Glk library
|
Just as you need an certain platform-specific files to write a regular Inform
game -- you need the same thing to
write Glulx Inform game. You also need two additional files: the
wrapper include file, infglk.h, and a Glk library for your platform. Since Glk
is a
portable
API, it is separate. But,
luckily, most interpreters come bundled with it.
All can be found at
http://www.ifarchive.org/indexes/if-archiveXprogrammingXglulx.html
. You can also find some at Zarf's
Glulx
page.
-
Oh, one last question. Why do Glulx and Glk have such funny names?
Zarf moves in mysterious ways.
My Reasons for Not Continuing Support
These pages were in a middle of a rewrite (2001) when I stopped support.
Parts One & Four have been rewritten;
Parts Two & Three Contain some factual
errors -- mainly about styles. (Check with Brief Glk for more accurate
presentation.)
But I am leaving this tutorial up to help anyone it might help.
3/2009
- I think I have fixed most of the errors, if not please let me know.
While writing "
Carma,
" I discovered that Glulx is not truly cross platform compatible. And, as
far as I know, the various platform conflicts have never been resolved, ergo my
withdrawal of support. Glulx seems to be interpreter-writer friendly and
game-writer non-friendly. My memory
of the conflicts is foggy now (and I never fully understood the
"interpreter" details), but to summarize:
-
Windows/Linux
- Inconsistencies in how game code was interpreted between the Windows
interpreter and the Linux interpreter. This cropped up in two main areas,
screen draws and the glk entry point, HandleGlkEvent. For me this meant that
when I developed a game in Windows that worked, I had to tweak it like crazy to
also get it to work with the Linux terp.
-
Linux
- The Linux interpreter lacked code (that was
supposed
to be in the interpreter) to correctly draw certain types of jpegs. So two
people wrote patches to make the Linux terp work with "Carma" and its
intensive graphics approach. (The
patches
are at the archive.)
-
Linux
- Ditto with sound files, patches had to created to handle "Carma's"
sounds/music.
-
Windows/Mac
- Sound files created under Windows, for some reason -- something to do with
bit signing -- do not work with the Mac. Or, to be specific, do not work with
QuickTime, the Mac terp's sound handler. This was the
major
platform incompatibility.
-
Windows/Mac
- Ditto with graphic files, QuickTime could not do the "animations"
that I had developed under Windows and that also ran fine with Linux. Although
this was not a file incompatibility, it amounted to the same
thing -- "Carma" would not run well on the Mac.
I complained about the above incompatibilities and asked for graphic and sound
file standardization, got patted on the head, and basically ignored
(I hate that).
For instance, the argument regarding the Windows/Linux code implementation
differences seemed to be, "If I had written the code right in the first
place then it would have worked with both." In other words, my code was
buggy, not the interpreters. However, there is a big flaw with that argument --
there is not enough Glulx documentation and/or example source code to know
when
a specific coding approach is right or not (especially when trying something
tricky)! Also, personally, I do not believe there should be that big a
difference in how each interpreter interpretes code from one platform to
another.
I want to say that I think Window's Glulxe works just great thanks to David
Kinder. But be warned, if you want your Glulx game to also be played by Linux
and/or Mac players, you may be in for a big disappointment and/or a lot of
debugging. And even then it may not work. OTOH, a game developed with the Linux
or Mac terp will probably work fine under Windows. But check it out with the
"other" terp too -- Linux or Mac. And note that these
incompatibilities
have also been experienced by everyone writing a Glulx game, not just me --
although "Carma" is probably the most graphic/sound intensive Glulx
game written to date.
I've always maintained that I am a
game
writer, not an
interpreter
writer, ergo it is not my job to fix or compensate for interpreters. And,
frankly, I see no flaw in
that
argument. ;-) So while I really like Glulx's windowing system, I'm outta here!
Doe 7/29/03
Part One
Part Two
Part Three
Top of Page
Appendix One
(infglk Wrapper Reference)
Appendix Two
(Interpreter & Color Charts)
doeadeer3@aol.com
|