Conor Stokes | 1 Mar 09:08 2008
Picon

Re: Coroutines for AI

>Anyway, fibers FTW for long-running operations that need to wait for 
>various kinds of completion, if you can handle the 
>error/failure/cancellation cases reasonably.

If you don't mind the initial implementation pain it can be well worth it to layer a fiber abstraction on top
of an extended work queue/thread pool system. This can be a great way to handle error/failure/completion
because you can do it all with a simple structure that gets passed on the queue that includes the fiber
context and any error/result information (or a simple structure + a work function/delegation if you want
to generalize things more). 

It can be a very nice way to implement CSP (Communicating Sequential Processes) in a C based language.

Cheers,
Conor

P.S. If you are on a platform that has a good IO Completion Portimplementation (some non-Microsoft
platforms have them now as well),you can use this for your work queue and get the benefits of IOCompletion
Events and scheduling magic.

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Brandon Van Every | 5 Mar 22:31 2008
Picon

CMake vs. the competition

I gave up on CMake.  Well, "had a showdown about it," or "got ridden
out of town on a rail," might be more precise, but people can look it
up in the CMake mailing list archives if they want the details.

Backing up for a moment... recently I worked on an Autoconf + GMake
--> CMake conversion for Firefox.  I was unsuccessful.  That wasn't
CMake's fault; rather, migrating a huge monolithic Autoconf + GMake
build is hard.  I attempted to do it with an automatic translator, so
that once Firefox was converted, everything at Mozilla could be
converted also.  I got pretty far, far enough to prove that it could
be done, but not far enough in the time available.  Mozilla has made
the code I wrote available.  They own it, and it is under their usual
tri-license.  https://bugzilla.mozilla.org/show_bug.cgi?id=416982

Subsequently, I annoyed Kitware's developers about CMake's
deficiencies so much that we simply couldn't work together anymore.
These all stemmed from debates about the inadequacies of CMake script,
its nasty corner cases, the lack of documentation for those corner
cases, and whether to replace it with Lua.  Now that I no longer care
about Kitware's support burdens or financial interest in the product,
I see it more objectively.  People have been handing me bitter
complaints about CMake script for quite some time.  It's too much of a
sow's ear to become the world's One True Build Language.  I've
defended it, and have tried to transform the complaints into action
within the CMake community, but I am not socially or politically
skilled enough to do so.  So we have parted ways.

Leading up to this, I did several surveys of competing tools, trying
to understand the implications of mainstream programming languages vs.
CMake script.
(Continue reading)

David Neubelt | 5 Mar 22:35 2008

Re: CMake vs. the competition

There is also KJam. http://www.oroboro.com/kjam/docserv.php

-= Dave

-----Original Message-----
From: Brandon Van Every [mailto:bvanevery <at> gmail.com] 
Sent: Wednesday, March 05, 2008 1:32 PM
To: sweng-gamedev <at> midnightryder.com
Subject: [Sweng-Gamedev] CMake vs. the competition

I gave up on CMake.  Well, "had a showdown about it," or "got ridden
out of town on a rail," might be more precise, but people can look it
up in the CMake mailing list archives if they want the details.

Backing up for a moment... recently I worked on an Autoconf + GMake
--> CMake conversion for Firefox.  I was unsuccessful.  That wasn't
CMake's fault; rather, migrating a huge monolithic Autoconf + GMake
build is hard.  I attempted to do it with an automatic translator, so
that once Firefox was converted, everything at Mozilla could be
converted also.  I got pretty far, far enough to prove that it could
be done, but not far enough in the time available.  Mozilla has made
the code I wrote available.  They own it, and it is under their usual
tri-license.  https://bugzilla.mozilla.org/show_bug.cgi?id=416982

Subsequently, I annoyed Kitware's developers about CMake's
deficiencies so much that we simply couldn't work together anymore.
These all stemmed from debates about the inadequacies of CMake script,
its nasty corner cases, the lack of documentation for those corner
cases, and whether to replace it with Lua.  Now that I no longer care
about Kitware's support burdens or financial interest in the product,
(Continue reading)

Jon Watte | 5 Mar 22:59 2008

Re: CMake vs. the competition


Have you looked at premake?

Sincerely,

jw

Brandon Van Every wrote:
> I gave up on CMake.  Well, "had a showdown about it," or "got ridden
>   

> http://code.google.com/p/waf/ - Waf is Python 2.3 based.  Written by
> an intelligent author disaffected with SCons politics.  Its
> predecessor, BKsys, was intended to be KDE's new build system, but
> CMake won out instead.  I'm lurking on Waf's mailing list to learn
> more about it.
>   

