A new commercial indie game made in SwiftForth (Windows)

[roger...@gmail.com]

IndieDB
http://www.indiedb.com/games/the-lady

Purchase
https://indiegamestand.com/store/985/the-lady/

Homepage
http://www.mprart.net/the-lady/

I programmed and helped design it. A guy named Michael Patrick Rogers created and directed it and did the sound and promo.

[Paul Rubin]

roger...@gmail.com writes:
> http://www.indiedb.com/games/the-lady...

> I programmed and helped design it. A guy named Michael Patrick Rogers
> created and directed it and did the sound and promo.

Nice! I saw something about it on reddit a while back, too.

Are you going to release the source code? What about a mobile version?

[AKK]

Congratulation!

But why did you specifically select Forth, over say Lua?
IMHO for a 2D game even slow Python would have sufficed.

[Laurent Laborde]

On Sunday, May 4, 2014 8:24:14 AM UTC+2, AKK wrote:
>
> But why did you specifically select Forth, over say Lua?
> IMHO for a 2D game even slow Python would have sufficed.

If i understood the interview correctly, the guy suffer from
heavy mental illness and visual hallucination.

I guess that make sense ;)

--
Ker2x

[AKK]

Neither did I make poor fun of him like you, nor did I pose a vain question.

I am really interested in his answer.

[Mark Wills]

I watched the video on the link provided. It looks a little strange (the text says it's rather surreal) but it looks excellent from a technical point of view. Very impressive. Well done. Is there a playable demo or anything?

[Roger Levy]

On Sunday, May 4, 2014 12:21:22 PM UTC-4, Mark Wills wrote:
> I watched the video on the link provided. It looks a little strange (the text says it's rather surreal) but it looks excellent from a technical point of view. Very impressive. Well done. Is there a playable demo or anything?

There was a demo created for the kickstarter. It seems to have been taken down, but I'll put it on my host, I think it should be OK. Obviously this demo doesn't represent the final game since it was made several months ago.

Demo Link: https://www.dropbox.com/s/6j8o48n5xi3w1q4/The%20Lady%20DEMO%20%28b1%29.zip

[Roger Levy]

> Congratulation!

Thank you.

> But why did you specifically select Forth, over say Lua?

Because I like Forth a lot and I'm pretty fluent in it. Lua is a more complex proposition. Which engine do you use? Or do you write your own in some other language for the CPU sensitive bits? Do you implement an interactive console? Besides, I had already made my own foundational engine in Forth so it was very easy to hit the ground running. I am investing in maximizing Forth for game development. I think it is starting to pay off - the game was completed on time, along with a game engine, and is really polished considering it had a $2500 budget.

> IMHO for a 2D game even slow Python would have sufficed.

I doubt it. We use particle effects with hundreds of particles, and a bone-based animation system. Even SwiftForth could only handle up to a couple dozen of animated characters on screen on my fast machine, and there wasn't time to bother with figuring out a system for object culling. Framerate is already choppy on some computers. It would not have been practical to do it in pure Python. I dislike Python, anyway.

[Roger Levy]

You could, you know, also buy it ;) Its only $5.

[Mark Wills]

Ah I didn't notice that. Thanks for pointing it out! You're absolutely right. For 5$ I'll just go ahead and buy it. :-)

[AKK]

Am 04.05.2014 22:36, schrieb Roger Levy:>
>> Congratulation!
>
> Thank you.
>
>> But why did you specifically select Forth, over say Lua?
>
> Because I like Forth a lot and I'm pretty fluent in it. Lua is a more complex proposition. Which engine do you use?

I don't develop games. But realtime simulation has similar requirements.

>> IMHO for a 2D game even slow Python would have sufficed.
>
> I doubt it.

Others don't:
http://www.pygame.org/news.html

But since you dislike it... ;-)

[Roger Levy]

> I don't develop games. But realtime simulation has similar requirements.

Ah, I see. You're a language war troll. It's OK.

> Others don't:
>
> http://www.pygame.org/news.html

I'm aware of Pygame. I didn't say Python isn't suitable for games. I was saying it's too slow for what we did, and you just said it's slow. C'mon though, look at those screenshots - the games showcased on that site don't even compare. They look like bottom-of-the-barrel DOS shareware from 1982. If you're going to compare languages for their suitability for making games then at least use comparable examples of games made with them.

Oh, and ... make ... games?

[Roger Levy]

> > Because I like Forth a lot and I'm pretty fluent in it. Lua is a more complex proposition. Which engine do you use?

> I don't develop games. But realtime simulation has similar requirements.

There was a misunderstanding. I'm sick with the flu so maybe I'm a bit foggy. But when I said "which engine do you use?" I was talking about regarding which to use with Lua not what you personally use. I thought you were defending your legitimacy when I called you a troll. Maybe you are a troll maybe you're not but I hate language comparisons.

I chose Forth because I really love it and I showed that it works. That's all there is to it. I have no interest in comparing programming languages academically.

[Alexander Skobelev]

It looks like you have used the Allegro library. Could you elaborate on
on that? Why did you choose Allegro over SDL2? What was your experience
with it? Are you planning to publish the Forth bindings for Allegro?

Thanks in advance!

[AKK]

I am definitively not trolling. We are prototyping controller boards
with integrated prediction algorithms.

[Roger Levy]

I am not aware of SDL2. I also wasn't aware of SDL2 when I started building the engine, last year, before I started working on The Lady. Allegro is nice for its simplicity and broad range of graphics routines - to me it is a real, complete package for game developers.

I had been doing my own stuff in pure OpenGL, but it was too complex. The switch in Allegro 5 to OpenGL was a catalyst to go back to simplicity.

My Allegro 5 bindings aren't comprehensive. Would anyone be interested in completing them?

[Alexander Skobelev]

On Monday, May 5, 2014 8:49:40 PM UTC+4, Roger Levy wrote: > On Monday,

Not sure about completing them, but definitely interested in an example
of practical use of the Allegro library in Forth.

[Roger Levy]

> Not sure about completing them, but definitely interested in an example
>
> of practical use of the Allegro library in Forth.

I just posted the bindings on the group. As for practical use, you'll have to wait until I either release the game's source code or make a free public domain game. I asked Mike if it was okay to release source and he hasn't gotten back to me.

I might also just release some facilities built on Allegro 5 that I use in my games, after I clean them up.

[Paul Rubin]

Roger Levy <roger...@gmail.com> writes:
> I just posted the bindings on the group. As for practical use, you'll
> have to wait until I either release the game's source code or make a
> free public domain game. I asked Mike if it was okay to release
> source and he hasn't gotten back to me.

I don't mind paying the $5, but if I do so I'm more interested in
studying and modifying the game than playing it. Maybe you could make
it like minecraft, where players are encouraged to extend it themselves.

[Alexander Skobelev]

On Wednesday, May 7, 2014 12:21:47 PM UTC+4, Roger Levy wrote:
>
> I just posted the bindings on the group. As for practical use, you'll
> have to wait until I either release the game's source code or make a
> free public domain game. I asked Mike if it was okay to release
> source and he hasn't gotten back to me.
>
> I might also just release some facilities built on Allegro 5 that I
> use in my games, after I clean them up.

