Announcement: Axiom, a Forth Based Universal Game Programming System

[d***@yahoo.com]

If you are interested in programming abstract strategy games, puzzles,
and a variety of other related applications (or you are just
interested in novel Forth applications), you might be interested in
"Axiom". Axiom is a universal game development system that works in
conjunction with the "Zillions Of Games" (tm) product. It is in the
form of a plug-in DLL engine for Zillions. Axiom has its own complete
Forth based scripting language as opposed to the built-in Lisp like
language included in the Zillions product. Axiom provides its own
search engine, allows the game AI to be customized, supports math, and
in general, allows a high degree of customized programming. Due to
the full power of Forth being available for game programming, Axiom
extends the range of games possible with the Zillions product.

You can find the Axiom development kit (which includes documentation)
along with several Axiom based games at:

http://www.zillions-of-games.com/cgi-bin/zilligames/submissions.cgi/46102?theme=39

Also, there is a yahoo group dedicated to Axiom:

http://games.groups.yahoo.com/group/axiom-system/

The Zillions of Games (tm) product is a commercial product, however
you can download the development kit and the Forth based Axiom games
for free. You need to purchase the Zillions product in order to play
these and Zillions games, however if your interest is limited to
examining the game programming, then you can look at the included *.
4th files.

Due to the fact it is Forth based, it may not be for everyone. In the
yahoo group, there has been some backlash to using Forth (e.g. "Why
didn't you use Java?). However, my personal experience has been that
Forth is an excellent language for this purpose.

I am not affiliated with the Zillions product in any way. I'm a Forth
enthusiast and Axiom has been a hobby project which I am offering to
the public for free. I've been working on Axiom and the current set
of Axiom based games for the past 1-1/2 years in my 'spare' time.

Thank you for your interest.

-- Greg Schmidt

[Jean-François Michaud]

Post by d***@yahoo.com
If you are interested in programming abstract strategy games, puzzles,
and a variety of other related applications (or you are just
interested in novel Forth applications), you might be interested in
"Axiom". Axiom is a universal game development system that works in
conjunction with the "Zillions Of Games" (tm) product. It is in the
form of a plug-in DLL engine for Zillions. Axiom has its own complete
Forth based scripting language as opposed to the built-in Lisp like
language included in the Zillions product. Axiom provides its own
search engine, allows the game AI to be customized, supports math, and
in general, allows a high degree of customized programming. Due to
the full power of Forth being available for game programming, Axiom
extends the range of games possible with the Zillions product.
You can find the Axiom development kit (which includes documentation)
http://www.zillions-of-games.com/cgi-bin/zilligames/submissions.cgi/4...
http://games.groups.yahoo.com/group/axiom-system/
The Zillions of Games (tm) product is a commercial product, however
you can download the development kit and the Forth based Axiom games
for free. You need to purchase the Zillions product in order to play
these and Zillions games, however if your interest is limited to
examining the game programming, then you can look at the included *.
4th files.
Due to the fact it is Forth based, it may not be for everyone. In the
yahoo group, there has been some backlash to using Forth (e.g. "Why
didn't you use Java?). However, my personal experience has been that
Forth is an excellent language for this purpose.
I am not affiliated with the Zillions product in any way. I'm a Forth
enthusiast and Axiom has been a hobby project which I am offering to
the public for free. I've been working on Axiom and the current set
of Axiom based games for the past 1-1/2 years in my 'spare' time.
Thank you for your interest.
-- Greg Schmidt

Outstanding work Greg! Forth will certainly benefit from your project.

Regards
Jean-Francois Michaud

[Marcel Hendrix]

***@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System
[..]

Post by d***@yahoo.com
I am not affiliated with the Zillions product in any way. I'm a Forth
enthusiast and Axiom has been a hobby project which I am offering to
the public for free. I've been working on Axiom and the current set
of Axiom based games for the past 1-1/2 years in my 'spare' time.
Thank you for your interest.

Great idea! You paid attention to doumentation too, and your Forth seems
to really deserve that name (being interactive). Do you care to discuss
why it has <BUILDS, and why there's a unified stack?


BTW, strange game player, Zillion :-) I tried it's chess, but it doesn't
even know when the game is over (I took its king after only 3 moves, but it
pretends not to notice).

It does know how to play tic-tac-toe, though (unfortunately, I do too).

-marcel

[d***@yahoo.com]

Post by Marcel Hendrix
[..]

Post by d***@yahoo.com
I am not affiliated with the Zillions product in any way. I'm a Forth
enthusiast and Axiom has been a hobby project which I am offering to
the public for free. I've been working on Axiom and the current set
of Axiom based games for the past 1-1/2 years in my 'spare' time.
Thank you for your interest.

Great idea! You paid attention to doumentation too, and your Forth seems
to really deserve that name (being interactive). Do you care to discuss
why it has <BUILDS, and why there's a unified stack?

ForthScript is subroutine threaded and implemented in C++. I couldn't
see any way
to implement CREATE ... DOES> without dropping into assembly which I
didn't want to do.

This was discussed in the following thread:

http://groups.google.com/group/comp.lang.forth/browse_thread/thread/43e2a017cfddfcb9/bdb18346b1fc8951?lnk=gst&q=gschmidt&rnum=3#bdb18346b1fc8951

Post by Marcel Hendrix
and the thunk is a magic bit of machine code, usually a single
instruction, that is placed in the threaded code immediately before
the DOES> action. This works with any kind of threading.

As far as a unified stack, I'm not sure what you mean. ForthScript
has both a data stack and a return stack.
It supports words such as (>R, R>, R, R@ etc.). Was there something
you found in the documentation that lead
you to believe there was a single stack?

Please let me know if I'm missing something on either one of these
points.

Post by Marcel Hendrix
BTW, strange game player, Zillion :-) I tried it's chess, but it doesn't
even know when the game is over (I took its king after only 3 moves, but it
pretends not to notice).