--

-- 

  Go is to Western chess what philosophy is to double entry accounting. 

  Forterra Systems is looking for superstar engineers, managers and artists to help 
  develop the highest-quality enterprise virtual world available on the market.
  E-mail me for details.

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
(Continue reading)

Brandon Van Every | 5 Mar 23:53 2008
Picon

Re: CMake vs. the competition

On Wed, Mar 5, 2008 at 4:59 PM, Jon Watte <hplus <at> mindcontrol.org> wrote:
>
>  Have you looked at premake?

Briefly, and also Bou , both based on Lua.
http://premake.sourceforge.net/
http://lua-users.org/wiki/LuaBuildBou

I don't think either has large projects to their credit, so at the
time, I didn't think they could say anything about the merits of OO or
other higher level programming approaches for large build systems.  I
also concluded that for small to medium sized projects, like 100K LOC
or less, the technical underpinnings of the build system don't matter
as long as they're basically sane.  Projects of that size simply don't
have enough of a build system to warrant technical angst.
Nevertheless there are substantial marketing and documentation reasons
to prefer mainstream languages.  I could probably stand to look at the
Lua-based tools again, now that I no longer have such a CMake-centric
perspective.

Kitware is uncommitted to adding Lua at this time, but they have
demonstrated proof of concept.  I suspect that they will ship CMake
2.6.0, see how people like the new function and scope features, and
then decide whether they'll do Lua officially for 2.8.0.  Which I
think means 1..2 years out, and no promises from them about doing it
at all.  But in the 3 months or so that I was hammering away at the
pros and cons of the subject, they moved from a position of "we don't
want to support 2 languages indefinitely" to "we're capable of
supporting 2 languages indefinitely."  They didn't want to hear it
about my auto-translation proposals, that's part of what caused us to
(Continue reading)

Darren Grant | 6 Mar 00:34 2008

Re: Coroutines for AI

What sort of performance are you getting from LuaPlus? 

