Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #30077 > unrolled thread

A new commercial indie game made in SwiftForth (Windows)

Back to article view | Back to comp.lang.forth

Contents

  A new commercial indie game made in SwiftForth (Windows) roger.levy@gmail.com - 2014-05-03 21:19 -0700
    Re: A new commercial indie game made in SwiftForth (Windows) Paul Rubin <no.email@nospam.invalid> - 2014-05-03 22:22 -0700
    Re: A new commercial indie game made in SwiftForth (Windows) AKK <akk@nospam.org> - 2014-05-04 08:24 +0200
      Re: A new commercial indie game made in SwiftForth (Windows) Laurent Laborde <kerdezixe@gmail.com> - 2014-05-04 03:44 -0700
        Re: A new commercial indie game made in SwiftForth (Windows) AKK <akk@nospam.org> - 2014-05-04 14:46 +0200
          Re: A new commercial indie game made in SwiftForth (Windows) Mark Wills <markwills1970@gmail.com> - 2014-05-04 09:21 -0700
            Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-04 13:28 -0700
              Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-04 13:38 -0700
                Re: A new commercial indie game made in SwiftForth (Windows) Mark Wills <markwills1970@gmail.com> - 2014-05-04 13:53 -0700
      Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-04 13:36 -0700
        Re: A new commercial indie game made in SwiftForth (Windows) AKK <akk@nospam.org> - 2014-05-04 23:27 +0200
          Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-04 14:39 -0700
          Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-04 14:44 -0700
            Re: A new commercial indie game made in SwiftForth (Windows) AKK <akk@nospam.org> - 2014-05-05 07:35 +0200
    Re: A new commercial indie game made in SwiftForth (Windows) Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-04 21:51 -0700
      Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-05 09:49 -0700
        Re: A new commercial indie game made in SwiftForth (Windows) Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-05 22:55 -0700
          Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 01:21 -0700
            Re: A new commercial indie game made in SwiftForth (Windows) Paul Rubin <no.email@nospam.invalid> - 2014-05-07 02:07 -0700
              Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 07:12 -0700
                Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 07:15 -0700
                  Re: A new commercial indie game made in SwiftForth (Windows) Richard Owlett <rowlett@pcnetinc.com> - 2014-05-07 09:28 -0500
                  Re: A new commercial indie game made in SwiftForth (Windows) Paul Rubin <no.email@nospam.invalid> - 2014-05-07 09:23 -0700
                    Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 09:56 -0700
                      Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 09:57 -0700
                        Re: A new commercial indie game made in SwiftForth (Windows) Paul Rubin <no.email@nospam.invalid> - 2014-05-07 10:02 -0700
                          Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 10:08 -0700
                            Re: A new commercial indie game made in SwiftForth (Windows) Paul Rubin <no.email@nospam.invalid> - 2014-05-07 12:03 -0700
                              Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 12:12 -0700
                        Re: A new commercial indie game made in SwiftForth (Windows) "Elizabeth D. Rather" <erather@forth.com> - 2014-05-07 08:16 -1000
                          Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 11:33 -0700
                            Re: A new commercial indie game made in SwiftForth (Windows) hughaguilar96@yahoo.com - 2014-05-07 22:32 -0700
                              Re: A new commercial indie game made in SwiftForth (Windows) Howerd <howerdo@yahoo.co.uk> - 2014-05-08 01:50 -0700
                                Re: A new commercial indie game made in SwiftForth (Windows) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-08 10:24 +0000
                                  Re: A new commercial indie game made in SwiftForth (Windows) Elizabeth D Rather <erather@forth.com> - 2014-05-08 09:05 -1000
                                Re: A new commercial indie game made in SwiftForth (Windows) Elizabeth D Rather <erather@forth.com> - 2014-05-08 09:00 -1000
                                  Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-08 12:09 -0700
                                    Re: A new commercial indie game made in SwiftForth (Windows) stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-08 20:11 +0000
                                      Re: A new commercial indie game made in SwiftForth (Windows) Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-09 01:22 +0200
                                        Re: A new commercial indie game made in SwiftForth (Windows) "Elizabeth D. Rather" <erather@forth.com> - 2014-05-08 17:08 -1000
                                    Re: A new commercial indie game made in SwiftForth (Windows) Elizabeth D Rather <erather@forth.com> - 2014-05-08 11:24 -1000
                                      Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-08 15:25 -0700
                                      Re: A new commercial indie game made in SwiftForth (Windows) Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-09 01:30 +0200
                                        Re: A new commercial indie game made in SwiftForth (Windows) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 08:42 +0000
                                          Re: A new commercial indie game made in SwiftForth (Windows) Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-10 15:30 +0200
                                            Re: A new commercial indie game made in SwiftForth (Windows) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 14:11 +0000
                                              Re: A new commercial indie game made in SwiftForth (Windows) Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-10 16:26 +0200
                                                Re: A new commercial indie game made in SwiftForth (Windows) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 14:37 +0000
                                                  Re: A new commercial indie game made in SwiftForth (Windows) Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-10 21:17 +0200
                                          Re: A new commercial indie game made in SwiftForth (Windows) "Elizabeth D. Rather" <erather@forth.com> - 2014-05-10 10:45 -1000
                                            Re: A new commercial indie game made in SwiftForth (Windows) Mark Wills <markwills1970@gmail.com> - 2014-05-10 14:28 -0700
                                              Re: A new commercial indie game made in SwiftForth (Windows) "Elizabeth D. Rather" <erather@forth.com> - 2014-05-10 11:41 -1000
                                                Re: A new commercial indie game made in SwiftForth (Windows) Mark Wills <markwills1970@gmail.com> - 2014-05-10 14:47 -0700
                                      Re: A new commercial indie game made in SwiftForth (Windows) Laurent Laborde <kerdezixe@gmail.com> - 2014-05-09 03:08 -0700
                                    Re: A new commercial indie game made in SwiftForth (Windows) Mark Wills <markwills1970@gmail.com> - 2014-05-08 14:44 -0700
                      Re: A new commercial indie game made in SwiftForth (Windows) "Alex McDonald" <blog@rivadpm.com> - 2014-05-07 20:18 +0100
                        Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-07 12:34 -0700
                          Re: A new commercial indie game made in SwiftForth (Windows) "Alex McDonald" <blog@rivadpm.com> - 2014-05-09 15:55 +0100
                            Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-09 10:22 -0700
                              Re: A new commercial indie game made in SwiftForth (Windows) "Alex McDonald" <blog@rivadpm.com> - 2014-05-09 22:13 +0100
                                Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-09 15:15 -0700
                          Re: A new commercial indie game made in SwiftForth (Windows) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 03:09 +0000
                            Re: A new commercial indie game made in SwiftForth (Windows) mhx@iae.nl - 2014-05-09 23:06 -0700
                              Re: A new commercial indie game made in SwiftForth (Windows) "Alex McDonald" <blog@rivadpm.com> - 2014-05-10 09:01 +0100
                            Parameter passing when calling C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 09:02 +0000
                              Re: Parameter passing when calling C stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-10 14:40 +0000
                                Re: Parameter passing when calling C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 15:26 +0000
                                  Re: Parameter passing when calling C stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-11 09:46 +0000
                                    Re: Parameter passing when calling C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-11 14:57 +0000
                                    Re: Parameter passing when calling C Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 20:37 +0200
            Re: A new commercial indie game made in SwiftForth (Windows) Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-07 04:03 -0700
    Re: A new commercial indie game made in SwiftForth (Windows) Zbigniew <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2014-05-07 16:19 +0000
    Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-11 11:49 -0700
      Re: A new commercial indie game made in SwiftForth (Windows) foxaudioresearch@gmail.com - 2014-05-12 18:34 -0700
        Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-13 06:40 -0700
          Re: A new commercial indie game made in SwiftForth (Windows) Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-13 23:55 -0700
          Re: A new commercial indie game made in SwiftForth (Windows) Mark Wills <markwills1970@gmail.com> - 2014-05-14 01:39 -0700
            Re: A new commercial indie game made in SwiftForth (Windows) Roger Levy <roger.levy@gmail.com> - 2014-05-14 07:08 -0700