Hmm... It's Chess is pretty strong, especially considering it's a
general game playing
program. If you are able to make this happen again, please save the
game (in a *.zsg file)
and send it to me. I can then post it and have the Chess Guru's
examine it.

Post by Marcel Hendrix
It does know how to play tic-tac-toe, though (unfortunately, I do too).
-marcel

Thank you for your comments and thanks to everyone for the kudos.

Regards,
-- Greg

[Marcel Hendrix]

Post by d***@yahoo.com
As far as a unified stack, I'm not sure what you mean. ForthScript
has both a data stack and a return stack.

[..]

But floating-point numbers are on the data stack, as 32-bit numbers.
IMHO, these are very unfortunate design decisions.

Post by d***@yahoo.com

Post by Marcel Hendrix
BTW, strange game player, Zillion :-) I tried it's chess, but it doesn't
even know when the game is over (I took its king after only 3 moves, but it
pretends not to notice).

Hmm... It's Chess is pretty strong, especially considering it's a general game playing
program. If you are able to make this happen again, please save the game (in a *.zsg file)
and send it to me. I can then post it and have the Chess Guru's examine it.

I only tried the Demo version and didn't realize the best it can do is play
'Loser Chess'. Apparently the rules are quite different. Probably a great
idea in the context of a demo for an extensible system.

-marcel

[d***@yahoo.com]

Post by Marcel Hendrix
But floating-point numbers are on the data stack, as 32-bit numbers.
IMHO, these are very unfortunate design decisions.

Pardon my ignorance on this, but besides less stack juggling, what do
you see as the main advantages of having a separate floating point
stack?
So far, in my limited applications to game programming, I haven't run
into difficulties, but then I don't typically perfrom extensive mixed
mode calculations.

Post by Marcel Hendrix
I only tried the Demo version and didn't realize the best it can do is play
'Loser Chess'. Apparently the rules are quite different. Probably a great
idea in the context of a demo for an extensible system.

Right, I forgot that the demo is 'Loser Chess'. I agree with your
rationale, although some objected to putting a 'Loser' game in the
demo.

-- Greg

[Marcel Hendrix]

Post by d***@yahoo.com

Post by Marcel Hendrix
But floating-point numbers are on the data stack, as 32-bit numbers.
IMHO, these are very unfortunate design decisions.

Pardon my ignorance on this, but besides less stack juggling, what do
you see as the main advantages of having a separate floating point
stack?

Is less stack juggling not compelling enough?

Source code clarity: with a unified stack, you are never completely sure
that there is not a float involved somewhere, whereas with a separate
stack you simply write
: x ( adam bertha -- xantippe ) ( F: r -- cos{r} ) ... ;

Then there is efficiency: a separate stack works much faster when you
use the hardware FPU or SSE2 unit. Most fast Forths use a separate
FP stack, so your code can never be directly used on/ported to/checked
through them.