Thanks a lot!

[Roger Levy]

>
> I don't mind paying the $5, but if I do so I'm more interested in
>
> studying and modifying the game than playing it. Maybe you could make
>
> it like minecraft, where players are encouraged to extend it themselves.

That is a fantastic idea!

I've brought it to Mike (he's the creator). How much would you be willing to pay for a source version to play with? Is $40 too much?

[Roger Levy]

On second thought, he's probably going to say no.

But maybe a game designed from the ground up to work for that model, or a sort of "game engine + complete example game" package would be interesting?

But how many Forth programmers would be in the market for something like this?

[Richard Owlett]

Roger Levy wrote:
>
>> I've brought it to Mike (he's the creator). How much would you be willing to pay for a source version to play with? Is $40 too much?
>
> On second thought, he's probably going to say no.
>
> But maybe a game designed from the ground up to work for that model, or a sort of "game engine + complete example game" package would be interesting?
>
> But how many Forth programmers would be in the market for something like this?
>

Turn that last question around, would it have features that would
attract gamers to Forth?

[Zbigniew]

At last Vagino will have "game programmed in Forth", which he was looking for
so many days (years?).
--
May the Forth be with you!

[Paul Rubin]

Roger Levy <roger...@gmail.com> writes:
> But maybe a game designed from the ground up to work for that model,
> or a sort of "game engine + complete example game" package would be
> interesting?
>
> But how many Forth programmers would be in the market for something
> like this?

Surely not enough ;-). But I thought part of the idea was to get
newbies interested in Forth.

I guess it only has any hope if it could either 1) work with a free
Forth like Gforth, or 2) work with the evaluation version of Swift
(and you'd better check with forth.com before attempting that).
Swiftforth is a great product from everything I hear, but I couldn't
imagine spending hundreds of $$ on a copy just to play and modify a game
when I wasn't getting paid for it.

[Roger Levy]

>
> > But how many Forth programmers would be in the market for something
>
> > like this?
>
>
>
> Surely not enough ;-). But I thought part of the idea was to get
>
> newbies interested in Forth.
>
>
>
> I guess it only has any hope if it could either 1) work with a free
>
> Forth like Gforth, or 2) work with the evaluation version of Swift
>
> (and you'd better check with forth.com before attempting that).
>
> Swiftforth is a great product from everything I hear, but I couldn't
>
> imagine spending hundreds of $$ on a copy just to play and modify a game
>
> when I wasn't getting paid for it.

There are 2 angles here.

1) Make the model "source distribution only". The eval version of SwiftForth is free and full featured minus turnkey export.

2) I know of a really impressive forth called iForth http://home.iae.nl/users/mhx/i4faq.html
the license is incredibly liberal. Pay ~$140 and use it for whatever the fuck you want. This is ideal for tooling it into a complete game dev environment (something I've had an interest in for years and have abandoned several tries), or simply as a game that can have modding scripts passed in.

[Roger Levy]

Actually ... I just recalled using the compiler features of SwiftForth apps is prohibited in the license. So concentrate on just the iForth angle.

[Paul Rubin]

Bernd's Android port of Gforth has OpenGPL bindings if I understand it
right. Maybe that can do the job, if you want an Android game?

I think making the person spend $140 on iForth would be a pretty
difficult sell, although iForth generates very efficient code.

[Roger Levy]

I tried GForth years ago. It think my verdict was "too bloated".

> I think making the person spend $140 on iForth would be a pretty
>
> difficult sell, although iForth generates very efficient code.

I think that technically I could give iForth away, since his license states "do anything you want with it". But I'm not that big of a dick so it would be a pared down version that is designed solely for scripting my game engine.

[Elizabeth D. Rather]

On 5/7/14 6:57 AM, Roger Levy wrote:
> Actually ... I just recalled using the compiler features of SwiftForth apps is prohibited in the license. So concentrate on just the iForth angle.
>

It's only the meta-compiler that can't be used in the eval version. The
standard SwiftForth compiler for user code is definitely available. In
other words, you can use it to write programs, but not to generate a
different Forth.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Roger Levy]

>
> It's only the meta-compiler that can't be used in the eval version. The
>
> standard SwiftForth compiler for user code is definitely available. In
>
> other words, you can use it to write programs, but not to generate a
>
> different Forth.
>
>

I'm confused. I contacted FORTH Inc. a while back asking if it was OK to make a game that compiled source files on-the-fly, or allow users to write their own games in Forth so long as they couldn't use PROGRAM without having a SwiftForth license, and was told flatly that both were prohibited.

[Paul Rubin]

Roger Levy <roger...@gmail.com> writes:
> I tried GForth years ago. It think my verdict was "too bloated".

Are you saying SwiftForth is smaller? I guess that's possible since
Swift is metacompiled and works somewhat differently, but both are
pretty featureful implementations.

[Roger Levy]

>
> Are you saying SwiftForth is smaller? I guess that's possible since
>
> Swift is metacompiled and works somewhat differently, but both are
>
> pretty featureful implementations.

It might have been that at the time I was looking for a Forth I could modify easily enough, and GForth's coding style IIRC was not very nice to work with. Working from distant memory here though. So by "bloated" maybe I meant that the word definitions themselves were long-winded rather than just the total # of system words.

[Alex McDonald]

on 07/05/2014 17:56:49, Roger Levy wrote:
>
>>
>> > But how many Forth programmers would be in the market for something
>>
>> > like this?
>>
>>
>>
>> Surely not enough ;-). But I thought part of the idea was to get
>>
>> newbies interested in Forth.
>>
>>
>>
>> I guess it only has any hope if it could either 1) work with a free
>>
>> Forth like Gforth, or 2) work with the evaluation version of Swift
>>
>> (and you'd better check with forth.com before attempting that).
>>
>> Swiftforth is a great product from everything I hear, but I couldn't
>>
>> imagine spending hundreds of $$ on a copy just to play and modify a game
>>
>> when I wasn't getting paid for it.
>
>
> There are 2 angles here.
>
> 1) Make the model "source distribution only". The eval version of

> SwiftFor th is free and full featured minus turnkey export.

>
> 2) I know of a really impressive forth called iForth
> http://home.iae.nl/users/mhx/i4faq.html the license is incredibly