Page 4 of 4 — ← Prev page 1 2 3 [4]

#30230

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.

[toc] | [prev] | [next] | [standalone]

#30234

In article <d46f6240-63f8-4dbc-86c2-5d45d4f28496@googlegroups.com>,
Roger Levy  <roger.levy@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.

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

[toc] | [prev] | [next] | [standalone]

#30238

On Saturday, May 10, 2014 5:09:24 AM UTC+2, Albert van der Horst wrote:
> In article <d46f6240-63f8-4dbc-86c2-5d45d4f28496@googlegroups.com>,
> Roger Levy  <roger.levy@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

[toc] | [prev] | [next] | [standalone]

#30239

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-86c2-5d45d4f28496@googlegroups.com>,
> > wrote:
>> Roger Levy  <roger.levy@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...

[toc] | [prev] | [next] | [standalone]

#30241 — Parameter passing when calling C

albert@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.

- 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/

[toc] | [prev] | [next] | [standalone]

#30255 — Re: Parameter passing when calling C

On Sat, 10 May 2014 09:02:12 GMT, anton@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 ...

Stephen

-- 
Stephen Pelc, stephenXXX@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

[toc] | [prev] | [next] | [standalone]

#30261 — Re: Parameter passing when calling C

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Sat, 10 May 2014 09:02:12 GMT, anton@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.

- 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/

[toc] | [prev] | [next] | [standalone]

#30283 — Re: Parameter passing when calling C

On Sat, 10 May 2014 15:26:22 GMT, anton@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.

Stephen

-- 
Stephen Pelc, stephenXXX@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

[toc] | [prev] | [next] | [standalone]

#30293 — Re: Parameter passing when calling C

stephenXXX@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.

- 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/

[toc] | [prev] | [next] | [standalone]

#30298 — Re: Parameter passing when calling C

Stephen Pelc wrote:

> On Sat, 10 May 2014 15:26:22 GMT, anton@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.

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

[toc] | [prev] | [next] | [standalone]

#30147

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!

[toc] | [prev] | [next] | [standalone]

#30152

In comp.lang.forth, roger.levy@gmail.com wrote:

> 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.

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

[toc] | [prev] | [next] | [standalone]

#30299

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

[toc] | [prev] | [next] | [standalone]

#30319

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)  ;-)

[toc] | [prev] | [next] | [standalone]

#30334

On Monday, May 12, 2014 9:34:25 PM UTC-4, foxaudio...@gmail.com wrote:
> 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)  ;-)

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.

[toc] | [prev] | [next] | [standalone]

#30351

On Tuesday, May 13, 2014 5:40:18 PM UTC+4, Roger Levy wrote:
> On Monday, May 12, 2014 9:34:25 PM UTC-4, foxaudio...@gmail.com wrote:
> 
> > 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) ;-)
> 
> 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.

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

[toc] | [prev] | [next] | [standalone]

#30354

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.

[toc] | [prev] | [next] | [standalone]

#30369

On Wednesday, May 14, 2014 4:39:14 AM UTC-4, Mark Wills wrote:
> 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.

@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.

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.forth

csiph-web