With a separate FP stack you switch to double or quad precision without
rewriting any code. (Say you want your Fractal generator upgraded to
256 bits with Julian Noble's ideas.)

-marcel

[d***@yahoo.com]

Post by Marcel Hendrix
Is less stack juggling not compelling enough?

Yes it is. I just wanted to make sure I wasn't overlooking other
important points
surrounding the issue.

Post by Marcel Hendrix
Source code clarity: with a unified stack, you are never completely sure
that there is not a float involved somewhere, whereas with a separate
stack you simply write
: x ( adam bertha -- xantippe ) ( F: r -- cos{r} ) ... ;
Then there is efficiency: a separate stack works much faster when you
use the hardware FPU or SSE2 unit. Most fast Forths use a separate
FP stack, so your code can never be directly used on/ported to/checked
through them.
With a separate FP stack you switch to double or quad precision without
rewriting any code. (Say you want your Fractal generator upgraded to
256 bits with Julian Noble's ideas.)
-marcel

I see, I'll consider these points as well, thanks!

-- Greg

[Krishna Myneni]

Post by d***@yahoo.com

Post by Marcel Hendrix
Is less stack juggling not compelling enough?

Yes it is. I just wanted to make sure I wasn't overlooking other
important points
surrounding the issue.

Post by Marcel Hendrix
Source code clarity: with a unified stack, you are never completely sure
that there is not a float involved somewhere, whereas with a separate
stack you simply write
: x ( adam bertha -- xantippe ) ( F: r -- cos{r} ) ... ;
Then there is efficiency: a separate stack works much faster when you
use the hardware FPU or SSE2 unit. Most fast Forths use a separate
FP stack, so your code can never be directly used on/ported to/checked
through them.
With a separate FP stack you switch to double or quad precision without
rewriting any code. (Say you want your Fractal generator upgraded to
256 bits with Julian Noble's ideas.)
-marcel

I see, I'll consider these points as well, thanks!
-- Greg

While all of the above arguments in favor of a separate fp stack have some
validity, collectively they may give the impression that Forth code written for
a unified/shared stack is hard to write, hard to document, and sluggish. Such a
conclusion should be met with skepticism. Some of the earliest Forth systems,
e.g. the LMI Forths featured a unified stack, and they were quite successful in
their day. I have worked extensively with a shared stack system, and even ported
a good bit of common Forth code to such a system:

http://ccreweb.org/software/kforth/kforth4.html

It may be that a separate stack system is now more compelling, given that it is
the common practice. However, should you decide to continue with a shared stack
system, I urge you to consider making fp numbers be double floats which occupy
two stack cells, rather than 32-bit fp numbers. Although it seems unlikely, and
the situation may never arise in your application, I have run into limitations
with the precision of 32-bit floats. Originally, in the days of DOS, I used
32-bit floats in an application named xyplot, to conserve memory. Now, I
actually have data which I cannot plot with this program, because the number of
significant digits is insufficient. This limitation is forcing a rewrite of a
good-sized program.

Krishna Myneni

[s***@jedit.org]

Post by Krishna Myneni
Originally, in the days of DOS, I used
32-bit floats in an application named xyplot, to conserve memory. Now, I
actually have data which I cannot plot with this program, because the number of
significant digits is insufficient. This limitation is forcing a rewrite of a
good-sized program.
Krishna Myneni

Changing the floating point precision should not require a *rewrite*.

Slava

[Krishna Myneni]

Post by s***@jedit.org

Post by Krishna Myneni
Originally, in the days of DOS, I used
32-bit floats in an application named xyplot, to conserve memory. Now, I
actually have data which I cannot plot with this program, because the number of
significant digits is insufficient. This limitation is forcing a rewrite of a
good-sized program.
Krishna Myneni

Changing the floating point precision should not require a *rewrite*.
Slava

By "rewrite" I mean that the C++ files have to be examined, and data which is
declared as "float" must be changed to "double". Similar changes must me made to
the class declarations. I'm not sure that a simple global replace will suffice.
For example, there may be explicit casts of double numbers to float, which
should be removed. Also, casts from float to double will be redundant and should
be removed. I would be uneasy with a global replace, without doing a careful
examination of the code in parallel.

XYPLOT's built-in Forth interpreter does use double floats (two cell fp numbers
on a shared stack), so none of the Forth modules will have to change, except for
a couple of interface words which are responsible for moving data back and forth
between the Forth environment and the C++ portions.

Krishna

[John Passaniti]

Post by Krishna Myneni
By "rewrite" I mean that the C++ files have to be examined, and data which is
declared as "float" must be changed to "double". Similar changes must me made to
the class declarations. I'm not sure that a simple global replace will suffice.
For example, there may be explicit casts of double numbers to float, which
should be removed. Also, casts from float to double will be redundant and should
be removed. I would be uneasy with a global replace, without doing a careful
examination of the code in parallel.

Incidentally, this is why most C/C++ programmers heed the advice to use
an abstracted data type from the start. This is most commonly done with
"int" since it can vary in size depending on platform. But switching
between float and double can present the same issues.

typedef double Real;

That (or a better symbol name) in a common header file addresses the
problem.

[Andrew Haley]

Post by d***@yahoo.com

Post by Marcel Hendrix
[..]

Post by d***@yahoo.com
I am not affiliated with the Zillions product in any way. I'm a Forth
enthusiast and Axiom has been a hobby project which I am offering to
the public for free. I've been working on Axiom and the current set
of Axiom based games for the past 1-1/2 years in my 'spare' time.
Thank you for your interest.

Great idea! You paid attention to doumentation too, and your Forth seems
to really deserve that name (being interactive). Do you care to discuss
why it has <BUILDS, and why there's a unified stack?

ForthScript is subroutine threaded and implemented in C++. I
couldn't see any way to implement CREATE ... DOES> without dropping
into assembly which I didn't want to do.

Other people have done it. It's far from being impossible. I don't
know enough about exactly how your threading scheme works to comment
on how exactly to do it in your system.

Post by d***@yahoo.com
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/43e2a017cfddfcb9/bdb18346b1fc8951?lnk=gst&q=gschmidt&rnum=3#bdb18346b1fc8951

Post by Marcel Hendrix
and the thunk is a magic bit of machine code, usually a single
instruction, that is placed in the threaded code immediately before
the DOES> action. This works with any kind of threading.

As far as a unified stack, I'm not sure what you mean.

Your question was re "history and rationale for CREATE vs. <BUILDS"
and had nothing at all to do with unified stacks.

Andrew.

[d***@yahoo.com]

On Aug 28, 11:29 am, Andrew Haley <***@littlepinkcloud.invalid>
wrote:

[On supporting CREATE .. DOES>]

Post by Andrew Haley
Other people have done it. It's far from being impossible. I don't
know enough about exactly how your threading scheme works to comment
on how exactly to do it in your system.

For details on ForthScript's threading, see section 5 "Internals
within "ForthScript.pdf" that is part of the Axiom development kit at:
http://www.zillionsofgames.com/cgi-bin/zilligames/submissions.cgi/16178?do=show;id=1452

Post by Andrew Haley
Your question was re "history and rationale for CREATE vs. <BUILDS"
and had nothing at all to do with unified stacks.

True enough, that reference was my response to part one of Marcel's

Post by Andrew Haley
Do you care to discuss why it has <BUILDS, and why there's a unified stack?

-- Greg

[Andrew Haley]

Post by d***@yahoo.com
[On supporting CREATE .. DOES>]

Post by Andrew Haley
Other people have done it. It's far from being impossible. I don't
know enough about exactly how your threading scheme works to comment
on how exactly to do it in your system.

For details on ForthScript's threading, see section 5 "Internals
http://www.zillionsofgames.com/cgi-bin/zilligames/submissions.cgi/16178?do=show;id=1452

OK, that all looks pretty conventional. To implement CREATE .. DOES>,
your DOES> should modify the CFA of the most recently created word.
As as example, consider something like

: const create , does> @ ;

DOES> makes the CFA of the most recently created word point into the
middle of the list of CFAs inside CONST, and then DOES> exits from
CONST.

The list of CFAs in CONST looks like this, with "&" meaning the CFA of
the following word:

& CREATE & , & DOES> & (DODOES) & @ & , & EXIT

So, when you do

CONST FOO

you create a new word whose CFA points to the address of (DODOES)
within the body of CONST. The action of (DODOES) is somewhat system
dependent, but it needs to get the address of the parameter field of
the current definition.

Andrew.

[Andrew Haley]

[ a bunch of stuff, mostly wrong ]

Sorry, I realized my error too late. The CFA points to code, not a
pointer to code, so this won't work. There's a level of indirection
missing.

Andrew.

[d***@yahoo.com]

Post by Andrew Haley
[ a bunch of stuff, mostly wrong ]
Sorry, I realized my error too late. The CFA points to code, not a
pointer to code, so this won't work. There's a level of indirection
missing.
Andrew.
From the thread I referenced earlier, the conclusion was that solving

this would be problematic
at the C++ level. Here's the relevant quote:

[> My compiler supports tail recursion optimization so a long chain
of

Post by Andrew Haley
calls does not use the return stack.
Even so, to implement ;CODE in a way that supports CREATE DOES> would
seem to require dropping down into assembly to make things work.

It would, yes.

Post by Andrew Haley
Maybe that's not even possible as it just occured to me that with
the tail recursion optimization, the return address wouldn't even be
available on the machine stack.

You could drop into assembler and handle it yourself. It's only a
few
instructions, after all.

Andrew. ]

-- Greg