> liberal. Pay ~$140 and use it for whatever the f uck you want. This is
> ideal for tooling it into a complete game dev enviro nment (something
> I've had an interest in for years and have abandoned sever al tries),

> or simply as a game that can have modding scripts passed in.
>

Since it's Windows, why not Win32Forth?

[Roger Levy]

> Since it's Windows, why not Win32Forth?

Reverse DLL parameter order, fewer IDE niceties and non-existent support.

[hughag...@yahoo.com]

SwiftForth doesn't allow compilation of Forth code during the run-time of the program (generally known as "meta-compilation") --- this largely kills the whole point of using Forth rather than C.

AFAIK, VFX does allow compilation of Forth code during the run-time of the program --- but you should ask Stephen Pelc about that.

[Howerd]

Hi Hugh,

I think that you misunderstand the meaning of meta-compilation.

> SwiftForth doesn't allow ...
I purchased SwiftForth last year, largely to get support for the latest Windows multitasker - it comes with complete source, so there is nothing that is "not allowed", everything is under my control.

Taking the most obvious interpretation of what you say :
> [ Forth, Inc. don't allow ] compilation of Forth code during the run-time of
> the program.
Oh dear. Most of my SwiftForth programs interpret Forth source at run time, if only to load a configuration file. Usually I use a sealed vocabulary to limit the destructive power of an unchained user. Sometimes I even expose ':' .

> (generally known as "meta-compilation")

No, this is not meta-compilation.

> this largely kills the whole point of using Forth rather than C.

Here I agree, in that it would make Forth pointless, if what you say is true...

Forth, Inc. and MPE have to protect themselves from pirates.
I could very easily type ( in SwiftForth ) :
starter QUIT program MYFORTH.EXE

and sell my new Forth system, but that is not allowed.

AFAIK everything else is allowed that does not produce a new Forth system ...

I'm sure others will correct me if I am wrong :-)

Best regards,
Howerd

[Albert van der Horst]

In article <22c56209-b95d-4af7...@googlegroups.com>,

Howerd <how...@yahoo.co.uk> wrote:
>Hi Hugh,
>
>I think that you misunderstand the meaning of meta-compilation.
>
>> SwiftForth doesn't allow ...
>I purchased SwiftForth last year, largely to get support for the latest
>Windows multitasker - it comes with complete source, so there is nothing
>that is "not allowed", everything is under my control.
>
>Taking the most obvious interpretation of what you say :
>> [ Forth, Inc. don't allow ] compilation of Forth code during the run-time of
>> the program.
>Oh dear. Most of my SwiftForth programs interpret Forth source at run
>time, if only to load a configuration file. Usually I use a sealed
>vocabulary to limit the destructive power of an unchained user.
>Sometimes I even expose ':' .

There is a difference between having a Forth and having a turnkey
program that interprets.

When I write a turnkey program in ciforth (lina) the main program
looks typically like

: main
if the first argument starts with a - :
EVALUATE it
else
sniff out the option
;

making the interpreter indispensible.

E.g. like so:
\ Handle options or files, end with accepting stdin.
: main init BEGIN ARGC 1 > WHILE 1 ARG[] OVER C@ &- = IF EVALUATE ELSE
process-file SHIFT-ARGS THEN REPEAT process ;

The code contains stuff like
: -h "
USAGE : uudecode [-f <forced-name>] <input1> [<input2> [<input3?...> ]
uudecode all uudecode blocks in all input files.
-f forces the names of the output files,
if more than one name is needed, digits in <forced-name> are incremented.

ERRORS : 1001 you must specify a file name with the -f option.
1002 forced file name too long.
1003 I cannot open one of the named files.
1004 Copying a file descriptor to 0 failed.
1005 There is a uudecode 'begin' but no corresponding 'end'
1006 An output file with a forced name couldn't be openened.
1007 The output file name couldn't be morphed into so many names.
1008 Too many chars in a line for our buffersize.
" TYPE BYE
;

and
\ Consume -f option and argument.
: -f SHIFT-ARGS ARGC 1 = 1001 ?ERROR
1 ARG[] DUP max-file > 1002 ?ERROR file-name $!
SHIFT-ARGS ;

A calculation program can have `` 1 ARG[] EVALUATE '' and be used
like
factorise 111111
or
factorise ' WANT $-PREFIX $123456789'
(Meaning: before interpreting the number, code is loaded to understand
$ prefixes, all within one argument.).

>> (generally known as "meta-compilation")
>No, this is not meta-compilation.
>
>> this largely kills the whole point of using Forth rather than C.
>Here I agree, in that it would make Forth pointless, if what you say is true...
>
>Forth, Inc. and MPE have to protect themselves from pirates.
>I could very easily type ( in SwiftForth ) :
>starter QUIT program MYFORTH.EXE
>
>and sell my new Forth system, but that is not allowed.
>
>AFAIK everything else is allowed that does not produce a new Forth system ...
>
>I'm sure others will correct me if I am wrong :-)

This is how the lina license works. If your derived program is not
a Forth system, it is not a derived work in the GPL sense, and
you're free to distribute it without source.
Using the Forth interpreter mechanism doesn't make a program a
"Forth system".

>
>Best regards,
>Howerd
>
>On Thursday, 8 May 2014 06:32:58 UTC+1, hughag...@yahoo.com wrote:
>> On Wednesday, May 7, 2014 11:33:24 AM UTC-7, Roger Levy wrote:
>>
>> > > It's only the meta-compiler that can't be used in the eval version. The
>>
>> > > standard SwiftForth compiler for user code is definitely available. In
>>
>> > > other words, you can use it to write programs, but not to generate a
>>
>> > > different Forth.
>>
>> >
>>
>> > I'm confused. I contacted FORTH Inc. a while back asking if it was
>OK to make a game that compiled source files on-the-fly, or allow users
>to write their own games in Forth so long as they couldn't use PROGRAM
>without having a SwiftForth license, and was told flatly that both were
>prohibited.
>>
>>
>>
>> SwiftForth doesn't allow compilation of Forth code during the run-time
>of the program (generally known as "meta-compilation") --- this largely
>kills the whole point of using Forth rather than C.
>>
>>
>>
>> AFAIK, VFX does allow compilation of Forth code during the run-time of
>the program --- but you should ask Stephen Pelc about that.

This kind of confusion makes it harder to promote programs built in Forth.
I think it's a pity.

P.S.
EVALUATE is dangerous:
factorise '"rm -rf /" SYSTEM'
is very bad if you're root. I see no point in prohibiting this where a
user could do
'"rm -rf /" SYSTEM'
directly.

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Elizabeth D Rather]

On 5/7/2014 10:50 PM, Howerd wrote:
> Forth, Inc. and MPE have to protect themselves from pirates.
> I could very easily type ( in SwiftForth ) :
> starter QUIT program MYFORTH.EXE
>
> and sell my new Forth system, but that is not allowed.
>
> AFAIK everything else is allowed that does not produce a new Forth system ...
>
> I'm sure others will correct me if I am wrong:-)

There should be a clear statement in the manual about what words
can/cannot be exposed to users. I haven't looked in a while, but as I
recall interpreting text is fine, and it's ok for your program to
compile options and features, but : etc. shouldn't be exposed to the
users (which can be avoided with sealed vocabularies).

[Elizabeth D Rather]

On 5/8/2014 12:24 AM, Albert van der Horst wrote:
> In article <22c56209-b95d-4af7...@googlegroups.com>,
> Howerd <how...@yahoo.co.uk> wrote:

...

>
>>> (generally known as "meta-compilation")
>> No, this is not meta-compilation.

Correct. Meta-compilation is generating a new Forth for the same or a
different target, not adding definitions to the current system.

[Roger Levy]

> There should be a clear statement in the manual about what words
>
> can/cannot be exposed to users. I haven't looked in a while, but as I
>
> recall interpreting text is fine, and it's ok for your program to
>
> compile options and features, but : etc. shouldn't be exposed to the
>
> users (which can be avoided with sealed vocabularies).
>

You know, restricting : and other defining words seems extreme. That gives up an enormous advantage in Forth.

I think the only restrictions should be the metacompiler, assembler, and PROGRAM. Especially if the wordset exposed to "scripters" was restricted to a specific domain. For instance no write-to-filesystem words and no Win32API access. Letting users write their own scripts without having to write a new interpreter should be allowed.

[Stephen Pelc]

On Thu, 8 May 2014 12:09:56 -0700 (PDT), Roger Levy
<roger...@gmail.com> wrote:

>You know, restricting : and other defining words seems extreme. That gives=

> up an enormous advantage in Forth.

I'm scarred by the number of badly written and badly documented Forths
that appeared in the 1980s and early 1990s. Consequently, MPE policy
is based around the idea that if an end-user needs the documentation
for the Forth, a licence for the MPE docs is required. If it's just
what we term "engineering and maintenance access", e.g. config files
or setup, then please use the interpreter. We encourage people
doing this to acknowledge our copyright in their code and
documentation.

The interpreter is a very useful tool.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Elizabeth D Rather]

The question is, what is the purpose of the system? The normal view is
that the purpose of a Forth system, like other languages and compilers,
is to make a *program* which will be distributed to end users who regard
this program as a "device" which does whatever it's intended to do
(play a game, run an instrument, etc.). End users are not buying a
language or programming system, and don't want or need to know anything
about the language it's written in.

If, in fact, what you want to sell is a programmable, extensible
product, I'm sure FORTH, Inc. would be happy to negotiate a licensing
agreement for that, but that is not the primary intent of the
off-the-shelf product.

[Mark Wills]

On Thursday, 8 May 2014 20:09:56 UTC+1, Roger Levy wrote:
> For instance no write-to-filesystem words and no Win32API access. Letting users write their own scripts without having to write a new interpreter should be allowed.

Let them have blocks. Files are for panzies! :-)

[Roger Levy]

On Thursday, May 8, 2014 5:24:23 PM UTC-4, Elizabeth D Rather wrote:
> On 5/8/2014 9:09 AM, Roger Levy wrote:
>
> >
>
> >> There should be a clear statement in the manual about what words
>
> >>
>
> >> can/cannot be exposed to users. I haven't looked in a while, but as I
>
> >>
>
> >> recall interpreting text is fine, and it's ok for your program to
>
> >>
>
> >> compile options and features, but : etc. shouldn't be exposed to the
>
> >>
>
> >> users (which can be avoided with sealed vocabularies).
>
> >>
>
> >
>
> > You know, restricting : and other defining words seems extreme. That gives up an enormous advantage in Forth.
>
> >
>
> > I think the only restrictions should be the metacompiler, assembler, and PROGRAM. Especially if the wordset exposed to "scripters" was restricted to a specific domain. For instance no write-to-filesystem words and no Win32API access. Letting users write their own scripts without having to write a new interpreter should be allowed.
>
> >
>
>
>
> The question is, what is the purpose of the system? The normal view is
>
> that the purpose of a Forth system, like other languages and compilers,
>
> is to make a *program* which will be distributed to end users who regard
>
> this program as a "device" which does whatever it's intended to do
>
> (play a game, run an instrument, etc.). End users are not buying a
>
> language or programming system, and don't want or need to know anything
>
> about the language it's written in.
>
>
>
> If, in fact, what you want to sell is a programmable, extensible
>
> product, I'm sure FORTH, Inc. would be happy to negotiate a licensing
>
> agreement for that, but that is not the primary intent of the
>
> off-the-shelf product.

you might be familiar with "modding". this is getting more and more popular in the game community. i.e. modifying the behavior of a game, whether it's adding or changing characters or the logic of various elements of levels, or entire levels, cutscenes, stories, or anything. depending on the level of customizability. conventionally, an off-the-shelf, or dedicated scripting language will be used, like Lua - but Forth is already built into the executable so it would be stupid not to just use it.

i'm fine with working out a royalty scheme since this would be a commercial project, so long as i could get a large amount of freedom. i might be in contact with you guys about this within the next few months. who's best to get in touch with for licensing?

[Bernd Paysan]

Stephen Pelc wrote:

> On Thu, 8 May 2014 12:09:56 -0700 (PDT), Roger Levy
> <roger...@gmail.com> wrote:
>
>>You know, restricting : and other defining words seems extreme. That
>>gives=
>> up an enormous advantage in Forth.
>
> I'm scarred by the number of badly written and badly documented Forths
> that appeared in the 1980s and early 1990s. Consequently, MPE policy
> is based around the idea that if an end-user needs the documentation
> for the Forth, a licence for the MPE docs is required. If it's just
> what we term "engineering and maintenance access", e.g. config files
> or setup, then please use the interpreter. We encourage people
> doing this to acknowledge our copyright in their code and
> documentation.
>
> The interpreter is a very useful tool.

I'm coming from the free software side, so we don't like imposed
restrictions. Therefore, here are some examples where the compiler is very
useful, too:

* Gerald's game he presented on EuroForth: The game engine is written in a
mix of C++, GL Shader Language, and an embedded Forth. The actual level
design is written in Forth. It's actually a 3D turtle graphics which
generates the OpenGL vertices. Of course, it is compiled; speed matters.
This level design language is a typical application of Forth as domain-
specific language, and it's using all the available features.

* Open Network Forth: One key element of ONF was that each node started with
a pretty bare system that could do communication, but didn't know how to
control the things it was in charge off - that stuff was pushed as source
code over the network and then compiled on each node.

* Other systems with similar attributes: EuroPay (pushing tokenized source
code to the terminals), OpenFirmware (tokenized source code in the driver
ROMs of the cards).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Bernd Paysan]

