 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Scripting in C using Co-Routines |
|
 |
DrNecessiter Member since: 7/27/2003 |
|||
 Posted - 8/5/2003 12:41:15 PM |
||||
| Excellent. You've described almost preciesly the way I hook Lua into our game. Essentially, each Lua script that is managed by the script manager has several wait-states that it can be in. waiting for a specifc timestamp to arrive waiting for a specific delay to pass waiting for variable = value waiting for variable != value waiting for variable > value waiting for variable < value These "wait" functions essentially execute a lua_yield and inform the script manager of the type of wait they are in. The script manager then tests the wait condition and reactivates the script when needed. A small pool of shared variables are accessable to both Lua and the game. These are the variables that can be used in the wait functions like this: Script.WaitVarGt(1, 4) -- wait until variable[1] is greater than 4 Perhaps variable[1] is the player's score, or the number of enemies he has killed. The script will wait for this event and continue when it has occurred. |
||||
|
||||
|
Estese Member since: 8/22/1999 From: Morinville, Canada, Canada |
|||
|
Posted - 8/5/2003 2:23:10 PM |
||||
| Very interesting and insightful article. I have been researching Lua for integration into my RPG, but after reading this, I'm considering adopting it instead. Lower overhead, less development time, and easier debugging than a scripting language, I think this is a very elegant solution to the coroutine problem. Keep up the good work! |
||||
|
||||
|
Ravyne Member since: 2/26/2007 From: Kirkland, WA, United States |
|||
|
Posted - 8/5/2003 6:54:03 PM |
||||
| Indeed interesting... I don't know that I'd call it "scripting" though... It achieves the same ends but scripting generally is associated with other things... I'm all for having more options though, especially when performance is a concern, and the co-routine info is good, so nice work on the article. Ravyne, NYN Interactive Entertainment [My Site][My School][My Group] |
||||
|
||||
|
nonnus29 Member since: 3/2/2002 From: USA |
|||
|
Posted - 8/5/2003 7:47:19 PM |
||||
| So if I create a global List of Objects that represent my particle effects in the main program then jump to a 'script' can the script still access the List created by another part of the program/engine? EDIT; The entire passing of parameters to and from the 'script' has got me entirely confused. Would you put a reference to the List on the stack and let the script pop; essentially the same way Lua passers parameters to and from a C/C++ pgm? [edited by - nonnus29 on August 5, 2003 9:49:28 PM] |
||||
|
||||
|
Grul Member since: 3/6/2001 From: Linköping, Sweden |
|||
|
Posted - 8/5/2003 9:19:32 PM |
||||
| This should mean that the scripts gets linked into the actual executable, so why not? on the other hand, in c++ this would need a declaration of this vector first. In C it should work, though. [edited by - Grul on August 5, 2003 9:20:26 PM] |
||||
|
||||
|
billy_zelsnack Member since: 8/5/2003 From: Madison, WI, United States |
|||
|
Posted - 8/5/2003 9:59:36 PM |
||||
Very cool idea and article. I am going to try this. -billy |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 8/5/2003 10:11:54 PM |
||||
| nonnus29: No you don't need to do anything special, you can just use a global or singleton and access it directly. It would be a good idea to define some sort of interface, but just treat it like any other C/C++ file. Grul: You don't need to directly link in your scripts. You can load in the code as a DLL, or use a small C compiler to compile it on the fly. Thomas |
||||
|
||||
|
Davaris Member since: 6/5/2000 From: Australia |
|||
|
Posted - 8/8/2003 4:06:10 PM |
||||
There is something about your method for scripting that concerns me. If you wanted someone else to do the scripting for your game wouldn't they need access to your source code? |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 8/8/2003 6:37:52 PM |
||||
| You wouldn't need to give them access to your source code. You would need to expose a set of c interfaces via a library interface, or export table. They would compile their code in to a DLL that you would dynamicly load. The proccess would parallel more traditional scripting interfaces since you would then have to spend more time defining and managing interfaces. Thomas |
||||
|
||||
|
targhan Member since: 10/17/2001 From: Sweden |
|||
|
Posted - 8/11/2003 11:25:35 AM |
||||
| Very nice article... ...if you're an extreme hacker that loves to make everyone around you crazy. I have never ever actually even considered using co-routines in anything but my most haxx0rish pieces of code. |
||||
|
||||
|
jwthomp Member since: 3/6/2002 From: Champaign, IL, United States |
|||
|
Posted - 8/12/2003 10:22:34 AM |
||||
| targhan, This has nothing to do with trying to make people "crazy" around you. Using c/c++ as your scripting language has been used in mainstream games and will almost certainly continue to do so. In fact, there are several advantages to doing so. The most obvious is of course speed, which opens up a whole new class of behaviors that you can script. For example, intensive mathematical calculations and internal game logic that would be handled too slowly can now move into scripts. This allows your core engine to be a little more generalized. It also allows you to change these behaviors more easily by simply recompiling the "script". Common objections: 1) You have to have the source code of the project. As mentioned earlier in this thread, you do not. All you have to know is how the game engine loads and talks to a scripting object. If you meet that interface then your script will work with the engine. 2) You have to compile the scripts. If you are using a scripting language and want to achieve anything beyond absolutely horrible performance, then you will be compiling those scripts as well. So using a language such as Python over c/c++ doesn't really gain you anything. 3) You can't crash a "real" scripting language. While many scripting languages allow you to catch errors and prevent corruption of the rest of your application, they are still "crashing", and require you to stop your application (since the script does affect game state you now have an unstable game). This is no great advantage over c/c++, which you can do error detection in anyway. c/c++ also have more mature debugging tools as well. 4) c/c++ are harder to learn than python/lua/my favorite scripting language. Frankly, this is debatable. The complexity of the scripting interface will probably have more to do with the imposed complexity than anything else. You can probably ease the burden by using a function based interface (c), rather than an object based interface as it requires a little less rigourous understanding of what is happening. Also, as most non-programmers will be tweaking your scripts rather than writing them, this becomes even less of a problem. Just some thoughts. Jeff Edit: I was late for work when I wrote this, and forgot the negatives.  Drawbacks: 1) Not platform independent. You have to compile scripts for each platform. Not a disadvantage if you are single platform. 2) Lack of interface code between other scripts, engine, and your script. The issue here is simply, how to export functions, and objects from your engine, and in fact other scripts, to the script that you are loading. If you are using c++, then this is a little tricky due to it's strongly typed nature. I'm going have to do some thinking on this. Does anyone else have any thoughts? [edited by - jwthomp on August 12, 2003 11:16:15 AM] |
||||
|
||||
|
rm3 Member since: 8/11/2002 |
|||
|
Posted - 8/14/2003 12:19:51 AM |
||||
| Hello. I have read the article. It is interesting. It has enlightened me as to how little I truly understand about scripting languages. My basic question is: What are the primary advantages of coroutines? Speed? C code? I guess I don't completely understand them, yet. Scripts would be compiled C code that is dynamically run? Or... ??? When I had to do scripting, I made a crappy psuedo C script language called FF-C. It took a lot of time writing the script handlers - I was basically rewriting compiled C into a slower, simpler, interpreted language. But the scripts were so small (less than a page in notepad) that it didn't really matter. Could coroutines have saved me time and money!?!? (okay, I didn't spend any money, except on soda). Thanks for the article! Information rocks! |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 8/14/2003 7:54:10 PM |
||||
| Using co-routines or threads is a very convient way of working with scripts. As the article suggest, they are crucial to having functional scripts do complex tasks. The scripts can be compiled from C in to machine language on the fly, staticly in to the app or dynamicly loaded. Whatever works best for your particular situation. Thomas |
||||
|
||||
|
duke Member since: 7/27/2002 From: USA |
|||
Posted - 8/15/2003 10:51:19 PM |
||||
| Wow, did I read the same article you guys did? Firstly, I must strongly disagree with how liberally you apply the term script. I would not consider C++/C as a scripting language but I suppose this is a moot point to some degree. Secondly, you never even once mentioned fibers at all... I mean all you are really doing is making a fiber more or less... Also, there is an article is one of the game gems that describes a similiar, if not the exact same technique, and it is better. And I guess I just can't get over the C/C++ as a script language part.... but I mean come on? That is ridiculous. I am not saying your technique is ridiculous, but calling that scripting is just out right misleading. And most of all, the technique you describe strikes me as being extremely error prone and difficult to debug not to mention quite severely limiting.... Now if I want to butter you up with some complements, I will say that the information you presented, although I disagree with it in part, is quite well organized and very easy to follow and that aspect of the article deserves an A+. Jeff |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 8/16/2003 7:17:10 PM |
||||
| Hello, could you explain what a fiber is or maybe a link to some information on it, please? Peter |
||||
|
||||
|
duke Member since: 7/27/2002 From: USA |
|||
Posted - 8/17/2003 10:06:16 AM |
||||
| There is info on msdn about fibers. I don't know offhand if fibers are purely a microsoft construct or if other OS's support the same concept. Look in the platform SDK docs about thread/process functions. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 8/17/2003 5:38:29 PM |
||||
| I found this page http://msdn.microsoft.com/msdnmag/issues/03/09/CoroutinesinNET/default.aspx if anyone else wants to look up fibers. It seems a fiber is a thread(with less overhead) that is controlled by the program rather then by the OS. Is that right? Peter |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 8/17/2003 11:02:08 PM |
||||
| Duke: A game script is simply data driven game logic. The key is that you're using some sort of language to define that data which contains some sort of game logic. Whether you use some home grown C like language, PERL, Java or LUA, or straight C++ doesn't matter. ie. VB and VB script. There's really no difference between C/C++ and what most people would call a scripting language. A programming language is a programming language. The line's get even more blurry when you take in to account the .net stuff, with every thing compiling to the same type of thing. -- Having debugging a lot of custom scripting and 3rd party scripting in my time. Using C++ is way eaiser to debug. What else has anything even close to the wealth of GUI and remote debugging tools that C++ has? And i don't see how C limits you. Perhaps you could explain further some of the draw backs that weren't mentioned the in article? Fibres are a recent implementation of co-routines in windows, but even that is a more heavy and it's a non cross-platform solution. Worth mentioning, to be sure. Thomas |
||||
|
||||
|
duke Member since: 7/27/2002 From: USA |
|||
Posted - 8/18/2003 4:52:59 PM |
||||
| Thomas: I must admit, I am begining to have second thoughts on my strong comments against calling using C/C++ for scripting... The article has made me consider something that just never really crossed my mind (not the co-routine part but your method of scripting in C)... I just got to a point in my project where I was starting to integrate lua into my engine but I think I will take a day or two and experiment with creating a limited C api and letting my guys write the scripts in C and use them as a DLL. As for the other problems with the co-routine stuff, I guess my thought is it just struck me as something that was inherently error prone due to some of the issues with creating C++ objects on the stack and what not... anyways I'm going to approach what the article discusses with a more open and mind and see where it takes me. Thanks |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 8/20/2003 1:58:12 PM |
||||
Here is the asm in AT&T format for anyone using a gcc based compiler.
//#define TG_SAVE_STACK(var) __asm {mov var, ESP}
#define TG_SAVE_STACK(var) __asm__\
(\
"mov %%ESP, %0\n"\
: "=g" (var) \
) // Copy to the stack pointer to local variable
//#define TG_RESTORE_STACK __asm {sub ESP, stack}
#define TG_RESTORE_STACK __asm__\
(\
"sub %%ESP, %0\n"\
: "=g" (stack)\
: "g" (stack)\
) // Restore the stack with our own variable
Peter |
||||
|
||||
|
deks Member since: 5/9/2000 From: Montreal, Canada |
|||
|
Posted - 2/19/2004 9:57:09 AM |
||||
| Anyone have a PowerPC version working? |
||||
|
||||
|
Toes Member since: 12/19/2000 |
|||
|
Posted - 1/28/2005 3:29:10 AM |
||||
| I finally linked to this article back to my Blog Links to the left lead to my other programming projects including some updated scripting library for use with LUA. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
