Forth Graphics Games ??
Dru Nelson
I'm interested in Forth and games..
Did anybody write any complete graphical games
in Forth (I'm sure someone did).
(Like a defender or asteroids or ...)
If so, is there any source available to one of
those around or left?
Please email me as well as posting..
Dru
dne...@slip.net
Paul E. Bennett
I remember that with some stuff I got from my vendor there were a couple of
simple games with source code. I am sure other vendors have some small token
games. You'd have to ask them about it though. I never played the games as I
have enough other things to do.
--
Paul E. Bennett ................... <p...@transcontech.co.uk>
Transport Control Technology Ltd. <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861 <enq...@transcontech.co.uk>
Going Forth Safely
Lars Krueger
In article <5snosr$o3t$1...@owl.slip.net> dne...@slip.net "Dru Nelson" writes:
>
> I'm interested in Forth and games..
>
> Did anybody write any complete graphical games
> in Forth (I'm sure someone did).
> (Like a defender or asteroids or ...)
>
> If so, is there any source available to one of
> those around or left?
>
> Please email me as well as posting..
I'm currently writing a board game in F-PC. If I'm right the English name is
"Three men's manor" or
something ( in German "Muehle")
The board looks like this: ( use a monospaced font )
+------------+---------------+
| | |
| +-------+----------+ |
| | | | |
| | +---+----+ | |
| | | | | |
+----+---+ +-----+----+
| | | | | |
| | +---+----+ | |
| | | | |
| +-------+----------+ |
| | |
+------------+---------------+
I want to give it an artificial (un)intelligent computer enemy
using a Q-learning. Let it play against itself for
-- let's say -- 24 hours and you will have a hard time to defeat it.
When there is enough room in F-PC's code space (the q-weights take
18kb and a few bytes) I add some 3D toys like a 3D board and
animated 3D figures.
At the moment there is no graphics in it ( board like above, just
using PC-line characters).
When it is done I put it on my web-page ( see signature ).
--
Lars Krueger
mailto:ai...@rz.tu-ilmenau.de
URL: http://www.rz.tu-ilmenau.de/~ai108
James Coupe
In article <5sp0iv$f...@news.sns-felb.debis.de>, Lars Krueger <krueger@br
adley.dbag.ulm.DaimlerBenz.COM> writes
> If I'm right the English name is
>"Three men's manor"
I think the general name in England is Nine Man's Norris (I'm english,
but I don't know for certain - it's not a very popular game nowadays).
If someone does update Starting Forth, can I suggest this as an example
program, rather than how to calculate volumes of sand and stuff like
that. A simple game like Space Invaders or Breakout (the bat, ball and
bricks game) would be my choice. Of course, a fairly simple 'proper'
application for Forth would be needed as well (as other people have
suggested, some sort of GUI or something like that which at least people
know about so they haven't got to think too hard about the actual thing
the code does as opposed to how the code works).
If not, can someone release a fairly simple source code for these sort
of games for us newbies to have a poke at and see if we can work out
what they're doing.
--
James Coupe (remove .nospam to reply by e-mail)
I think I saw another ship in the sky today. A big white one. I've never seen
a big white one. Only six small black ones. Perhaps six small black ones can
look like one big white one. Perhaps I would like a glass of whisky. Yes, that
seems more likely.
Darrell Johnson
Sorry 'bout that, just fixed my reply address.
(silly thing changed in one part of Netscape,
but I didn't restart news :)
Darrell "will program for food" Johnson
(you don't really think the *SPAMBEGONE* is part of my e-mail address,
do you?)
T.W.Wor...@ncl.ac.uk
Dru Nelson <dne...@slip.net> wrote:
<snip>
>Did anybody write any complete graphical games
>in Forth (I'm sure someone did).
>(Like a defender or asteroids or ...)
>
>If so, is there any source available to one of
>those around or left?
I don't think this is what you were asking for but as far as I know the
original arcade machine version of Missile Command was supposed to have
been coded in Forth. I don't think Williams will let you have the source
code, though!
Thomas Worthington
James Coupe
In article <33F304...@nt.com>, Darrell Johnson <DARR...@nt.com>
writes
>I'm not English (Canuck eh?), but I played the game as a child, and I'm
>pretty
>sure it's Nine Man's Morris (it could have been misspelled, of course).
I couldn't remember and just plumped for one of them.
You don't like that explanation?
Well, "N" is next to "M" on the keyboard.... ;)
Darrell Johnson
James Coupe wrote:
>
> In article <5sp0iv$f...@news.sns-felb.debis.de>, Lars Krueger <krueger@br
> adley.dbag.ulm.DaimlerBenz.COM> writes
> > If I'm right the English name is
> >"Three men's manor"
>
> I think the general name in England is Nine Man's Norris (I'm english,
> but I don't know for certain - it's not a very popular game nowadays).
>
I'm not English (Canuck eh?), but I played the game as a child, and I'm
pretty
sure it's Nine Man's Morris (it could have been misspelled, of course).
> If someone does update Starting Forth, can I suggest this as an example
> program, rather than how to calculate volumes of sand and stuff like
> that. A simple game like Space Invaders or Breakout (the bat, ball and
> bricks game) would be my choice. Of course, a fairly simple 'proper'
> application for Forth would be needed as well (as other people have
> suggested, some sort of GUI or something like that which at least people
> know about so they haven't got to think too hard about the actual thing
> the code does as opposed to how the code works).
>
The problem with making this sort of example program is that the code
would have to depend on the operating system, or at least the machine.
The Forth virtual machine does not have a bitmapped graphical output.
You would have to pick from a rather large array of standards and lose
the universality (if that's a word :) of the example code.
It's kind of sad to think that even today, the only truly universal
standard is the teletype display (serial text output with carriage
returns).
Even files aren't completely universal (files vs. blocks flame wars).
> If not, can someone release a fairly simple source code for these sort
> of games for us newbies to have a poke at and see if we can work out
> what they're doing.
>
> --
>
> James Coupe (remove .nospam to reply by e-mail)
>
There are many assembler source code examples for graphics; if you want
to code games you probably need to use assembler in some parts anyways.
Luckily, Forth makes incorporating assembler easy; try including the
graphics
set-up code in a Forth program and then just use a pointer to the video
memory (I recommend using double-buffer copy assembler to cut down on
flicker).
A good starting point is:
http://www.resourcium.com/
Tons O' resources for the budding (and experienced) game developer.
James Coupe
>would have to depend on the operating system, or at least the machine.
>The Forth virtual machine does not have a bitmapped graphical output.
>You would have to pick from a rather large array of standards and lose
>the universality (if that's a word :) of the example code.
Hmm... I see. I don't suppose there's any chance of this being added by
the ANSI people? Obviously, it would be incredibly difficult to do with
all the various graphics platforms around at the moment, so probably
isn't worth the trouble and Forth doesn't need graphics that much.
However, it would be nice if forth could be used to program games since
it does seem (to me) to be the 'perfect' language, ignoring the lack of
graphics engine. I mean, it gives you the ability to subroutine stuff
(or rather, makes you subroutine stuff) which is what is done in games
all the time. I've seen semi-professional flow-charting (it was an
example done by the Darling or Oliver people at Codemasters (reponsible
for Dizzy - the egg games) for a magazine competition example). It
break everything down into threads (how to do the movement of the
character, how to do the title screen and stuff) and it seems like once
you'd got a few words defined, you'd have the basics of a games engine
where the words could be effortlessly combined (more or less) to get the
game.
The other thing is that games are a popular form of programming. I, for
instance, would like to program for a living when I am older. If
possible, I would like to learn to program and program for a living in
Forth but if I actually want to get employed I'll probably have to learn
C (or it's ++ version), PASCAL or something like that. Showing that
Forth can do stuff other than, as is popularly perceived, programs for
little hand held calculators and portable devices, could help to improve
it's popularity, and we all know that Forth can get stuff that would
probably take tens of thousands of bytes of code in C can be got down to
a lot less due to the nature of it's programs.
Though it isn't a good thing, the graphic interface does seem to be here
to stay (Windows, Macs etc.) so it might be time for Forth to take a
look at it's stance on graphics and, maybe, think about incorporating
some new graphic words into it's vocabulary, if not just for helping to
keep it afloat. As said, that could water down the language when you
get floods of people coming into it without a clue of what it's really
about, but it could help to keep Forth going for a fair few more years
yet.
--
James Coupe (remove .nospam to reply by e-mail)
I think I saw another ship in the sky today. A big white one. I've never seen
Marcel Hendrix
T.W.Wor...@ncl.ac.uk wrote Re: Forth Graphics Games ??
> Dru Nelson <dne...@slip.net> wrote:
> <snip>
> >Did anybody write any complete graphical games
> >in Forth (I'm sure someone did).
> >(Like a defender or asteroids or ...)
> >
> >If so, is there any source available to one of
> >those around or left?
> <snip>
Sorry for the indirect response.
The iForth distribution comes with gorillas.frt. This is a port of a
Quickbasic (graphics) game that came with MS-DOS 5.0 (gorillas.bas).
This is a straight BASIC -> Forth translation and absolutely not recommended
for educational purposes. I just wanted to see if all the concepts and "hooks"
(input of numbers, graphics, sounds, error recovery..) for writing graphics
games were available in iForth.
There a number of very simple other games available too, but most of them
simply use coloured text:
Directory of C:\DFWFORTH\EXAMPLES\GAMES
[.] [..] makesys.bat maze.dat glife.frt
gorillas.glo tictacto.frt tetris.frt tetra.frt squash.frt
pacman.frt mutant.frt mastmind.frt gorillas.frt gorexe.frt
go.frt four-row.frt eliza.frt duncan.frt anagrams.frt
bomber.frt life.frt adventur.org adventur.frt
25 File(s) 173,475 bytes
Writing a good game is just a lot of hard work, and what to do with it once
it is finished? Play with it?
-marcel
odie
If you're interested in seeing an example game in windows using
Win32Forth, you can look at:
http://www.geocities.com/SiliconValley/Pines/7826/
I'm still cleaning up the source code a bit, but I will email it to
anyone who wishes to look at it.
-mike
mi...@americanmeter-wv.com
Marcel Hendrix
od...@the.sunday.comics (odie) writes Re: Forth Graphics Games ??
Quite spectacular for a 400K windows program, *far* better than I remember
from a lot of the tiresome PD game-CD stuff out there. Color, sounds, help,
highscore and all that, no need for any setup procedure, and no problems
with NT.
I really enjoyed playing with it for a while. This is certainly something I
can and will show to others. Let's hope that goes for the source code too
:-)
-marcel
Darrell Johnson
Dru Nelson wrote:
>
> I'm interested in Forth and games..
>
> in Forth (I'm sure someone did).
> (Like a defender or asteroids or ...)
>
> If so, is there any source available to one of
> those around or left?
>
>
> dne...@slip.net
Come to think of it, that sounds like fun. I'll stick to 16-bit 80x86
DOS real mode and double buffered VGA 13h graphics, no sound. I'll have
to grab the keyboard and timing interrupts for smooth control. It'll
probably be a bit heavy on CODE definitions. I'll post the code here
(comp.lang.forth), if there are no objections (if someone has a better
place to put it let me know). Expect to see a "space invaders" style
game in the next week or two. I think I'll make a series of it.
Darrell Johnson
(drop *SPAMBEGONE* to reply)
Disclaimer: I speaks for meself an' noone eltse.
Mike Coughlin
>I'm interested in Forth and games..
>Did anybody write any complete graphical games
>in Forth (I'm sure someone did).
>(Like a defender or asteroids or ...)
>If so, is there any source available to one of
>those around or left?
Tetris has been written in ANS Forth for an ANSI computer
terminal (usually called VT100 emulation). It is included
in Gforth and even works on my computer (Sun 3/80 Unix).
You can find new versions of Gforth at prep.ai.mit.edu and its mirrors
or at
http://www.complang.tuwien.ac.at/forth/gforth/
or
ftp://ftp.complang.tuwien.ac.at/pub/forth/gforth/
Another interesting item in the graphic games department was
a maze drawing and solving program from a very old out of print
issue of Forth dimensions that I saw running on Will Baden's
port of F83 for the Apple II. I think the authors are still using
Forth and might republish if enough interested people nagged them.
--
Michael Coughlin mi...@gnu.ai.mit.edu Cambridge, MA USA
Curtis R. Anderson
Darrell Johnson wrote:
> Come to think of it, that sounds like fun. I'll stick to 16-bit 80x86
> DOS real mode and double buffered VGA 13h graphics, no sound. I'll have
> to grab the keyboard and timing interrupts for smooth control. It'll
> probably be a bit heavy on CODE definitions. I'll post the code here
> (comp.lang.forth), if there are no objections (if someone has a better
> place to put it let me know). Expect to see a "space invaders" style
> game in the next week or two. I think I'll make a series of it.
It would be fun to see posted here. But it sounds like a lot of work to
do.
--
Curtis R. Anderson, Co-creator of "Gleepy the Hen", SP 2.5?, KoX
http://www.servtech.com/public/cra/ | Illegitimus non Carborundum
ftp://ftp.servtech.com/pub/users/cra/ | Don't let the bastards
mailto:gle...@intelligencia.com | grind you down
Darrell Johnson
James Coupe wrote:
>
> In article <33F304...@nt.com>, Darrell Johnson <DARR...@nt.com>
> writes
> >The problem with making this sort of example program is that the code
> >would have to depend on the operating system, or at least the machine.
> >The Forth virtual machine does not have a bitmapped graphical output.
> >You would have to pick from a rather large array of standards and lose
> >the universality (if that's a word :) of the example code.
>
> Hmm... I see. I don't suppose there's any chance of this being added by
> the ANSI people? Obviously, it would be incredibly difficult to do with
> all the various graphics platforms around at the moment, so probably
> isn't worth the trouble and Forth doesn't need graphics that much.
>
>
> Though it isn't a good thing, the graphic interface does seem to be here
> to stay (Windows, Macs etc.) so it might be time for Forth to take a
> look at it's stance on graphics and, maybe, think about incorporating
> some new graphic words into it's vocabulary, if not just for helping to
> keep it afloat. As said, that could water down the language when you
> get floods of people coming into it without a clue of what it's really
> about, but it could help to keep Forth going for a fair few more years
> yet.
>
Personally, I oppose the idea of adding graphics to the Forth standard.
The possibities of graphics platforms are too diverse to account for in
a single standard. I prefer proprietary libraries for each platform: if
you want to be portable write your ideal interface in Forth and change
the code behind the interface to use the appropriate library for each
platform. You will have more flexibility in a library you design to
represent your set of target platforms than a universal one as well as
keeping down the complexity to the minimum needed for your application.
Darrell Johnson
*SPAMBEGONE* be gone lest e-mail falleth into the hell of invalid
addesses
I am not now the avatar of the mighty NORTEL, I have free will and these
words flow from my own mind.
Let no man confuse that which I spew forth with that which would the
mighty NORTEL, my very temporary employer.
(Don't you find standard disclaimers boring?)
Matt J. Gumbley
>In article <5snosr$o3t$1...@owl.slip.net>, Dru Nelson <dne...@slip.net> wrote:
>
>>I'm interested in Forth and games..
<snip>
Many moons ago, I used to write games in Forth on a Sinclair ZX
Spectrum, using a version of Forth called "White Lightning". It had
its own graphics library, and some of the programs I wrote were quite
impressive (if I say so myself :-). It was the first Forth I'd used,
and thinking about those days gone by has rekindled my interest in
Forth. I've just downloaded Win32Forth, and F-PC, and several other
Forths for other platforms... now all I need are copies of Leo
Brodie's books :-)
Anyone else on this NG remember White Lightning? It was written by
Oasis Software, if I recall...
Ah, fond memories.... back to hacking this C++ :-(
Regards,
Matt
Matt Gumbley | Email: | Nothing is Irrelevant.
Research Assistant | csa49 @ | Nothing is Wasted.
Rm 106, Comp. Sci. | keele . | Everything is Transformed.
Dept., Keele Univ. | ac . uk | [These are my views, not necessarily
+44 (0)1782 583438 | | those of .cs.keele.ac.uk -- MJG]
Dru Nelson
Great replies, I also like that win32forth game.
Some noise though. Still, I didn't see any references to Missile
command source or (yeah, the game Ikari Warriors used forth, et).
Dependence on wierd graphics engines isn't a problem.
I just want to see a real live game that used graphics that might
have been popular in arcades or home systems available.
If not, ok, that's cool too.
(Please no discussion of what should be standard or about off topic
stuff)
Remembering a great C64 or ZX81 game is encouraged :-)
Can't wait to see the space invaders on F-PC...
Bernd Paysan
Darrell Johnson wrote:
> Personally, I oppose the idea of adding graphics to the Forth standard.
> The possibities of graphics platforms are too diverse to account for in
> a single standard.
They look much more different than they are. For MINOS, I need only few
things, and I can find them anywhere (in Windows, in MacOS, in X). I
need to draw lines, fill rectangles and polygons, draw text, copy images
and draw masked icons, all into windows and memory buffers clipped by
rectangles or regions (polygons). And receive pointer, keyboard, and
window manager events. The names of these functions are different, the
usage is different, and sometimes you have bugs to work around. But
after all, these things are burried in the lower level parts of MINOS,
the higher level parts keep all the same.
> I prefer proprietary libraries for each platform: if
> you want to be portable write your ideal interface in Forth and change
> the code behind the interface to use the appropriate library for each
> platform. You will have more flexibility in a library you design to
> represent your set of target platforms than a universal one as well as
> keeping down the complexity to the minimum needed for your application.
Hm, this is my approach (since there is no standard), but why not make
the results standard? Since graphic user interfaces require the user to
keep some drawing context, the OO layer I use is suited best to hide
that context. My drawing objects all have a state, while the system
below might not.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
Robin Ziolkowski
Mike Coughlin wrote:
<snip>
> Another interesting item in the graphic games department was
> a maze drawing and solving program from a very old out of print
> issue of Forth dimensions that I saw running on Will Baden's
> port of F83 for the Apple II. I think the authors are still using
> Forth and might republish if enough interested people nagged them.
>
> --
> Michael Coughlin mi...@gnu.ai.mit.edu Cambridge, MA USA
The above mentioned maze generating game was part of a games package
available from FIG. The game came with source. I have taken this
program and adapted it to include a solving algorithem that uses
cellular automata. The program runs on a PC. If anyones interested I
could dig it up and email it to them. Come to think of it; does anyone
know if I have to ask the authors permission to do this?
Regards
Robin
Wil Baden
Robin Ziolkowski (Robin.Zi...@itron.com) wrote:
I presume that this is the the maze program I wrote for my F83 Extension.
Of course you have my permission. Would you be so kind to send me a
copy, please?
I _just_ now remembered that my maze program did solve itself, so it's
something different. Oh well.
--
Wil Baden WilB...@Netcom.com
Mycroft
Darrell Johnson wrote:
.> James Coupe wrote:
.> >
.> > In article <33F304...@nt.com>, Darrell Johnson
<DARR...@nt.com>
.> > writes
.> > >The problem with making this sort of example program is that the
code
.> > >would have to depend on the operating system, or at least the
machine.
.> > >The Forth virtual machine does not have a bitmapped graphical
output.
.> > >You would have to pick from a rather large array of standards and
lose
.> > >the universality (if that's a word :) of the example code.
I don't think that's really that much of a problem. Sometimes it seems
Forthers are too hung up on the "but it won't run on a VAX 11" deal.
There are tons of books out there on writing graphics programs for
languages like C and C++. Basically two approaches are taken. One,
simply write the examples for one particular platform. It will be
useful for programmers using that platform and other programmers
at least have some sample code to work from. Personally I would like
to see a book like "wiz bang graphics programming using Win32Forth",
or something of that nature. Approach two, use some standard graphics
library that has been, or is being, ported to many platforms such as
OpenGL.
For the purposes of writing a graphics tutorial in Forth a decent
graphics
API could be built on a rather simple set of graphics primitives. Those
being PIXELSET, PIXELREAD, BITBLT, BITMAPCREATE, BITMAPDESTROY and
BITMAPDISPLAY. From there you could build a set of primitives that
would be good enough to create simple games such as Pac Man.
.> >
.> > Hmm... I see. I don't suppose there's any chance of this being
added by
.> > the ANSI people? Obviously, it would be incredibly difficult to do
with
.> > all the various graphics platforms around at the moment, so
probably
.> > isn't worth the trouble and Forth doesn't need graphics that much.
.> >
.> > <snip>
.> >
.> > Though it isn't a good thing, the graphic interface does seem to be
here
.> > to stay (Windows, Macs etc.) so it might be time for Forth to take
a
.> > look at it's stance on graphics and, maybe, think about
incorporating
.> > some new graphic words into it's vocabulary, if not just for
helping to
.> > keep it afloat. As said, that could water down the language when
you
.> > get floods of people coming into it without a clue of what it's
really
.> > about, but it could help to keep Forth going for a fair few more
years
.> > yet.
.> >
.>
.> Personally, I oppose the idea of adding graphics to the Forth
standard.
.> The possibities of graphics platforms are too diverse to account for
in
.> a single standard. I prefer proprietary libraries for each platform:
if
.> you want to be portable write your ideal interface in Forth and
change
.> the code behind the interface to use the appropriate library for each
.> platform. You will have more flexibility in a library you design to
.> represent your set of target platforms than a universal one as well
as
.> keeping down the complexity to the minimum needed for your
application.
Well Java's GUI interface and OpenGL are strong counter examples to the
idea that you can't write a decent graphics user interface that will
port across different platforms. And if you use good software
engineering
techniques the result can still be something that takes advantage of
platform specifics such as 3D graphics hardware. For example, a
graphics
library initialization routine could first check for the existence of
the 3D hardware. If it existed it would load a set of words to render
using the hardware, otherwise it could load the equivalent set of
software
rendering words.
Mycroft
Darrell Johnson wrote:
.> Take another step back, look at the _really_ big picture. Windows,
.> MacOS, and X are very similar (in graphical capabilities), but Forth
is
.> used in many more places than personal computers. Look at platform
.> games, VCR displays, graphing calculators, screen phones, et cetera.
.> Besides, this thread is about games programming, which is usually
.> subject to very intense optimization. Third-party libraries are a
.> trade-off between performance and versatility; if you know exactly
what
.> your requirements are you can hard-code details like sprite size and
add
.> performance.
Well here's a bigger picture. Write now real time operating systems
are developing to run inside many of those embedded systems you just
described. QNX comes to mind as well as TAOS. I've never worked with
either, but the TAOS developers claim all you have to do to port TAOS
to any particular graphics system is BITBLT. I've tried a QNX demo.
It can fit an entire real time OS with an HTML browser/sever on a
single 1.44 bootable floppy and it can run on a 386. Considering
how cheap 386 processors are today it's not unthinkable to have
a 386 and a meg of ram inside a VCR. The operating systems I
mentioned all use C/C++ for their primary development system. Java
was originally designed for embedded systems, although it might be
too top heavy for pocket calculators now. I do know of at least
one real-time operating systems that is used for robot control
and is Java-ready though.
Also many game programmers are going the C/C++ route. AFAIK Doom was
written in, and many other game developers liscensed the 3D graphics
engine written for it. Doom has been ported to many non-PC platforms
including Linux, Nintendo 64, Atari Jaguar ect. You may be able to
tweak more performance out of your game by reinventing the wheel
each time, but will you get your "Doom-Killer" game to market before
the Quake-succesor game comes out?
.> IMHO Forth is about minimizing development time, bugs, and system
.> requirements, but at the cost (gain?) of requiring that the
programmer
.> be intimately familiar with the relevant features of the system he is
.> developing for. Any standard (or cross-platform library) must be
only
.> the intersection of the capabilities of its subject systems, with
other
.> capabilities lost. Trying to define a sweeping standard on a very
.> diverse range of machines will naturally lead to inefficiency and
.> encourage bizarre application programmer optimizations (try to make a
.> standard sprite engine for machines with hardware sprites of
different
.> sizes and color depths). I do like ANS Forth, as it is reasonably
small
.> and provides functionality which is easily implemented on a wide
range
.> of machines efficiently (by not trying to do too much and keeping in
.> mind the processors and standards which exist).
I don't think it's an either-or proposition. If a decent graphics
library for Forth that was easy to port was developed, a lot of
people, including myself, would use it. At any rate it would be
a nice teaching tool for those who wanted to lean graphics programming
in Forth without knowing the intricacies of the current Super-VGA
standard. And of course this is Forth we're talking about here.
If you don't like a particular graphics library standard that someone
might propose, you can always write your own.
Jeff Fox
Mycroft wrote:
>
> Well here's a bigger picture...
Well put.
> either, but the TAOS developers claim all you have to do to port TAOS
> to any particular graphics system is BITBLT.
I have considered posting my pet graphics words. In 1980 I began
using logical bitblt primitives for things as done in smalltalk. This
meant that most of the stuff I wrote was portable from environment
to environment. Intel 8080, Apple II, IBM PC, MuP21, F21, etc.
I am of the opinion that byte or cell based bitblock transfer/
logical operations is about all that is needed. They are
more useful for real time stuff than pixel operations and
there is really only one word with a few small variations.
However this approach means that manipulations of the bitmaps
are going to be system specific, but that's about it. You can
easily implement sprites, or windows, or widgets or whatever
in a portable way with primitives and easily optimize them
for a system with features you want to support.
> I don't think it's an either-or proposition. If a decent graphics
> library for Forth that was easy to port was developed, a lot of
> people, including myself, would use it. At any rate it would be
> a nice teaching tool for those who wanted to lean graphics programming
> in Forth without knowing the intricacies of the current Super-VGA
> standard. And of course this is Forth we're talking about here.
> If you don't like a particular graphics library standard that someone
> might propose, you can always write your own.
I really like the MEME system. It is Forth as a scripting language
for a RenderMan display engine, TCP/IP interface, and object tools.
It is the best thing I have seen for doing shared virtual reality
on the net. In fact the idea is quite portable since RenderMan
engines are available for many enviroments, and Forth and
everything else there is pretty portable.
I doubt if we will see it soon on an F21 system, but I have always
liked the idea of doing a cheap but compatible system for the
F21. One the subject of F21..
I put an update at my website about F21c coming back from MOSIS
and going to Norsk for packaging. I also added a page with
a little update on that Chess program we had here a few months
ago.
--
Jeff Fox jf...@dnai.com
Ultra Technology Inc. http://www.dnai.com/~jfox/
Darrell Johnson
Bernd Paysan wrote:
>
> Darrell Johnson wrote:
> > Personally, I oppose the idea of adding graphics to the Forth standard.
>
> They look much more different than they are. For MINOS, I need only few
> things, and I can find them anywhere (in Windows, in MacOS, in X). I
> need to draw lines, fill rectangles and polygons, draw text, copy images
> and draw masked icons, all into windows and memory buffers clipped by
> rectangles or regions (polygons). And receive pointer, keyboard, and
> window manager events. The names of these functions are different, the
> usage is different, and sometimes you have bugs to work around. But
> after all, these things are burried in the lower level parts of MINOS,
> the higher level parts keep all the same.
Take another step back, look at the _really_ big picture. Windows,
MacOS, and X are very similar (in graphical capabilities), but Forth is
used in many more places than personal computers. Look at platform
games, VCR displays, graphing calculators, screen phones, et cetera.
Besides, this thread is about games programming, which is usually
subject to very intense optimization. Third-party libraries are a
trade-off between performance and versatility; if you know exactly what
your requirements are you can hard-code details like sprite size and add
performance.
IMHO Forth is about minimizing development time, bugs, and system
requirements, but at the cost (gain?) of requiring that the programmer
be intimately familiar with the relevant features of the system he is
developing for. Any standard (or cross-platform library) must be only
the intersection of the capabilities of its subject systems, with other
capabilities lost. Trying to define a sweeping standard on a very
diverse range of machines will naturally lead to inefficiency and
encourage bizarre application programmer optimizations (try to make a
standard sprite engine for machines with hardware sprites of different
sizes and color depths). I do like ANS Forth, as it is reasonably small
and provides functionality which is easily implemented on a wide range
of machines efficiently (by not trying to do too much and keeping in
mind the processors and standards which exist).
Darrell Johnson
(Drop *SPAMBEGONE* to reply)
Standard disclaimer: the views expressed herein are not representative
of those of my employer.
"Keep it simple, as simple as possible, but no simpler."
-Albert Einstein
Jet Thomas
In <33FAFF...@nmisq2.miss.nt.com> Darrell Johnson <"
>> > Personally, I oppose the idea of adding graphics to the Forth
>> > standard.
>> They look much more different than they are. For MINOS, I need only
>> few things, and I can find them anywhere (in Windows, in MacOS, in
>> X).
>> <snip>
>Take another step back, look at the _really_ big picture. Windows,
>MacOS, and X are very similar (in graphical capabilities), but Forth
>is used in many more places than personal computers. Look at platform
>games, VCR displays, graphing calculators, screen phones, et cetera.
>Besides, this thread is about games programming, which is usually
>subject to very intense optimization. Third-party libraries are a
>trade-off between performance and versatility; if you know exactly
>what your requirements are you can hard-code details like sprite size
>and add performance.
OK, so the question is, are there things that Forth programmers should
do portably with graphics, that justify a standard? When you need
optimization you ignore the standard and do what works. When you need
portability you can accept an inefficient standard -- or if there isn't
one then you're just out of luck.
If we had a graphics standard that let us do some things portably, it
would make sense to try to make it optimizable. That is, you'd like to
be able to start with portable code and optimise it for a particular
system without having to rethink it from scratch. You might have to
throw away all the _code_, but you'd like to keep the algorithms if you
can.
So are there uses where we'd like to have portable graphics? My first
thought is for diagrams in source code. Right now our Forth source
code is 100% text. If you make a diagram you do it with ascii or you
do it with some commercial graphic system and have a bitmap. Portable
graphics would be useful there, but not enough to justify the effort.
Commercial drawing systems are good enough, we don't need to reinvent
that wheel and have yet another incompatible graphic protocol.
Similarly it would be useful in documentation to have occasional screen
captures etc, but not enough to justify the work.
Portable graphics would _require_ methods to zoom images and to display
parts of images. As soon as you try to port graphics you get size
problems. But that's two issues -- one is portable graphics code and
the other is portable graphics images. If you don't use the latter you
probably won't need the former either.
If you do things with portable graphics code, you'll get something
that's inefficient on all systems. If it's set up well, you could then
start replacing the lowest levels of it to make it more efficient on
your system while keeping the higher levels unchanged. You'd stop that
process at your particular point of diminishing returns, whenever it
came. If you do need to port graphics over wildly different hardware,
that might be a better way to do it than to rewrite from scratch with
no standard. But it would be easier to write good code for one system
first, and never think about the second system until you have to port
to a second system.
We could probably come up with a good bit-mapped standard. We might be
able to get a good subset that worked for raster graphics too. The
questions are, do we have a use for portable graphics, and is it worth
the effort?
Graham Chiu
In article <33f8635...@news.keele.ac.uk>, "Matt J. Gumbley"
<ma...@nospam.cs.keele.ac.uk.nospam> writes
>Anyone else on this NG remember White Lightning? It was written by
>Oasis Software, if I recall...
Yes. I still have a copy for the C64 ( or was it called something else?
). All the manuals were written on hard to read red paper presumably as
a form of copy protection. I tried to write a terminal program but gave
up on it as the stack occupied the memory addresses used for the serial
port! Clearly they hadn't thought about modem games in those days.
-------
Regards, Graham Chiu
Bernd Paysan
Bruce R. McFarling wrote:
>
> On a less serious note, how do you slow down the *Text* game TT
> (a tetris alike) included with Gforth? I'm wondering whether my upgraded
> computer at my other office is simply running so fast that assumptions
> about processing delays are simply being violated. Or is it normally
> jerky near the top and then rushes through the middle half of the
> tetris-alike box?
No, certainly not. We (read that Dirk Zoller, who wrote it) use "ms",
which depends on some OS features (usually uses "select", on DOS, we
used to poll DJGPP's gettimeofday). If it's jerky, it's either that the
OS doesn't give you a decent "ms", or the output buffer flush doesn't
work.
Eric Marsden
Mycroft <dr...@cis.uab.edu> writes:
> I don't think it's an either-or proposition. If a decent graphics
> library for Forth that was easy to port was developed, a lot of
> people, including myself, would use it. At any rate it would be
> a nice teaching tool for those who wanted to lean graphics programming
> in Forth without knowing the intricacies of the current Super-VGA
> standard. And of course this is Forth we're talking about here.
> If you don't like a particular graphics library standard that someone
> might propose, you can always write your own.
Why are we talking about Forth-specific graphics libraries? It seems
to me that the future for graphics, certainly for games programming,
lies in OpenGL. This API has a good track record on workstations,
scales well to $250 000 SGI machines, and is supported by cheap 3D
cards which are now appearing for PCs. Games such as Quake have been
ported to it.
The OpenGL API is slanted towards C; why not develop ways of
interfacing with it from Forth?
--
Eric Marsden
emarsden @ hotmail.com
It's elephants all the way down.
Jet Thomas
In <do3eo2v...@salines.cict.fr> Eric Marsden
<mar...@salines.cict.fr> writes:
>Why are we talking about Forth-specific graphics libraries? It seems
>to me that the future for graphics, certainly for games programming,
>lies in OpenGL. This API has a good track record on workstations,
>scales well to $250 000 SGI machines, and is supported by cheap 3D
>cards which are now appearing for PCs. Games such as Quake have been
>ported to it.
>The OpenGL API is slanted towards C; why not develop ways of
>interfacing with it from Forth?
That sounds good. If we built a nice factored set of Forth words that
get the benefits of OpenGL then that would be a good set of things to
emulate when we didn't have OpenGL to work with. And when OpenGL is
available it would be the obvious way to implement those words.
Darrell Johnson
Just so you don't think I'm forgetting about this project: things were
rough there for a while, but I've finally figured out how to properly
mix assembler into FPC (oh, the shame of forgetting NEXT). I've got
double-buffered graphics going, and the sprite engine is nearly
finished. I'm not sure whether FPC will be happy with me if I grab the
keyboard and timer interrupts, so that part may never get done. I will
definitely post it without perfectly smooth movement and control as soon
as the rest gets finished, as I'm sure there are people who would like
to write graphical turn-based games that don't require movement to
continue without input (this may be handy for Muehle, Lars).
Darrell Johnson
(Drop *SPAMBEGONE* to reply)
Standard disclaimer: the views expressed herein are not representative
of those of my employer.
"Keep it simple, as simple as possible, but no simpler."
-Albert Einstein
Note how considerately I've included a shorter yet more useful statement
from a notably more intelligent and wiser person; mail signatures:
altruism or merely an effort to legitimize by association?
Darrell Johnson
Note that I'm branching this thread so we can keep this discussion
without further annoying the game programmers.
Just to set the record straight, I am 100% OK with cross-platform GUI
libraries (though I think they're generally too slow for games, but that
was on the game thread). I'm only opposed to adding graphics to the
ANSI Forth standard. In my opinion ANSI Forth already covers enough
ground. I really like Win32Forth, I'd like it even more if some
altruistic group made a few changes to its interface and ported it to a
few more platforms so it was Win32/OS2/X/Be/MacForth or maybe just
GUIForth (I'm not volunteering ... yet). I just think that the standard
should really stay so general that it can be implemented on virtually
(if not literally) _all_ computer systems. Forth has a very strong
history as an embedded processor language, and now that we finally have
a real ANSI standard, lets not throw it away by adding features that
make it unsuited to many (most?) of it devotees. I never want the term
"creeping featurism" to apply to the Forth standard (to some
_implementations_ on the other hand ...). If you put something in the
standard, you are effectively saying, "You must use this or be subject
to mockery for reinventing the wheel." If you add a library, it's more
like, "Here's something you can use if you want to." I mean, wouldn't
you give somebody a weird look for writing a COPYTOS function (not an
alias, a CODE definition) that did the exact same thing as DUP?
In closing, a standard is the definition of the language. To claim that
you know a language you should be familiar with the entire standard.
Forth makes this easy by being small. Look at how big C++ is getting,
and even they aren't trying to make a graphics interface a part of the
language. I have read several articles now that say _nobody_ can
accurately claim to know all of C++ inside and out (I tend to agree,
given my own personal experiences). In Perl, nobody expects you to know
the whole language, it's made for hacking around in subsets, but don't
expect someone to trust their life to a Perl script. But one of the
greatest advantages of Forth is that you can learn to know exactly what
should happen for any reasonable code (and unreasonable code if you
include "Something really bad will happen." as exact knowledge ;).
BTW: if you want a relatively easily implemented GUI add-on to Forth
(and don't care about the performance hit), try embedding a TCL/TK
interpreter.
Jet Thomas
In <33FD93...@nmisq2.miss.nt.com> Darrell Johnson <"
darrell_johnson"@nmisq2.miss.nt.com> writes:
>I just think that the standard
>should really stay so general that it can be implemented on virtually
>(if not literally) _all_ computer systems. Forth has a very strong
>history as an embedded processor language, and now that we finally
>have a real ANSI standard, lets not throw it away by adding features
>that make it unsuited to many (most?) of it devotees. I never want
>the term "creeping featurism" to apply to the Forth standard (to some
>_implementations_ on the other hand ...). If you put something in the
>standard, you are effectively saying, "You must use this or be subject
>to mockery for reinventing the wheel." If you add a library, it's
>more like, "Here's something you can use if you want to."
That's exactly what the optional standard wordsets are. An
implementation doesn't have to include them, but if it does include
those names you know what they're supposed to do. Typically there will
be some words that are supposed to be there if the wordset is
implemented at all, and then other words that are even _more_ optional.
If your Forth includes the words and you use them, your code will be
portable to other Forths that include those words.
I'm not clear what words should be necessary in a graphics standard.
Back in the old days it seemed obvious to include POINT HLINE VLINE
LINE and maybe ARC . You can draw horizontal and vertical lines more
efficiently than others, so you separate those out. You can draw any
diagrams with those 5, if ARC is any piece of any ellipse at any angle.
But it sounds like these days some sort of BLITTER is more useful.
Then there's the question of screen size. With different screens and
particularly with different windows on one screen, you don't want the
images to be the wrong size. One obvious bad idea is to do all the
graphics in floating point so you can resize easily. Another approach
is to pick some arbitrary size for your fixed-point virtual graphics
screen (maybe 65536x65536), make all your graphics in those terms, and
resize from that. When I think as a user, I figure that any time an
image gets resized it might lose something I care about, so -- thinking
as a user -- I want to be able to look at the image its original size,
where maybe I get a porthole onto the image that I can look at it a
piece at a time. And I also want to be able to zoom it up and down so
I get to see the whole thing or details. And I want to be able to
change the aspect myself, or reset it to the default. That image is
for _me_ and I don't want somebody else deciding for me how I've got to
see it, I want to be able to see what I want.
So in that context, people maybe should make their images look good
with whatever display size they choose, and the user's system should be
able to resize anything to anything else.
Then there's color. Back in the old days that was obvious, you had
WHITE BLACK RED GREEN BLUE and a maybe a few others, with maybe LIGHT
and DARK or BRIGHT and NORMAL . I have no idea how to standardize
colors now. Again speaking as a user, I figure what I'd want would be
for the exporting system to have some way to say what its color range
and representation was, and the importing system should match that up
as best it can with its own colors, and I -- the user -- should get to
override those choices if I want to. Again, I have no idea how to
arrange that.
Then there are file formats. With filespace so cheap and access so
fast it can be easier to access file images than to draw them, even for
simple images. It would be good to have some way to manage graphic
files. We don't want to settle on particular file formats, all of
which will be obsolete in a few years, but it would be nice to have a
way to tell whether a particular format is available.
This is all a lot of work to think out. If we had people who were
actually using graphics with Forth, who could benefit from portability,
that would be a better way to drive the process than just some guys
thinking about what would be nice. Also that would give us a better
idea what's possible, as we looked at the problems they ran into. On
the other hand there are more pleasant ways to figure out the shape of
a wall than to ram your head into it repeatedly. If we could translate
somebody else's graphics standard that might make a better optional
standard for us than none at all, and it might be easier to deal with
than interfacing to their language for all our graphics needs.
Marcel Hendrix
jeth...@ix.netcom.com(Jet Thomas) writes Re: Forth Graphics Standard/Library was Re: Forth Graphics Games ??
>In <33FD93...@nmisq2.miss.nt.com> Darrell Johnson <"darrell_johnson"@nmisq2.miss.nt.com> writes:
>
>> If you put something in the
>>standard, you are effectively saying, "You must use this or be subject
>>to mockery for reinventing the wheel." If you add a library, it's
>>more like, "Here's something you can use if you want to."
> That's exactly what the optional standard wordsets are. An
> implementation doesn't have to include them, but if it does include
> those names you know what they're supposed to do. Typically there will
> be some words that are supposed to be there if the wordset is
> implemented at all, and then other words that are even _more_ optional.
> If your Forth includes the words and you use them, your code will be
> portable to other Forths that include those words.
My experience with iForth is that you can do pretty complex things with
just a handfull of library routines (in my case 45 words and 16 _standard_
color names for text output). It would be enough if the stack diagram of
these were standardized.
> I'm not clear what words should be necessary in a graphics standard.
> Back in the old days it seemed obvious to include POINT HLINE VLINE
> LINE and maybe ARC . You can draw horizontal and vertical lines more
> efficiently than others, so you separate those out. You can draw any
> diagrams with those 5, if ARC is any piece of any ellipse at any angle.
You can leave it to the library to do HLINE and VLINE instead of LINE. The
word POINT should be there for interactive use, but I'm sure that this will
be too slow in general (try defining a filled circle using POINT on Windows NT
and see what I mean:-) The reason some people want BITBLT is probably because
this ensures many bits are managed at once, and efficiency will not be an
issue (until some user defines POINT in terms of BITBLT :-)
[..]
> Then there's the question of screen size. With different screens and
> particularly with different windows on one screen, you don't want the
> images to be the wrong size. One obvious bad idea is to do all the
> graphics in floating point so you can resize easily.
Why not? For actually using the graphics this is ideal. One of iForths words
(not one of the 45 low-level ones) maps a floating-point usercoordinate system
onto a window size in pixels.
> is to pick some arbitrary size for your fixed-point virtual graphics
> screen (maybe 65536x65536), make all your graphics in those terms, and
> resize from that. When I think as a user, I figure that any time an
I write all iForth graphics apps using Xsize and Ysize (these are values
filled by the library). If these were constants you couldn't set dots or
draw lines efficiently, they would always be converted to drawing an array
of filled rectangles (or circles).
[..]
> Then there's color. Back in the old days that was obvious, you had
> WHITE BLACK RED GREEN BLUE and a maybe a few others, with maybe LIGHT
> and DARK or BRIGHT and NORMAL . I have no idea how to standardize
Define a color as a 3-byte packed vector (packed in a 32-bit word). A pointer
to structure is even better, because it allows to "paint with the pointed-to
bitmap". Also define a few standard colors for drawing text.
> Then there are file formats. With filespace so cheap and access so
> fast it can be easier to access file images than to draw them, even for
> simple images. It would be good to have some way to manage graphic
> files. We don't want to settle on particular file formats, all of
> which will be obsolete in a few years, but it would be nice to have a
> way to tell whether a particular format is available.
Define a library call that converts an image to a standard format
(or fails :) Given the color spec above, this should be a file of 32-bit
pixels, so it can be managed by the 45 library routines. It is nice to be
able to convert the bitmaps back to any other format (or to the OS "native"
format, whatever it may be).
[..]
-marcel
Paul E. Bennett
In article <33FD93...@nmisq2.miss.nt.com>
darrell_johnson@*SPAMBEGONE*nmisq2.miss.nt.com
"Darrell Johnson" writes:
> Note that I'm branching this thread so we can keep this discussion
> without further annoying the game programmers.
>
> Just to set the record straight, I am 100% OK with cross-platform GUI
> libraries (though I think they're generally too slow for games, but that
> was on the game thread). I'm only opposed to adding graphics to the
> ANSI Forth standard. In my opinion ANSI Forth already covers enough
> ground. I really like Win32Forth, I'd like it even more if some
> altruistic group made a few changes to its interface and ported it to a
> few more platforms so it was Win32/OS2/X/Be/MacForth or maybe just
> GUIForth (I'm not volunteering ... yet). I just think that the standard
> should really stay so general that it can be implemented on virtually
> (if not literally) _all_ computer systems.
The ANS/ISO standards for Forth are OK as far as they go. However, I feel
that there is, with Forth, an opportunity to multi-part the standard such
that the CORE and EXCEPTION word-sets were the first volume of the standard
along with the rest of the notes. Other word-sets could have occupied separate
standards documents as sub-parts (ie: ANSX3.215 Part 2 might have been the
DOUBLES word-set). There would have then been no problem in having different
word-sets for specific items like Graphics or Network Communications.
Application developers then only need the CORE (Part 1) plus the selected
other parts. The subsequent parts could be made available when they develop
instead of calling for an update of the whole standard each time. I have
made such comments to the ISO committee.
[%X]
--
Paul E. Bennett ................... <p...@transcontech.co.uk>
Transport Control Technology Ltd. <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861 <enq...@transcontech.co.uk>
Going Forth Safely
barrym
James Coupe (ja...@obeah.demon.co.uk.nospam) wrote:
:
: If someone does update Starting Forth, can I suggest this as an example
: program, rather than how to calculate volumes of sand and stuff like
: that. A simple game like Space Invaders or Breakout (the bat, ball and
: bricks game) would be my choice. Of course, a fairly simple 'proper'
: application for Forth would be needed as well (as other people have
: suggested, some sort of GUI or something like that which at least people
: know about so they haven't got to think too hard about the actual thing
: the code does as opposed to how the code works).
I'm not sure a game would be a good way to teach programming. Especially
not a graphics game. The change to and from graphics mode adds a little
complexity and that's not what you want for a beginner. He should be able
to focus on programming and syntax and looping, etc.
Also, any single project is less desirable, I think, in a tutorial, than
a lot of small examples geared directly to teach the subject at hand.
That also lets the student jump right into any chapter if he already knows
a few things but needs help with some certain aspect of the language.
Barry
Jet Thomas
In <3401B9...@nmisq2.miss.nt.com> Darrell Johnson <"
darrell_johnson"@nmisq2.miss.nt.com> writes:
>> In <33FD93...@nmisq2.miss.nt.com> Darrell Johnson <"
>> darrell_johnson"@nmisq2.miss.nt.com> writes:
>> >If you put something in the
>> >standard, you are effectively saying, "You must use this or be subject
>> >to mockery for reinventing the wheel." If you add a library, it's
>> >more like, "Here's something you can use if you want to."
>> That's exactly what the optional standard wordsets are. An
>> implementation doesn't have to include them, but if it does include
>> those names you know what they're supposed to do. Typically there will
>> be some words that are supposed to be there if the wordset is
>> implemented at all, and then other words that are even _more_ optional.
>> If your Forth includes the words and you use them, your code will be
>> portable to other Forths that include those words.
><snip>
>I think you missed my point. On the level of a compiler writer, if you
>want to put the same functionality in your implementation as is defined
>in an optional standard wordset, you are expected to use that "optional"
>wordset, and not some proprietary notation you dream up.
If your hardware or OS provides functionality that doesn't match the
standard, why _not_ use proprietary notation to describe it? It's nice if
you can implement whatever standard words apply too -- then your users can
import code designed for some other systems.
>On the level
>of an application programmer, if your version of Forth includes this
>optional wordset, you are expected to use it (again - or be subjected to
>mockery for reinventing the wheel).
Again, if you need better performance and you get it by using words that
you can't derive from the standard wordsets, who should complain? (If you
can derive your special words from standard ones, then if there's need you
can make a preamble that implements your words in a standard way -- then
your code becomes portable and you get to use your special efficient
constructions. It will slow down on other systems, but you can decide how
much optimising the ported version needs when you port it. This seems like
sheer common sense to me, and if someone mocks you for it then perhaps
they deserve a clear explanation.
>I still think libraries
>are the way to go, they don't imply universality (there's that
>is-it-a-word? word again :) and they seperate the code from the
>compiler, so the Forth compiler executable doesn't become bloated.
Again, I always imagined that the optional wordsets would be
implemented as libraries. They get ENVIRONMENT? strings to say that
they've been loaded.