Elizabeth D Rather wrote:

> The question is, what is the purpose of the system? The normal view is
> that the purpose of a Forth system, like other languages and compilers,
> is to make a *program* which will be distributed to end users who regard
> this program as a "device" which does whatever it's intended to do
> (play a game, run an instrument, etc.). End users are not buying a
> language or programming system, and don't want or need to know anything
> about the language it's written in.

What about this level design language thing I mentioned in my reply to
Stephen? The end user is buying a game, but one of the important aspects of
game development is that you separate the game engine and the level
description. In a Forth game, the level description is very likely Forth
code plus image data. The level designer might be aware of the Forth code,
and there are a number of interesting games out there where users can design
their own level and even submit it to the community.

Some games (like minecraft) have stuff inside that allows people to build
some logic inside. They even implemented Forth inside minecraft:

http://integratedredstone.wikispaces.com/RedPower+Control

I think the original idea of having a language for programmers, and some
sort of rat pushing a button on the end user side isn't true anymore (if it
ever was).

[Elizabeth D. Rather]

On 5/8/14 1:22 PM, Bernd Paysan wrote:
...

> I'm coming from the free software side, so we don't like imposed
> restrictions. Therefore, here are some examples where the compiler is very
> useful, too:
>
> * Gerald's game he presented on EuroForth: The game engine is written in a
> mix of C++, GL Shader Language, and an embedded Forth. The actual level
> design is written in Forth. It's actually a 3D turtle graphics which
> generates the OpenGL vertices. Of course, it is compiled; speed matters.
> This level design language is a typical application of Forth as domain-
> specific language, and it's using all the available features.

