Thread: RE: [GD-General] Off the shelf scripting languages
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Gareth L. <GL...@cl...> - 2003-04-17 09:10:24
|
> -----Original Message----- > From: Marc Fascia [mailto:ma...@ma...] > It seems that Python, Lua and Ruby are > popular choices in that topic. Other good choises are tcl, and javascript/vbscript if this is a win32 only product. _______________________ Regards, Gareth Lewin Programmer, Climax Solent. (To anyone outside Climax, sorry for the disclaimer below) DISCLAIMER: Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and Climax Development Ltd. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and contact the originator of the email. In accordance with the Telecommunications (Lawful Business Regulations) (Interception of Communications) Regulations 2000 the Company reserves the right and, may at any time, monitor and intercept (but not record) e-mails to establish if they are relevant to its business. |
|
From: Gareth L. <GL...@cl...> - 2003-04-17 19:18:59
|
Hi. > JavaScript: x-platform if you grab the Mozilla > implementation; not sure > what the footprint would be on a console, and of course you have the > garbage collection issue. Language is very nice though and of course > there's plenty of reference material out there. I mainly refered to the COM scripting host, which is incredably powerful. I forgot about Javascript as a standa along language. > Tcl: Not my cup of tea but may be someone else's? Lets not get into a issue of preferances. But the big 3 scripting languages ( Perl,Tcl and Python ) are all very powerful scripting languages are will all pretty much work very well for every game. They each have their strengths and weaknesses. Tcl is probably the "lightest" of the 3 and the most suitable as a "glue" language (That's what it was designed for). Python is "fatter", but also has more features, and would be more suitable for a game that is very heavy in script. Perl is somewhere in the middle, but to me it's more of a standalone language and less of a "glue". Also Perl is very good at a lot of things that are very irrelevant for games ( regex, string handling etc ). > Simkin: Language features are nice, but I don't want to write No opinions, never used. > Python: if it proves to be viable on consoles (I'm watching > others and > hoping for the best) I would be very happy. I haven't seen other > languages with anything close to Boost.Python for > ease-of-integration; > it is seriously impressive: http://www.boost.org/libs/python/doc/. > Other positives are same as JavaScript: lots of reference > material, very > readable, etc. See above. I would be interested to see what the overhead of python is. It's faster than tcl, but it's VM is "big". On a side note, FUBI is FAR more easy to integrate than Boost.Python, and we use it for our propriety scripting language and it's a huge boon. The subject of "off the shelf" vs "self made" in not in the scope of the original question though. DISCLAIMER: Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and Climax Development Ltd. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and contact the originator of the email. In accordance with the Telecommunications (Lawful Business Regulations) (Interception of Communications) Regulations 2000 the Company reserves the right and, may at any time, monitor and intercept (but not record) e-mails to establish if they are relevant to its business. |
|
From: Jones, C. <CJ...@bl...> - 2003-04-17 23:41:35
|
We are currently using Small on a large-scale PC RPG and a PS2/Xbox action RPG. It was also used on Baldurs Gate: Dark Alliance for the PS2 and Xbox. Small is relatively lightweight and about as trivial to integrate as Lua. I think Lua is a more flexible language in a lot of ways, but is sometimes more difficult for people to grasp. Small is really just a lightweight, typeless version of C, so anyone familiar with C will be comfortable with it. -Chris -----Original Message----- From: Brian Hook [mailto:ho...@py...] Sent: Thursday, April 17, 2003 3:59 PM To: gam...@li... Subject: Re: [GD-General] Off the shelf scripting languages >on every platform. Lua is write in clear ANSI C++ and is light. Port Small correction -- Lua is written in clear ANSI C, and it compiles cleanly with a C++ compiler as well. It's also been used by many commercial games and it's incredibly lightweight. Its syntax isn't too bad either. Lua's biggest "problem" is that it lacks a comprehensive set of "blessed" external libraries, something Python is very good with, however if you just need a scripting language, it's great. Another, less popular, alternative is Small, which has nice clean documentation, a familiar syntax and seems to be reasonably popular as well. -Hook ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
|
From: Gareth L. <GL...@cl...> - 2003-04-18 07:56:17
|
> -----Original Message----- > From: Jones, Chris [mailto:CJ...@bl...] > > Small is relatively lightweight and about as trivial to > integrate as Lua. I > think Lua is a more flexible language in a lot of ways, but > is sometimes > more difficult for people to grasp. Small is really just a > lightweight, > typeless version of C, so anyone familiar with C will be > comfortable with > it. > That sounds very much like GEL (Our internal scripting language being used on Sudeki). The problem we have is that our goal is for designers to use the scripting language, and they are, but the C like syntax is a bit of a curve that shouldn't be needed. DISCLAIMER: Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and Climax Development Ltd. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and contact the originator of the email. In accordance with the Telecommunications (Lawful Business Regulations) (Interception of Communications) Regulations 2000 the Company reserves the right and, may at any time, monitor and intercept (but not record) e-mails to establish if they are relevant to its business. |
|
From: Gareth L. <GL...@cl...> - 2003-04-18 07:57:21
|
> From: gekido [mailto:ge...@ub...] > the syntax IS a bit wierd, but here's a few samples from the Reality > Factory implementation - it's definitely not XML ;} > > http://rfactory.uber-geek.ca/docs/Con_Scripting.htm > > http://rfactory.uber-geek.ca/docs/PawnScript.htm > > { > Start[ () > { > SetTerrain("flat.bmp", "desert256.bmp"); > SetSkyDome(400, 64); > SetSkyTexture("clouds_256.bmp"); > SetSkyColor(164, 200, 255, 255); > SetTimeScale(700); > DisableSun(false); > DisableCloud(false); > UseSkyFog(false); > } ] > > Run[ () > { > SetWindDirection("north"); > } ] > } Impressive, I've now added Simkin to my list of things to look at :) DISCLAIMER: Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and Climax Development Ltd. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and contact the originator of the email. In accordance with the Telecommunications (Lawful Business Regulations) (Interception of Communications) Regulations 2000 the Company reserves the right and, may at any time, monitor and intercept (but not record) e-mails to establish if they are relevant to its business. |
|
From: Tom F. <to...@mu...> - 2003-04-22 13:03:23
|
Python works well for us on all the consoles (NGC, PS2, XBox). We're using SWIG as a C++ interface rather than Boost, simply because Boost depends on fancy stuff that compilers don't necessarily deal with properly. Whereas SWIG is relatively simple code, but seems equivalently powerful - mix and match between C and Python classes, call either from the other, stuff like that. You need some custom allocators on consoles, otherwise fragmentation is a problem, but I'm sure that's true of all scripting languages, and indeed true of most problems. Python's garbage collector is actually pretty smart, and we've not had any problems with "free cascades" or anything scary like that. Don't believe the hype. Python may be overkill if you just want a level-simple scripting language. We're using it for the majority of high-level gameplay as well as level scripting - basically everything but rendering, sound, world management and all the fairly low-level stuff like that. For that, it's very good. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: brian sharon [mailto:pud...@po...] > Sent: 17 April 2003 19:09 > To: gam...@li... > Subject: Re: [GD-General] Off the shelf scripting languages > > > JavaScript: x-platform if you grab the Mozilla > implementation; not sure > what the footprint would be on a console, and of course you have the > garbage collection issue. Language is very nice though and of course > there's plenty of reference material out there. > > Tcl: Not my cup of tea but may be someone else's? > > Simkin: Language features are nice, but I don't want to write > script in > XML. And the other file format looks even less clear, if that's > possible: look at http://www.simkin.co.uk/Docs/Simkin/Example.s.txt. > What goes in the brackets? Well, brackets seem to group method > arguments with the method body. Except when they're used to > block out > comments. But comments can also follow double slashes. > Hmmmm. Well, > I'm sure I can count on my designers to sort it all out...I > mean, they > already *almost* understand what a source control system > does, so this > should be cake. > > Python: if it proves to be viable on consoles (I'm watching > others and > hoping for the best) I would be very happy. I haven't seen other > languages with anything close to Boost.Python for > ease-of-integration; > it is seriously impressive: http://www.boost.org/libs/python/doc/. > Other positives are same as JavaScript: lots of reference > material, very > readable, etc. > > --brian > > > Gareth Lewin wrote: > > >>-----Original Message----- > >>From: Marc Fascia [mailto:ma...@ma...] > >>It seems that Python, Lua and Ruby are > >>popular choices in that topic. > >> > >> > > > >Other good choises are tcl, and javascript/vbscript if this > is a win32 only > >product. > >_______________________ > >Regards, Gareth Lewin > >Programmer, Climax Solent. > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Andrew P. <aj...@eu...> - 2003-04-22 20:56:33
|
I agree with Tom here. I fail to see the great advantage of boost over swig in this case. After trying both under VC++ (and therein lies boosts problem - speed) swig wins hands down. It really isn't any more effort than using boost and is certainly easier to debug if things go wrong. Andrew Perella -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Tom Forsyth Sent: 22 April 2003 13:59 To: gam...@li... Subject: RE: [GD-General] Off the shelf scripting languages Python works well for us on all the consoles (NGC, PS2, XBox). We're using SWIG as a C++ interface rather than Boost, simply because Boost depends on fancy stuff that compilers don't necessarily deal with properly. Whereas SWIG is relatively simple code, but seems equivalently powerful - mix and match between C and Python classes, call either from the other, stuff like that. You need some custom allocators on consoles, otherwise fragmentation is a problem, but I'm sure that's true of all scripting languages, and indeed true of most problems. Python's garbage collector is actually pretty smart, and we've not had any problems with "free cascades" or anything scary like that. Don't believe the hype. Python may be overkill if you just want a level-simple scripting language. We're using it for the majority of high-level gameplay as well as level scripting - basically everything but rendering, sound, world management and all the fairly low-level stuff like that. For that, it's very good. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: brian sharon [mailto:pud...@po...] > Sent: 17 April 2003 19:09 > To: gam...@li... > Subject: Re: [GD-General] Off the shelf scripting languages > > > JavaScript: x-platform if you grab the Mozilla > implementation; not sure > what the footprint would be on a console, and of course you have the > garbage collection issue. Language is very nice though and of course > there's plenty of reference material out there. > > Tcl: Not my cup of tea but may be someone else's? > > Simkin: Language features are nice, but I don't want to write > script in > XML. And the other file format looks even less clear, if that's > possible: look at http://www.simkin.co.uk/Docs/Simkin/Example.s.txt. > What goes in the brackets? Well, brackets seem to group method > arguments with the method body. Except when they're used to > block out > comments. But comments can also follow double slashes. > Hmmmm. Well, > I'm sure I can count on my designers to sort it all out...I > mean, they > already *almost* understand what a source control system > does, so this > should be cake. > > Python: if it proves to be viable on consoles (I'm watching > others and > hoping for the best) I would be very happy. I haven't seen other > languages with anything close to Boost.Python for > ease-of-integration; > it is seriously impressive: http://www.boost.org/libs/python/doc/. > Other positives are same as JavaScript: lots of reference > material, very > readable, etc. > > --brian > > > Gareth Lewin wrote: > > >>-----Original Message----- > >>From: Marc Fascia [mailto:ma...@ma...] > >>It seems that Python, Lua and Ruby are > >>popular choices in that topic. > >> > >> > > > >Other good choises are tcl, and javascript/vbscript if this > is a win32 only > >product. > >_______________________ > >Regards, Gareth Lewin > >Programmer, Climax Solent. > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557 _____________________________________________________________________ This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322 _____________________________________________________________________ This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322 |
|
From: Ivan-Assen I. <as...@ha...> - 2003-04-22 21:37:40
|
> Python works well for us on all the consoles (NGC, PS2, XBox). How do you store the state of the interpreters, or does the "no arbitrary moment savegames" nature of most console games save you from this? Resolving the pointers embedded within interpreter stacks was one of the two major issues we had to resolve for our custom scripting system - and that we don't want to have to resolve yet again. On the other hand, our custom scripting language sucks in more ways than one, and I would be happy to scrap it and integrate a "real language" instead. (Latent functions a la UnrealScript being the other major issue, but Stackless Python seems to be able to support that.) regards, Assen |
|
From: Thatcher U. <tu...@tu...> - 2003-04-23 05:35:48
|
On Apr 23, 2003 at 12:37 +0300, Ivan-Assen Ivanov wrote: > > Python works well for us on all the consoles (NGC, PS2, XBox). > > How do you store the state of the interpreters, or does > the "no arbitrary moment savegames" nature of most console > games save you from this? > > Resolving the pointers embedded within interpreter stacks > was one of the two major issues we had to resolve for our > custom scripting system - and that we don't want to have to > resolve yet again. On the other hand, our custom scripting > language sucks in more ways than one, and I would be happy > to scrap it and integrate a "real language" instead. > > (Latent functions a la UnrealScript being the other > major issue, but Stackless Python seems to be able > to support that.) The latest version of Lua (5.0) is mostly "stackless", so latent functions are supported, and so you don't have troubles with interpreter state embedded in the C stack (if that's the problem you're referring to). You would still have to write some code to serialize the VM and heap state. -- Thatcher Ulrich http://tulrich.com |
|
From: Ivan-Assen I. <as...@ha...> - 2003-04-23 12:10:38
|
> The latest version of Lua (5.0) is mostly "stackless", so > latent functions are supported, and so you don't have > troubles with interpreter state embedded in the C stack (if > that's the problem you're referring to). You would still > have to write some code to serialize the VM and heap state. There are two separate problems. To support latent functions, the interpreter must be able to yield (as in "yield vs. return" when you talk about coroutines) control back to the thread scheduler that runs it when it encounters a latent function call - this is more convoluted than the usual "run this script for it's side effects and return a value when it's done" model of embedding. To support serialization, the interpreter stacks must not only NOT be intertwined with the C stack - the "stackless" property of Stackless Python, and, I presume Lua 5.0 - but also must not contain any live pointers to real memory - or provide a mechanism for serializing the state of each execution thread. regards, Assen |
|
From: Thatcher U. <tu...@tu...> - 2003-04-24 02:13:15
|
On Apr 23, 2003 at 12:05 +0300, Ivan-Assen Ivanov wrote: > > To support serialization, the interpreter stacks must not only > NOT be intertwined with the C stack - the "stackless" property of > Stackless Python, and, I presume Lua 5.0 - but also must not contain > any live pointers to real memory - or provide a mechanism for > serializing the state of each execution thread. In general, the Lua stack will be chock full of pointers to live objects, as will the Lua objects on the heap. So as Tom says, you serialize this just like you serialize anything else -- traverse the live objects, keep track of object ID's, fix up pointers, etc. -- Thatcher Ulrich http://tulrich.com |
|
From: Enno R. <en...@de...> - 2003-04-28 12:36:42
|
Thatcher Ulrich wrote: > On Apr 23, 2003 at 12:05 +0300, Ivan-Assen Ivanov wrote: > > In general, the Lua stack will be chock full of pointers to live > objects, as will the Lua objects on the heap. So as Tom says, you > serialize this just like you serialize anything else -- traverse the > live objects, keep track of object ID's, fix up pointers, etc. I've just started looking at lua and whether that would be a good replacement for our own scripting. I started by looking at coroutines and a simple scheduler and ran across the same issue of serializing the state for savegames. Are there any good examples on how to traverse the lua stack and find my C pointers to do the serialization? I'd be thankful for a few pointers :-) Enno. |
|
From: Thatcher U. <tu...@tu...> - 2003-04-28 15:10:01
|
On Apr 28, 2003 at 02:35 +0200, Enno Rehling wrote: > Thatcher Ulrich wrote: > > >On Apr 23, 2003 at 12:05 +0300, Ivan-Assen Ivanov wrote: > > > > >In general, the Lua stack will be chock full of pointers to live > >objects, as will the Lua objects on the heap. So as Tom says, you > >serialize this just like you serialize anything else -- traverse the > >live objects, keep track of object ID's, fix up pointers, etc. > > I've just started looking at lua and whether that would be a good > replacement for our own scripting. I started by looking at coroutines and a > simple scheduler and ran across the same issue of serializing the state for > savegames. Are there any good examples on how to traverse the lua stack and > find my C pointers to do the serialization? I'd be thankful for a few > pointers :-) That in particular should be pretty straightforward; just iterate over the stack elements (using the Lua API) and look for entries which are userdata. But, besides your own data, there are various parts of the VM that need to be serialized as well, not to mention Lua's heap objects, which may also reference your objects. The Lua garbage-collector code (src/lgc.c) is very similar to what you need for serialization. I think the lua-l mailing list would be a better place to ask, though. -- Thatcher Ulrich http://tulrich.com |
|
From: brian s. <pud...@po...> - 2003-04-17 18:09:00
|
JavaScript: x-platform if you grab the Mozilla implementation; not sure what the footprint would be on a console, and of course you have the garbage collection issue. Language is very nice though and of course there's plenty of reference material out there. Tcl: Not my cup of tea but may be someone else's? Simkin: Language features are nice, but I don't want to write script in XML. And the other file format looks even less clear, if that's possible: look at http://www.simkin.co.uk/Docs/Simkin/Example.s.txt. What goes in the brackets? Well, brackets seem to group method arguments with the method body. Except when they're used to block out comments. But comments can also follow double slashes. Hmmmm. Well, I'm sure I can count on my designers to sort it all out...I mean, they already *almost* understand what a source control system does, so this should be cake. Python: if it proves to be viable on consoles (I'm watching others and hoping for the best) I would be very happy. I haven't seen other languages with anything close to Boost.Python for ease-of-integration; it is seriously impressive: http://www.boost.org/libs/python/doc/. Other positives are same as JavaScript: lots of reference material, very readable, etc. --brian Gareth Lewin wrote: >>-----Original Message----- >>From: Marc Fascia [mailto:ma...@ma...] >>It seems that Python, Lua and Ruby are >>popular choices in that topic. >> >> > >Other good choises are tcl, and javascript/vbscript if this is a win32 only >product. >_______________________ >Regards, Gareth Lewin >Programmer, Climax Solent. > > |
|
From: gekido <ge...@ub...> - 2003-04-17 21:22:43
|
> Simkin: Language features are nice, but I don't want to write script in > XML. And the other file format looks even less clear, if that's > possible: look at http://www.simkin.co.uk/Docs/Simkin/Example.s.txt. > What goes in the brackets? Well, brackets seem to group method > arguments with the method body. Except when they're used to block out > comments. But comments can also follow double slashes. Hmmmm. Well, > I'm sure I can count on my designers to sort it all out...I mean, they > already *almost* understand what a source control system does, so this > should be cake. the syntax IS a bit wierd, but here's a few samples from the Reality Factory implementation - it's definitely not XML ;} http://rfactory.uber-geek.ca/docs/Con_Scripting.htm http://rfactory.uber-geek.ca/docs/PawnScript.htm we have implemented High and Low level scripts, which give the designers the freedom to have 'instant one-frame' script actions (low-level) or longer-actions that may take more than a single frame to process (high-level ai stuff for example)... i can put you in touch with the lead programmer if you wish to discuss the implementation of simkin in more details... We use scripts for a wide range of things - here's the simplest type to initialize a Terrain and skydome for rendering... not THAT incomprehensible...the 'Start' command initializes everything on level load, the Run command allows you to have sun locations that change, moving clouds, wind changing directions etc in realtime... works very well and doesn't require any kind of recompiling or programmers to modify - the designers can go nuts all they want. { Start[ () { SetTerrain("flat.bmp", "desert256.bmp"); SetSkyDome(400, 64); SetSkyTexture("clouds_256.bmp"); SetSkyColor(164, 200, 255, 255); SetTimeScale(700); DisableSun(false); DisableCloud(false); UseSkyFog(false); } ] Run[ () { SetWindDirection("north"); } ] } cheers mike w www.uber-geek.ca |
|
From: <Lag...@wa...> - 2003-04-17 22:29:55
|
> Python: if it proves to be viable on consoles (I'm watching others and > hoping for the best) I would be very happy. I haven't seen other > languages with anything close to Boost.Python for ease-of-integration; > it is seriously impressive: http://www.boost.org/libs/python/doc/. luabind (http://luabind.sf.net/) for lua (www.lua.org) allow the same ease-of-integration It is based on the same work. IMHO for a scripting language you need to be aware of porting the VM on every platform. Lua is write in clear ANSI C++ and is light. Port on PS2, GC, XBOX is very easy. ------------------------ Lagarde Sébastien Neko entertainment Junior programmer |
|
From: Brian H. <ho...@py...> - 2003-04-17 22:59:40
|
>on every platform. Lua is write in clear ANSI C++ and is light.= Port Small correction -- Lua is written in clear ANSI C, and it= compiles cleanly with a C++ compiler as well. It's also been used by many= commercial games and it's incredibly lightweight. Its syntax= isn't too bad either. Lua's biggest "problem" is that it lacks a comprehensive set of "blessed" external libraries, something Python is very good with,= however if you just need a scripting language, it's great. Another, less popular, alternative is Small, which has nice clean= documentation, a familiar syntax and seems to be reasonably= popular as well. -Hook |
|
From: <Lag...@wa...> - 2003-04-17 23:05:09
|
>>on every platform. Lua is write in clear ANSI C++ and is light. Port >Small correction -- Lua is written in clear ANSI C, and it compiles oops thank to correct me ---------------------- Lagarde Sébastien Neko entertainment Junior programmer |
|
From: brian s. <pud...@po...> - 2003-04-17 23:01:39
|
Sweet, I hadn't seen that before. The only alternative I knew of was toLua. Unfortunately Lua on consoles doesn't seem viable because of the GC. We're using it as a configuration language, but we're not trying to execute scripts at runtime because we can't maintain 60 fps if the GC goes off and thinks about things for a few milliseconds. Hence the search for alternatives. Python is pretty portable in its own right; you can find the needed patches by googling "python ps2" or "python gamecube". And the amount of time you'll spend porting is much less than the time you'll spend supporting your end users, so I'd argue that it's a factor in the decision, but not *the* factor. But all this discussion is irrelevant. I've found the ultimate scripting language: http://www.muppetlabs.com/~breadbox/bf/. No garbage collector, dead-simple VM, and even smaller footprint than Lua! :) --brian Lagarde Sébastien wrote: >>Python: if it proves to be viable on consoles (I'm watching others and >>hoping for the best) I would be very happy. I haven't seen other >>languages with anything close to Boost.Python for ease-of-integration; >>it is seriously impressive: http://www.boost.org/libs/python/doc/. >> >> > >luabind (http://luabind.sf.net/) for lua (www.lua.org) allow the same >ease-of-integration >It is based on the same work. > >IMHO for a scripting language you need to be aware of porting the VM on >every platform. >Lua is write in clear ANSI C++ and is light. Port on PS2, GC, XBOX is very >easy. >------------------------ >Lagarde Sébastien >Neko entertainment >Junior programmer > > |
|
From: Brian H. <ho...@py...> - 2003-04-17 23:32:54
|
>Unfortunately Lua on consoles doesn't seem viable because of the= GC. It's viable, just a pain in the ass. Someone else posted that= the only way to really use it in that environment is to preload everything and avoid all allocations and frees during a mission/level, then clean everything out between levels. Python suffers from a similar problem even with refcounting, e.g.= release cascades. I would imagine patching Lua to avoid any GC at all would be relatively easy and might even be a good compromise. Now, for something with an extended life you're going to have to= find a decent real-time GC implementation. Brian |
|
From: <cas...@ya...> - 2003-04-18 19:59:05
|
Brian Hook wrote: > Now, for something with an extended life you're going to have to find > a decent real-time GC implementation. Lua 5.1 will have an incremental garbage collector, that will probably solve most, if not all, of those problems. Ignacio Castaño cas...@ya... |
|
From: Colin F. <cp...@ea...> - 2003-04-21 05:28:08
|
2003 April 20th Sunday Clear your schedule, because you are one click away from your new addiction: Neural Networks! http://www.colinfahey.com/2003apr20_neuron/2003apr20_neuron.htm This article describes the fundamentals of neural networks, such as simulation and back-propagation, and features interesting training scenarios, such as Exclusive-OR (XOR) and Tic-Tac-Toe. Download the complete C++ source code and start performing your own experiments immediately. The source code is public domain, and can be used for any purpose without consideration. There are many books and articles written about neural networks, but I offer my own article in the hope that it will stimulate new thinking and experimentation, and will make the subject more accessible to novices. --- Colin cp...@ea... http://www.colinfahey.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X