My experience is with Win32 fibers so far and they still have a fairly
significant overhead for context switches (invoked from c#), so I won't
be liberally scheduling thousands of active agents this way.  But point
taken from others that there are still big win situations for a handful
of long-running processes.

Joel Pritchett wrote:
> In the past I've made heavy use of Lua coroutines for AI programming
> and I thought it worked wonderfully. Debugging Lua at the time (4
> years ago?) was very difficult as no good debuggers were available,
> but that isn't the case anymore. If your interested check out LuaPlus,
> which we're using currently.
>
> j
>
> On Fri, Feb 29, 2008 at 4:28 AM, Tom Plunket <gamedev <at> fancy.org
> <mailto:gamedev <at> fancy.org>> wrote:
>
>     > Does anyone have anything to say for/against using coroutines to
>     > implement AI?
>
>     Any code I've ever seen implemented as coroutines became much easier
>     to understand, debug, and generally grok when reimplemented to not
>     have such a nasty hack at its root.  Oftentimes a simple state
>     machine with per-tick update achieves the exact same effect.
>
>     -tom!
>     _______________________________________________
(Continue reading)

Darren Grant | 6 Mar 01:08 2008

Re: Coroutines for AI

Jon Watte wrote:
>
> I have to say, though, that the code flow is a lot easier to read and
> understand and modify in the fiber version than in the state machine
> version.
>
> Cheers,
>
>             / h+

Yea this is ultimately what I'm trying to integrate with AI models,
being able to complete a process without leaving the lexical
environment.  If performance wasn't an issue (well duh ;) ) it wouldn't
really matter to me how it is done internally because the benefit of not
having to roll your own environment for every parallel process is huge. 
I guess any language that binds closures to the lexical environment they
come from is already a big leg up.

Regards,
Darren

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Jon Watte | 6 Mar 01:38 2008

Re: Coroutines for AI


The talk about Stackless Python at this years' GDC had the same comment 
-- you can't expect to run 1,000s of active tasks at the same time 
without being hammered by overhead costs. It's not a panacea for very 
small things.

Sincerely,

jw

Darren Grant wrote:
> What sort of performance are you getting from LuaPlus? 
>
> My experience is with Win32 fibers so far and they still have a fairly
> significant overhead for context switches (invoked from c#), so I won't
> be liberally scheduling thousands of active agents this way.  But point
> taken from others that there are still big win situations for a handful
> of long-running processes.
>   

--

-- 

  Go is to Western chess what philosophy is to double entry accounting. 

  Forterra Systems is looking for superstar engineers, managers and artists to help 
  develop the highest-quality enterprise virtual world available on the market.
  E-mail me for details.

_______________________________________________
Sweng-Gamedev mailing list
(Continue reading)

Joel Pritchett | 6 Mar 02:21 2008
Picon

Re: Coroutines for AI

> What sort of performance are you getting from LuaPlus?
I haven't seen it be an issue when profiling, thats really all I can say about that.

Even back on the xbox and ps2 we used a heavy amount of lua and it wasn't really a problem. I really think the performance of the language versus c++ is far less important than how you use it in your engine.

For example, one of our AI scripts looked sort of like this (this is just psuedo code, not compilable lua).

function Patrol( point[] waypoints )
{
    foreach( point waypoint in waypoints )
    {
           GoToPoint( waypoint, OnInterruption )
    }
}

function OnInterruption( reason )
{
     if( reason == eEnemySpotted )
     {
           Attack()
     }
     ....
}

The function 'GoToPoint' would call into C++ and not return to the LUA script until it reached its destination or the character was interrupted. GoToPoint did things like sort out pathfinding and what animation to play, stuff that we decided was too low level for LUA. In this particular architecture, each character ends up running a couple of lines of lua every few seconds and it isn't something that you are likely to ever see be an issue. The things that did end up being slow would have been slow in C++ too.

j

On Thu, Mar 6, 2008 at 9:34 AM, Darren Grant <dgrant <at> kerberos-productions.com> wrote:
What sort of performance are you getting from LuaPlus?

My experience is with Win32 fibers so far and they still have a fairly
significant overhead for context switches (invoked from c#), so I won't
be liberally scheduling thousands of active agents this way.  But point
taken from others that there are still big win situations for a handful
of long-running processes.



Joel Pritchett wrote:
> In the past I've made heavy use of Lua coroutines for AI programming
> and I thought it worked wonderfully. Debugging Lua at the time (4
> years ago?) was very difficult as no good debuggers were available,
> but that isn't the case anymore. If your interested check out LuaPlus,
> which we're using currently.
>
> j
>
> On Fri, Feb 29, 2008 at 4:28 AM, Tom Plunket <gamedev <at> fancy.org
> <mailto:gamedev <at> fancy.org>> wrote:
>
>     > Does anyone have anything to say for/against using coroutines to
>     > implement AI?
>
>     Any code I've ever seen implemented as coroutines became much easier
>     to understand, debug, and generally grok when reimplemented to not
>     have such a nasty hack at its root.  Oftentimes a simple state
>     machine with per-tick update achieves the exact same effect.
>
>     -tom!
>     _______________________________________________
>     Sweng-Gamedev mailing list
>     Sweng-Gamedev <at> lists.midnightryder.com
>     <mailto:Sweng-Gamedev <at> lists.midnightryder.com>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sweng-Gamedev mailing list
> Sweng-Gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.21.1/1303 - Release Date: 2/28/2008 12:14 PM

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Davis Sickmon | 6 Mar 04:43 2008

Paris GDC Call For Papers

Howdy All - 
   The "Call For Papers" that I mentioned got back to me with information - and a real tight schedule :-)  Attached is the email he wanted me to post below:

-------------

Davis,

Thanks for your answer!
I would be really happy if you could post the call for paper for me if it does not take too much time for you. Please let me know. I hope my message is not too formal. 

"GDC is moving to Paris next June 23-24. We are looking for speakers able to communicate and present their thoughts and works on the hottest topics of our industry. This is the right opportunity for you to share best practices with the rest of the community and value your company and your expertise on an international scale. If you wish to apply as a speaker, please post your submission for the call for paper by Friday March 7th. We know the deadline is soon but I just learned about this list !

Here is the link for Paris GDC: http://www.parisgdc.com/ 
Regarding the call for paper more specifically : 
- Call for paper submission guidelines: http://www.parisgdc.com/Call_for_Paper_fr.pdf
- Link for call for paper: https://www.cmpevents.com/GDPA08/a.asp?option=N&V=3&CPid=223 
The advisory board will evaluate the submissions. Do not hesitate any longer, the call for paper ends on March 7th!
Shall you have any questions, please get back to me. If you wish to apply to the call for paper but you think you won't be able to answer in due time, please let me know.

Best Regards
Clement Galiay
cgaliay <at> parisgdc.com
Ph:+33 426 234 121"

-------------

Davis Ray Sickmon, Jr
Midnight Ryder Technologies
SWEng-GameDev List Admin
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Gmane