Depending on what features of the domain-specific language will be
available to users, it's quite possible that a suitable arrangement can
be negotiated.

> * Open Network Forth: One key element of ONF was that each node started with
> a pretty bare system that could do communication, but didn't know how to
> control the things it was in charge off - that stuff was pushed as source
> code over the network and then compiled on each node.

Assuming all the various control modules were written under license,
that would be just fine.

> * Other systems with similar attributes: EuroPay (pushing tokenized source
> code to the terminals), OpenFirmware (tokenized source code in the driver
> ROMs of the cards).
>

We definitely had an arrangement with Europay covering their needs, and
each version Open Firmware was developed by the company that was
distributing it, and they set their licensing appropriately.

Business people are, for the most part, neither dumb nor blind (those
who are, don't stay in business long). They will make whatever
arrangements will protect their business interests and serve their
customers' needs appropriately.

[Laurent Laborde]

On Thursday, May 8, 2014 11:24:23 PM UTC+2, Elizabeth D. Rather wrote:
> On 5/8/2014 9:09 AM, Roger Levy wrote:
>
> The question is, what is the purpose of the system? The normal view is
> that the purpose of a Forth system, like other languages and compilers,
> is to make a *program* which will be distributed to end users who regard
> this program as a "device" which does whatever it's intended to do
> (play a game, run an instrument, etc.). End users are not buying a
> language or programming system, and don't want or need to know anything
> about the language it's written in.

Actually this is a HUGE sale argument in video games.
Gamers love to be able to mod the code, the biggest LUA community is made of gamers, imho :)
Lua and Python are the two languages of choice for mods.

Also, some AAA games engines are provided for free
(with commercial licensing option) :
- Source Engine
- UDK
- Cryengine
...

--
Ker2x

[Alex McDonald]

ANS, free, complete source, active user community, works well & long
pedigree. There are tradeoffs in every tool.

[Roger Levy]

> ANS, free, complete source, active user community, works well & long
>
> pedigree. There are tradeoffs in every tool.

It wasn't meant to be a knock against it. I had to weigh my needs against what it provided.

[Alex McDonald]

I didn't take it as such.

[Roger Levy]

I'm such an airhead, I forgot the biggie: that win32forth is win32 only!

Hoping to get my engine working on other platforms, one way or another. That was a big reason for going with swiftforth, to be able to at least port it to linux and mac.

[Albert van der Horst]

In article <d46f6240-63f8-4dbc...@googlegroups.com>,

Roger Levy <roger...@gmail.com> wrote:
>> Since it's Windows, why not Win32Forth?
>
>Reverse DLL parameter order, fewer IDE niceties and non-existent support.

Interesting that you mention parameter order. I made a dll call mechanism
(wina 5.0) and decided against facilities to reverse the parameter order,
building the stack up exactly as seen by the dll, with no abstractions.
You can read it off the microsoft documentation.

Now I keep saying to myself, what is the difference in reading that
documentation bottom to top? We all can comb our hair looking in the
mirror right? You might even find it difficult using the cam recorder
in your smart phone, that shows you how it really is.

It should be just a mindset, still I find it difficult.

[m...@iae.nl]

On Saturday, May 10, 2014 5:09:24 AM UTC+2, Albert van der Horst wrote:
> In article <d46f6240-63f8-4dbc...@googlegroups.com>,
> Roger Levy <roger...@gmail.com> wrote:
> >> Since it's Windows, why not Win32Forth?
> >
> >Reverse DLL parameter order, fewer IDE niceties and non-existent support.
>
> Interesting that you mention parameter order. I made a dll call mechanism
> (wina 5.0) and decided against facilities to reverse the parameter order,
> building the stack up exactly as seen by the dll, with no abstractions.
> You can read it off the microsoft documentation.
>
> Now I keep saying to myself, what is the difference in reading that
> documentation bottom to top? We all can comb our hair looking in the
> mirror right? You might even find it difficult using the cam recorder
> in your smart phone, that shows you how it really is.
>
> It should be just a mindset, still I find it difficult.

That is probably because at some point you may want to
change / port / understand something like:

... swap 2swap 6 pick over -rot GameChanger swap hDC Call TextOut ?win-error

-marcel

[Alex McDonald]

on 10/05/2014 07:06:31, wrote:
> On Saturday, May 10, 2014 5:09:24 AM UTC+2, Albert van der Horst
> > wrote:
>> In article <d46f6240-63f8-4dbc...@googlegroups.com>,

> > wrote:

>> Roger Levy <roger...@gmail.com> wrote:
> > wrote:
>> >> Since it's Windows, why not Win32Forth?

> > wrote:

>> >
> > wrote:
>> >Reverse DLL parameter order, fewer IDE niceties and non-existent support.

> > wrote:

>>
> > wrote:
>> Interesting that you mention parameter order. I made a dll call mechanism

> > wrote:
>> (wina 5.0) and decided against facilities to reverse the parameter order,

> > wrote:
>> building the stack up exactly as seen by the dll, with no abstractions.

> > wrote:
>> You can read it off the microsoft documentation.

> > wrote:

>>
> > wrote:
>> Now I keep saying to myself, what is the difference in reading that

> > wrote:
>> documentation bottom to top? We all can comb our hair looking in the

> > wrote:
>> mirror right? You might even find it difficult using the cam recorder

> > wrote:
>> in your smart phone, that shows you how it really is.

> > wrote:

>>
> > wrote:
>> It should be just a mindset, still I find it difficult.

> wrote:
>
> That is probably because at some point you may want to
> change / port / understand something like:
>
> ... swap 2swap 6 pick over -rot GameChanger swap hDC Call TextOut
> ?win-error
>
> -marcel
>

Errr... you fogot "rewrite". That 6 pick is horrible...

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>I think the original idea of having a language for programmers, and some
>sort of rat pushing a button on the end user side isn't true anymore (if it
>ever was).

The separation between programmers and (non-programming) end users
exists in many settings, so it's no wonder that licenses of
proprietary software are designed for such settings.

That difference exists even in cases where the license is not making
the difference, and where the program author does not expect it.
E.g., Knuth expected that the users would make custom variants of TeX
for their own purposes, but that did not happen. Instead, they wrote
macro packages for TeX, and of these, LaTeX was the winner who took it
all; and there are various packages that build on top of LaTeX.

So for TeX we do have the separation, but it's more fine-grained:
There are relatively few who work on TeX (pretty much only porting and
such), some more who work on the LaTeX core, many more that work on
packages for LaTeX, and then there are the end users (many of whom
define their own commands and environments, but not all).

