Announcement: Axiom, a Forth Based Universal Game Programming System
dream...@yahoo.com
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
> 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:
>
>
> 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
Outstanding work Greg! Forth will certainly benefit from your project.
Regards
Jean-Francois Michaud
Marcel Hendrix
[..]
> 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
dream...@yahoo.com
> dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System
> [..]
>
> > 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:
The gist of it is:
Andrew Haley wrote:
> 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.
> 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.
>
> 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
> 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.
>> 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
dream...@yahoo.com
> 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.
> 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
Andrew Haley
> On Aug 27, 1:00 pm, m...@iae.nl (Marcel Hendrix) wrote:
>> dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System
>> [..]
>>
>> > 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.
> This was discussed in the following thread:
> The gist of it is:
> Andrew Haley wrote:
>> 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.
dream...@yahoo.com
wrote:
[On supporting CREATE .. DOES>]
> 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
> 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
two part question:
>Do you care to discuss why it has <BUILDS, and why there's a unified stack?
-- Greg
Andrew Haley
> On Aug 28, 11:29 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> [On supporting CREATE .. DOES>]
>> 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
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.
Marcel Hendrix
> On Aug 27, 11:41 pm, m...@iae.nl (Marcel Hendrix) wrote:
>> 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
Andrew Haley
> dream...@yahoo.com wrote:
>> On Aug 28, 11:29 am, Andrew Haley <andre...@littlepinkcloud.invalid>
>> wrote:
[ 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.
dream...@yahoo.com
wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> wrote:
> > dreamwa...@yahoo.com wrote:
> >> On Aug 28, 11:29 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> >> wrote:
>
> [ 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
> 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.
> 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
dream...@yahoo.com
> dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System
>
> > On Aug 27, 11:41 pm, m...@iae.nl (Marcel Hendrix) wrote:
> 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.
>
> 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
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
sl...@jedit.org
wrote:
> 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
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
> 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.