This kind of layering is also present in other areas, e.g., games with
addons and macro languages.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/

[Anton Ertl]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>Interesting that you mention parameter order. I made a dll call mechanism
>(wina 5.0) and decided against facilities to reverse the parameter order,
>building the stack up exactly as seen by the dll, with no abstractions.
>You can read it off the microsoft documentation.
>
>Now I keep saying to myself, what is the difference in reading that
>documentation bottom to top? We all can comb our hair looking in the
>mirror right?

Combing is relatively simple, you don't try to write the computation
of the parameters at the same time, and you have years of training.
Even something not that much more complicated, like using scissors to
trim one hair is very difficult in the mirror (at least for me).

>You might even find it difficult using the cam recorder
>in your smart phone, that shows you how it really is.

Probably, which would show that it is not a good idea to reverse the
order.

Programming is hard enough, we should not make it harder just to
relief the Forth system of a job that it can do with a one-time effort
on part of the implementor; in contrast, the burden of reversing
manually is constant.

Also, most calling conventions pass 3-8 parameters in registers.
Unless you use that as your stack representation (which is probably
suboptimal), you have the remapping effort on platforms with these
calling conventions (i.e., most platforms) anyway. So reversing
optimizes the implementation effort on one platform, and burdens all
programmers on all platforms. Not a good deal.

[Bernd Paysan]

Anton Ertl wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>>I think the original idea of having a language for programmers, and some
>>sort of rat pushing a button on the end user side isn't true anymore (if
>>it ever was).
>
> The separation between programmers and (non-programming) end users
> exists in many settings, so it's no wonder that licenses of
> proprietary software are designed for such settings.
>
> That difference exists even in cases where the license is not making
> the difference, and where the program author does not expect it.
> E.g., Knuth expected that the users would make custom variants of TeX
> for their own purposes, but that did not happen. Instead, they wrote
> macro packages for TeX, and of these, LaTeX was the winner who took it
> all; and there are various packages that build on top of LaTeX.
>
> So for TeX we do have the separation, but it's more fine-grained:
> There are relatively few who work on TeX (pretty much only porting and
> such), some more who work on the LaTeX core, many more that work on
> packages for LaTeX, and then there are the end users (many of whom
> define their own commands and environments, but not all).
>
> This kind of layering is also present in other areas, e.g., games with
> addons and macro languages.

Yes, but part of this layering usually gets removed when you use Forth to
write such a system. E.g. take TeX: If you wrote a typesetting system in
Forth, you wouldn't implement the macro language from scratch. You would
use Forth as macro language, with all the words you needed to write the
typesetting system. Same with a game: the macro language would be Forth
plus the words of the game engine.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:

>Anton Ertl wrote:
>> So for TeX we do have the separation, but it's more fine-grained:
>> There are relatively few who work on TeX (pretty much only porting and
>> such), some more who work on the LaTeX core, many more that work on
>> packages for LaTeX, and then there are the end users (many of whom
>> define their own commands and environments, but not all).
>>
>> This kind of layering is also present in other areas, e.g., games with
>> addons and macro languages.
>
>Yes, but part of this layering usually gets removed when you use Forth to
>write such a system. E.g. take TeX: If you wrote a typesetting system in
>Forth, you wouldn't implement the macro language from scratch. You would
>use Forth as macro language, with all the words you needed to write the
>typesetting system. Same with a game: the macro language would be Forth
>plus the words of the game engine.

That's an implementation issue, but what I meant is that such systems
have these layers in the kinds of users. A great many "mere users",
fewer macro writers, even fewer addon/mod writers, and very few core
programmers. And I don't think that this would change if there was
just one programming language for macros, addons and core.

[Bernd Paysan]

Anton Ertl wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>>Anton Ertl wrote:
>>> So for TeX we do have the separation, but it's more fine-grained:
>>> There are relatively few who work on TeX (pretty much only porting and
>>> such), some more who work on the LaTeX core, many more that work on
>>> packages for LaTeX, and then there are the end users (many of whom
>>> define their own commands and environments, but not all).
>>>
>>> This kind of layering is also present in other areas, e.g., games with
>>> addons and macro languages.
>>
>>Yes, but part of this layering usually gets removed when you use Forth to
>>write such a system. E.g. take TeX: If you wrote a typesetting system in
>>Forth, you wouldn't implement the macro language from scratch. You would
>>use Forth as macro language, with all the words you needed to write the
>>typesetting system. Same with a game: the macro language would be Forth
>>plus the words of the game engine.
>
> That's an implementation issue, but what I meant is that such systems
> have these layers in the kinds of users. A great many "mere users",
> fewer macro writers, even fewer addon/mod writers, and very few core
> programmers. And I don't think that this would change if there was
> just one programming language for macros, addons and core.

Sure, that sort of layers wouldn't change. But the point is that when
there's only one programming language for macros, addons, and core, the mere
user will use that programming language. Not in the same way as the core
programmer does, but he can access the compiler and interpreter.

[Stephen Pelc]

On Sat, 10 May 2014 09:02:12 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>Also, most calling conventions pass 3-8 parameters in registers.
>Unless you use that as your stack representation (which is probably
>suboptimal), you have the remapping effort on platforms with these
>calling conventions (i.e., most platforms) anyway. So reversing
>optimizes the implementation effort on one platform, and burdens all
>programmers on all platforms. Not a good deal.

Hmmm ... I'm not so sure. If you are calling C libraries or an
operating system, you're doing a hosted Forth. The Forth is probably
going to be a native code Forth.

If the Forth data stack is not going to be the C/OS stack, then you
have to make decisions such as to copy the arguments/return values
or to switch the stacks. This decision impacts stack and task layout
in memory to the level that you have to *know* how a particular
O/S handles interrupts, signals and callbacks.

With register-based C calling conventions, the overhead of copying
parameters is insignificant compared to the inefficiency of keeping
several Forth stack items in registers. I'll get around to doing that
set of measurements one of these days ...

[Anton Ertl]

Yes, and the advantage of using the same language is that the entry
barrier into the next layer is lower.

Anyway, I think it is understandable that a proprietary Forth system
license is designed for the frequent two-layer case. And yes, it's
deplorable that such a license eliminates one advantage of Forth; of
course, one can negotiate a special license for the specific needs,
but there is also a barrier there.

The funny thing is that some people who wished that Gforth did not
have a copyleft (aka share-alike) license have suggested that more
permissive licensing should be used for turnkey programs that do not
give access to the compiler or somesuch; for some unfathomable reason
they assumed that we have a particular interest in supporting
proprietary software that locks the user out of the Forth system it is
based on.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>On Sat, 10 May 2014 09:02:12 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Also, most calling conventions pass 3-8 parameters in registers.
>>Unless you use that as your stack representation (which is probably
>>suboptimal), you have the remapping effort on platforms with these
>>calling conventions (i.e., most platforms) anyway. So reversing
>>optimizes the implementation effort on one platform, and burdens all
>>programmers on all platforms. Not a good deal.
>
>Hmmm ... I'm not so sure. If you are calling C libraries or an
>operating system, you're doing a hosted Forth. The Forth is probably
>going to be a native code Forth.

Not necessarily, but let's keep that assumption for this posting.

>If the Forth data stack is not going to be the C/OS stack, then you
>have to make decisions such as to copy the arguments/return values
>or to switch the stacks. This decision impacts stack and task layout
>in memory to the level that you have to *know* how a particular
>O/S handles interrupts, signals and callbacks.

What are you getting at, and what does the OS's handling of interrupts
and signals have to do with parameter passing?

As for callbacks, sure, you have have to know the calling convention
for that, just like you have to know the calling convention for doing
the calls of the C functions in the first place. But I still don't
know what you are getting at.

>With register-based C calling conventions, the overhead of copying
>parameters is insignificant compared to the inefficiency of keeping
>several Forth stack items in registers.

Yes, that's what I was getting at: You probably don't want the C
calling convention as your internal Forth calling convention, so you
cannot just call a C function as if it was a Forth word. So you have
to teach the compiler the C calling convention anyway, so in general,
burdening the programmer with reversing the arguments buys very little
benefit for the compiler writer.

[Bernd Paysan]

Anton Ertl wrote:
> The funny thing is that some people who wished that Gforth did not
> have a copyleft (aka share-alike) license have suggested that more
> permissive licensing should be used for turnkey programs that do not
> give access to the compiler or somesuch; for some unfathomable reason
> they assumed that we have a particular interest in supporting
> proprietary software that locks the user out of the Forth system it is
> based on.

That sort of thinking is understandable from the point of view of those who
want such a license: They are thinking of their software as proprietary
stuff, and stuck in that way of thinking. They just want a cheap system to
maximize their profit (though, of course, one particular guy didn't even
want to make a profit...).

[Elizabeth D. Rather]

On 5/9/14 10:42 PM, Anton Ertl wrote:
> Bernd Paysan <bernd....@gmx.de> writes:
>> I think the original idea of having a language for programmers, and some
>> sort of rat pushing a button on the end user side isn't true anymore (if it
>> ever was).
>
> The separation between programmers and (non-programming) end users
> exists in many settings, so it's no wonder that licenses of
> proprietary software are designed for such settings.

When I think of all the software that I use, virtually none of it is
intended to be "programmable" by users. The one exception is Excel,
which allows some VB code (although I've never used that feature). TeX
and relatives are another exception, but I don't use it. And virtually
the entire range of microcontroller applications are for widgets that
don't even have a user interface (though some have lights, buttons, etc.).

That said, FORTH, Inc. does have a number of customers who are selling
programmable applications under license. It's just a matter of
identifying what capabilities are required in what circumstances.

[Mark Wills]

How can one claim an additional licence fee for what amounts to EVALUATE in a loop?

I think I'm misunderstanding something here!

[Elizabeth D. Rather]

On 5/10/14 11:28 AM, Mark Wills wrote:
> How can one claim an additional licence fee for what amounts to EVALUATE in a loop?
>
> I think I'm misunderstanding something here!
>

Yes, I think you are. What is licensable is user access to a full
programming environment including compiler, assembler, interactive
development environment, debugging aids, libraries, documentation, etc.

As Stephen has pointed out, the interpreter itself is often quite useful
in applications.

[Mark Wills]

Ah. Okay I've got it. Yes that's a completely different matter. Sorry for the misunderstanding on my part.

[Stephen Pelc]

On Sat, 10 May 2014 15:26:22 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>>If the Forth data stack is not going to be the C/OS stack, then you
>>have to make decisions such as to copy the arguments/return values
>>or to switch the stacks. This decision impacts stack and task layout
>>in memory to the level that you have to *know* how a particular
>>O/S handles interrupts, signals and callbacks.
>
>What are you getting at, and what does the OS's handling of interrupts
>and signals have to do with parameter passing?

For example, can you guarantee that any of the stack area below the
stack pointer (assuming grow-down stacks) is safe to use? Some O/S
permit this, some don't.

How much stack space does a called C function use? You don't know
for the most part. The C stack then has to be below the data stack.

Where are the stacks for callbacks? Some O/S use the original caller's
stack. With nested callbacks we have seen applications in the wild
need several megabytes of stack space.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>For example, can you guarantee that any of the stack area below the
>stack pointer (assuming grow-down stacks) is safe to use? Some O/S
>permit this, some don't.
>
>How much stack space does a called C function use? You don't know
>for the most part. The C stack then has to be below the data stack.
>
>Where are the stacks for callbacks? Some O/S use the original caller's
>stack. With nested callbacks we have seen applications in the wild
>need several megabytes of stack space.

Yes, these issues have to be taken into consideration. They don't go
away with reverse parameter order, so they are not an argument for
or against it.

Concerning the individual issues: Neither C nor Forth limits stack
consumption. The OS or application decides at the start how much
address space each stack has; and if it is good, it puts a guard page
in to cause an exception on stack overflow. On Linux you can see the
memory map of process $p with

cat /proc/$p/maps

For a Gforth process, I see:

00400000-0041e000 r-xp 00000000 00:17 233563 .../gforth
0061e000-0061f000 r--p 0001e000 00:17 233563 .../gforth
0061f000-00628000 rw-p 0001f000 00:17 233563 .../gforth
00628000-00669000 rw-p 00000000 00:00 0
01f9e000-02004000 rw-p 00000000 00:00 0 [heap]
7fdf866e1000-7fdf86753000 rwxp 00000000 00:17 233562 .../gforth.fi
7fdf86753000-7fdf86ee1000 rwxp 00000000 00:00 0
[mappings for various shared libraries]
7fdf87f50000-7fdf87fd0000 rwxp 00000000 00:00 0
7fdf87fd0000-7fdf87fd6000 rw-p 00000000 00:00 0
7fdf87fd6000-7fdf87fd7000 rwxp 00000000 00:00 0
7fdf87fd7000-7fdf87fd8000 ---p 00000000 00:00 0
7fdf87fd8000-7fdf87fdc000 rwxp 00000000 00:00 0
7fdf87fdc000-7fdf87fdd000 ---p 00000000 00:00 0
7fdf87fdd000-7fdf87fe1000 rwxp 00000000 00:00 0
7fdf87fe1000-7fdf87fe2000 ---p 00000000 00:00 0
7fdf87fe2000-7fdf87fe6000 rwxp 00000000 00:00 0
7fdf87fe6000-7fdf87fe7000 ---p 00000000 00:00 0
7fdf87fe7000-7fdf87feb000 rwxp 00000000 00:00 0
7fdf87feb000-7fdf87fec000 ---p 00000000 00:00 0
7fdf87fec000-7fdf87ff0000 rwxp 00000000 00:00 0
7fdf87ff0000-7fdf87ff2000 rw-p 00000000 00:00 0
7fdf87ff2000-7fdf87ff3000 r--p 00022000 00:10 923295 .../ld-2.15.so
7fdf87ff3000-7fdf87ff5000 rw-p 00023000 00:10 923295 .../ld-2.15.so
7ffff0e0a000-7ffff0e2b000 rw-p 00000000 00:00 0 [stack]
7ffff0fff000-7ffff1000000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0[vsyscall]

As you can see, the C stack [stack] would first run into a mapping of
the linker; it can consume about 129GB of space before that happens.
You also see the dictionary at 7fdf866e1000-7fdf86ee1000 in two
mappings: one for the image gforth.fi, and one for the rest. The
Forth stacks (plus user area) are at 7fdf87fd6000-7fdf87ff0000, with a
guard page between each stack.

The mappings for a vfxlin process looks as follows:

08048000-080c0000 rwxp 00000000 00:10 316417 /usr/bin/vfxlin
080c0000-08848000 rwxp 00000000 00:00 0
098ba000-099db000 rwxp 00000000 00:00 0 [heap]
[Mappings of shared libraries]
f77a0000-f77a2000 rwxp 00000000 00:00 0
f77a2000-f77a3000 r-xp 00000000 00:00 0 [vdso]
f77a3000-f77c3000 r-xp 00000000 00:10 923644 .../ld-2.15.so
f77c3000-f77c4000 r-xp 0001f000 00:10 923644 .../ld-2.15.so
f77c4000-f77c5000 rwxp 00020000 00:10 923644 .../ld-2.15.so
ff939000-ff95a000 rwxp 00000000 00:00 0 [stack]

Again, the C stack first runs into a mapping of the linker; this time
there is about 129MB of space before that happens.

A callback is just an ordinary indirect call, so normally it uses the
same stack as the rest. Where does it happen differently? And yes, C
programs may consume lots of stack space, and the OS typically cater
to that.

[Bernd Paysan]

Stephen Pelc wrote:

> On Sat, 10 May 2014 15:26:22 GMT, an...@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>>>If the Forth data stack is not going to be the C/OS stack, then you
>>>have to make decisions such as to copy the arguments/return values
>>>or to switch the stacks. This decision impacts stack and task layout
>>>in memory to the level that you have to *know* how a particular
>>>O/S handles interrupts, signals and callbacks.
>>
>>What are you getting at, and what does the OS's handling of interrupts
>>and signals have to do with parameter passing?
>
> For example, can you guarantee that any of the stack area below the
> stack pointer (assuming grow-down stacks) is safe to use? Some O/S
> permit this, some don't.

Windows even limits you in the amount of memory you can allocate from the
stack in one go... this is mind-blowing stupid.

> How much stack space does a called C function use? You don't know
> for the most part. The C stack then has to be below the data stack.
>
> Where are the stacks for callbacks? Some O/S use the original caller's
> stack. With nested callbacks we have seen applications in the wild
> need several megabytes of stack space.

In bigForth, I decided to leave the C stack to C, and for callbacks, the
temporary stacks are allocated from that C stack. The callbacks are often
called in another thread which doesn't have its own per-thread Forth stacks.
Gforth now (git head) follows the same decision.

[Roger Levy]

If anyone has any questions for me regarding implementation details of the game I'll be happy to answer them.

[foxaudio...@gmail.com]

On Sunday, May 11, 2014 2:49:33 PM UTC-4, Roger Levy wrote:
> If anyone has any questions for me regarding implementation details of the game I'll be happy to answer them.

LOL!


(This was a pretty big thread topic drift) ;-)

[Roger Levy]

Yeah, and I feel like Gandalf. I stopped that onslaught dead in its tracks, and now it's crickets.





I've been working on generalizing and reorganizing the engine to make similar projects with. I don't think Mike is down with me releasing source to the game itself. But I don't know if the engine will be in a state to release for a while - it's pretty sloppy, and nonsensical in places. I wrote it in a hurry for the game and it could be a lot cleaner, and obviously there are no docs. But I do plan on getting out there.

There's a lot of stuff I could talk about in the meantime.

* Special data structures - arrays etc
* How I scripted game objects
* How graphics and sound work
* How the game scales to fit whatever display it's running on
* The particle engine, used for blood and rain
* Collision detection

And those are just examples. I don't know what people are interested in. It'll help me to learn better how to document this stuff by sharing here.

[Alexander Skobelev]

That would be great!
BTW, are you going to port the engine to UNIXes?

[Mark Wills]

On Tuesday, 13 May 2014 14:40:18 UTC+1, Roger Levy wrote:
> * How the game scales to fit whatever display it's running on

That would be interesting.

[Roger Levy]

@Alexander
Porting it to Unix (Mac/Linux) would probably be pretty easy for someone who knows Unix a lot better than I do! We expect to make a chunk of money from sales and bundles. I might use a bit of my share to pay someone to port the platform dependent stuff.
Windows 7+ users, help your Mac & Linux brothers out by buying a copy! ;)

@Mark

OK, the viewport stuff is probably a good place to start since it's pretty simple.

So at the beginning of the project we had to decide on a virtual screen size to keep everything at the right scale. Backgrounds would be at this size which is basically the maximum resolution the game supports before it is scaling the background up. The resolution we chose was 2048x1152.

create vres 2048 , 1152 ,

Our goal was to present the game at a fixed aspect ratio no matter what display the user has. Like a movie, it would be automatically letterboxed if the aspect ratio of the display was different.

https://www.dropbox.com/s/4le7axhg6il3s0h/Screenshot%202014-02-26%2013.10.20.png

To get Allegro to transform the display we need a matrix structure. That's just a 4x4 contiguous 2d array of cells:

create viewm 16 cells allot

Also we are going to store the scale we calculate for things like mouse-clicking. This is used in the in-game level editor.

variable viewfactor 1.0 viewfactor ! \ default

Here are some shorthands for getting virtual screen width and height.

: vw vres @ ;
: vh vres cell+ @ ;

: svh vh 1p viewfactor @ p* ; \ scaled vh

And this stores the thickness of the top black bar, for the same reason as VIEWFACTOR. But also to display the "quit?" message at the right Y offset relative to the window, because my math is sloppy.

variable topoffset

So here's the meat of the letterboxing code.

: calc-viewport
displaywh 2p locals| h w |
w 2 + vw 1p p/ dup viewfactor !

( scale ) p>f fdup viewm al_scale_transform

h 2 / svh 2 / - dup topoffset !
dup -1e p>f viewm al_translate_transform

viewm al_use_transform

( y ) 2 swap 1i 2 + w svh 2i 4 4 2- al_set_clipping_rectangle
;

: update-viewport
viewm al_identity_transform calc-viewport ;

Operators that have letter P are fixed-point (16.16)

First we find VIEWFACTOR then we find TOPOFFSET (vertical centering) transforming our matrix as we go and then telling Allegro to use it.

At the end, I cut off a 2 pixel margin on all sides to hide pixel offset artifacts that led to weird stuff like foreground overlays not always covering the whole screen. It's just because working in OpenGL for 2D is weird sometimes.

UPDATE-VIEWPORT is called every frame, ensuring that even if the game was displayed in a window (which it was during development) it will scale-to-fit in real time.