Re: [Warzone-dev] Linux crashdumps
Am Donnerstag, 22. Februar 2007 schrieb Dennis Schridde: > Am Mittwoch, 21. Februar 2007 schrieb Dennis Schridde: > > Am Mittwoch, 21. Februar 2007 schrieb Dennis Schridde: > > > Am Mittwoch, 21. Februar 2007 schrieb Per Inge Mathisen: > > > > On 2/21/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > > > > For those interested in signal handling and backtrace creation, > > > > > this sample might be usefull. > > > > > > > > Dump caused by signal: SIGSEGV, Segmentation fault > > > > > > > > Backtrace: > > > >0x8048513 > > > > 0x315420 > > > >0x8048995 > > > > 0x4b8ae4e4 > > > >0x8048451 > > > > > > > > At lines: > > > > /home/devel/warzone/gdmp.c:27 > > > > ??:0 > > > > /home/devel/warzone/gdmp.c:90 > > > > ??:0 > > > > ??:0 > > > > > > > > Did not seem to work very well here. I compiled with -g -O0. > > > > > > Oh, it does... > > > What you see are not the places where the signal was generated. > > > You see the return addresses. > > > > > > The 1st line is probably allways useless. It shows the location where > > > the backtrace was generated. The 2nd line is probably allways not in > > > the signaled binary, I think it belongs to the signal handler in glibc. > > > The 3rd line is the interesting one, it shows the location after the > > > function where the signal was generated. > > > > > > In this case the signal is generated in except(), so it points to the > > > next instruction after returning from except(). > > > I agree that this might not be too usefull, especially for bigger > > > functions. > > > > > > The only other way would be to compile with -rdynamic and use push the > > > return addresses through backtrace_symbols() before storing them... > > > But that would not give you any significant additional information, you > > > still have only the return addresses. The only gain is that you also > > > get to know the functions of the library instead of just your own > > > binary. This might be a little bit helpful in cases where it crashes > > > not directly in your binary, but eg. in a call to strcpy or similar. > > > I wasn't able to find out how to create "real" backtraces or even how > > > to dump the callstack. It currently seems to me that the glibc doesn't > > > offer such functionality. Maybe GCC does offer something, since the > > > calling convention is probably defined by GCC and not the LibC... > > > > > > --Dennis > > > > Found a doc with a tiny little bit of more information: > > http://www.linuxjournal.com/article/6391 > > More potentialy usefull information: > http://alephnull.com/ > http://savannah.nongnu.org/projects/libunwind If I didn't do anything wrong libunwind doesn't offer anything additional than the GLibC integrated backtrace() (at least nothing of use for us). Additional to that it also crashes after examination of the signal handler function (it works well if not called from the signal handler)... --Dennis pgp2NmUkCptbQ.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Linux crashdumps
Am Mittwoch, 21. Februar 2007 schrieb Dennis Schridde: > Am Mittwoch, 21. Februar 2007 schrieb Dennis Schridde: > > Am Mittwoch, 21. Februar 2007 schrieb Per Inge Mathisen: > > > On 2/21/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > > > For those interested in signal handling and backtrace creation, this > > > > sample might be usefull. > > > > > > Dump caused by signal: SIGSEGV, Segmentation fault > > > > > > Backtrace: > > >0x8048513 > > > 0x315420 > > >0x8048995 > > > 0x4b8ae4e4 > > >0x8048451 > > > > > > At lines: > > > /home/devel/warzone/gdmp.c:27 > > > ??:0 > > > /home/devel/warzone/gdmp.c:90 > > > ??:0 > > > ??:0 > > > > > > Did not seem to work very well here. I compiled with -g -O0. > > > > Oh, it does... > > What you see are not the places where the signal was generated. > > You see the return addresses. > > > > The 1st line is probably allways useless. It shows the location where the > > backtrace was generated. The 2nd line is probably allways not in the > > signaled binary, I think it belongs to the signal handler in glibc. The > > 3rd line is the interesting one, it shows the location after the function > > where the signal was generated. > > > > In this case the signal is generated in except(), so it points to the > > next instruction after returning from except(). > > I agree that this might not be too usefull, especially for bigger > > functions. > > > > The only other way would be to compile with -rdynamic and use push the > > return addresses through backtrace_symbols() before storing them... > > But that would not give you any significant additional information, you > > still have only the return addresses. The only gain is that you also get > > to know the functions of the library instead of just your own binary. > > This might be a little bit helpful in cases where it crashes not directly > > in your binary, but eg. in a call to strcpy or similar. > > I wasn't able to find out how to create "real" backtraces or even how to > > dump the callstack. It currently seems to me that the glibc doesn't offer > > such functionality. Maybe GCC does offer something, since the calling > > convention is probably defined by GCC and not the LibC... > > > > --Dennis > > Found a doc with a tiny little bit of more information: > http://www.linuxjournal.com/article/6391 More potentialy usefull information: http://alephnull.com/ http://savannah.nongnu.org/projects/libunwind pgpZyqPscXKeq.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Linux crashdumps
Am Mittwoch, 21. Februar 2007 schrieb Dennis Schridde: > Am Mittwoch, 21. Februar 2007 schrieb Per Inge Mathisen: > > On 2/21/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > > For those interested in signal handling and backtrace creation, this > > > sample might be usefull. > > > > Dump caused by signal: SIGSEGV, Segmentation fault > > > > Backtrace: > >0x8048513 > > 0x315420 > >0x8048995 > > 0x4b8ae4e4 > >0x8048451 > > > > At lines: > > /home/devel/warzone/gdmp.c:27 > > ??:0 > > /home/devel/warzone/gdmp.c:90 > > ??:0 > > ??:0 > > > > Did not seem to work very well here. I compiled with -g -O0. > > Oh, it does... > What you see are not the places where the signal was generated. > You see the return addresses. > > The 1st line is probably allways useless. It shows the location where the > backtrace was generated. The 2nd line is probably allways not in the > signaled binary, I think it belongs to the signal handler in glibc. The 3rd > line is the interesting one, it shows the location after the function where > the signal was generated. > > In this case the signal is generated in except(), so it points to the next > instruction after returning from except(). > I agree that this might not be too usefull, especially for bigger > functions. > > The only other way would be to compile with -rdynamic and use push the > return addresses through backtrace_symbols() before storing them... > But that would not give you any significant additional information, you > still have only the return addresses. The only gain is that you also get to > know the functions of the library instead of just your own binary. This > might be a little bit helpful in cases where it crashes not directly in > your binary, but eg. in a call to strcpy or similar. > I wasn't able to find out how to create "real" backtraces or even how to > dump the callstack. It currently seems to me that the glibc doesn't offer > such functionality. Maybe GCC does offer something, since the calling > convention is probably defined by GCC and not the LibC... > > --Dennis Found a doc with a tiny little bit of more information: http://www.linuxjournal.com/article/6391 pgpUJ26CbReIN.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Linux crashdumps
Am Mittwoch, 21. Februar 2007 schrieb Per Inge Mathisen: > On 2/21/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > For those interested in signal handling and backtrace creation, this > > sample might be usefull. > > Dump caused by signal: SIGSEGV, Segmentation fault > > Backtrace: >0x8048513 > 0x315420 >0x8048995 > 0x4b8ae4e4 >0x8048451 > > At lines: > /home/devel/warzone/gdmp.c:27 > ??:0 > /home/devel/warzone/gdmp.c:90 > ??:0 > ??:0 > > Did not seem to work very well here. I compiled with -g -O0. Oh, it does... What you see are not the places where the signal was generated. You see the return addresses. The 1st line is probably allways useless. It shows the location where the backtrace was generated. The 2nd line is probably allways not in the signaled binary, I think it belongs to the signal handler in glibc. The 3rd line is the interesting one, it shows the location after the function where the signal was generated. In this case the signal is generated in except(), so it points to the next instruction after returning from except(). I agree that this might not be too usefull, especially for bigger functions. The only other way would be to compile with -rdynamic and use push the return addresses through backtrace_symbols() before storing them... But that would not give you any significant additional information, you still have only the return addresses. The only gain is that you also get to know the functions of the library instead of just your own binary. This might be a little bit helpful in cases where it crashes not directly in your binary, but eg. in a call to strcpy or similar. I wasn't able to find out how to create "real" backtraces or even how to dump the callstack. It currently seems to me that the glibc doesn't offer such functionality. Maybe GCC does offer something, since the calling convention is probably defined by GCC and not the LibC... --Dennis pgpeRGva5au2S.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdebbuger profiling result with vertex arrays
Am Mittwoch, 21. Februar 2007 schrieb Per Inge Mathisen: > On 2/21/07, The Watermelon <[EMAIL PROTECTED]> wrote: > > 4.frequent texture binds > > ... > > > Any hints/ideas/comments? :) > > This would seem the easiest to improve. We can cram much more textures > into our texture atlases by making them larger. Then we need to switch > between them less often. They are currently fixed at 512x512. > Unfortunately, just increasing the > > #define PAGE_WIDTH 512 > #define PAGE_HEIGHT 512 > > defines in src/textures.c won't do ;-). I suspect this value is > hard-coded or assumed in several places in the code. It is. Especially the terrain renderer needs to be adjusted, since it assumes a specific number of tiles to be in a texture page. --Dennis pgpY81YgzGXny.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch: removal of duplicate code
Per Inge Mathisen wrote: On 2/17/07, Gerard Krol <[EMAIL PROTECTED]> wrote: I went duplicate code hunting, and fixed these occurrences of copy&paste. There are quite some more, but I leave those for another time. I have been working on this, and committed parts of it, but it is a real pain to check it for correctness. Yeah, it is. Struggled with that myself too. I see that the two functions merged in src/display3d.c have differences, though, where one function used buildingBrightness and another brightness, which are calculated differently, while in the merged function, buildingBrightness only is used. Calculated differently? I just took another look at the code, and this does not seem to be the case. The value buildingBrightness is just abandoned at some point, and brightness is used. It would be nice to know if such changes are intentional or not. In principle the code should behave exactly as before. The only change I remember is that some value that has something to do with the muzzle flash that was different for the normal buildings and the defensive buildings. I supposed the value on the defensive buildings was updated at some time, and the value for the normal buildings was forgotten, so I made both normal and defensive buildings use the muzzle flash parameter from the defensive buildings. - Gerard ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch: removal of duplicate code
On 2/17/07, Gerard Krol <[EMAIL PROTECTED]> wrote: I went duplicate code hunting, and fixed these occurrences of copy&paste. There are quite some more, but I leave those for another time. I have been working on this, and committed parts of it, but it is a real pain to check it for correctness. I see that the two functions merged in src/display3d.c have differences, though, where one function used buildingBrightness and another brightness, which are calculated differently, while in the merged function, buildingBrightness only is used. It would be nice to know if such changes are intentional or not. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdebbuger profiling result with vertex arrays
On 2/21/07, The Watermelon <[EMAIL PROTECTED]> wrote: 4.frequent texture binds ... Any hints/ideas/comments? :) This would seem the easiest to improve. We can cram much more textures into our texture atlases by making them larger. Then we need to switch between them less often. They are currently fixed at 512x512. Unfortunately, just increasing the #define PAGE_WIDTH 512 #define PAGE_HEIGHT 512 defines in src/textures.c won't do ;-). I suspect this value is hard-coded or assumed in several places in the code. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Re: [Warzone-commits] r792 - in /trunk: lib/sound/track.c lib/sound/track.h src/data.c
Giel van Schijndel wrote:
Author: muggenhor
Date: Mon Feb 19 22:52:27 2007
New Revision: 792
URL: http://svn.gna.org/viewcvs/warzone?rev=792&view=rev
Log:
* removed some redundant code from src/data.c:
- the function dataAudioLoad first checked whether the audio system is
disabled and if it is sets return buffer (*ppData) to NULL, even though this
functionality is already performed by the function it calls
(audio_LoadTrackFromBuffer)
Well, you made a little mistake there. The function is supposed to
return FALSE ONLY when an error occurs. Returning FALSE causes for me:
error: resLoad: failed to parse wrf/frontend.wrf
error: Shutting down after failure
And you also made it return FALSE when sound is disabled. The attached
patch corrects this, and also removes the redundant function
audio_LoadTrackFromBuffer which was only a very thin wrapper for
sound_LoadTrackFromBuffer. The check if sound is enabled is again in
dataAudioLoad.
- Gerard
Index: src/data.c
===
--- src/data.c (revision 792)
+++ src/data.c (working copy)
@@ -989,13 +989,16 @@
/* Load an audio file */
BOOL dataAudioLoad(char *pBuffer, UDWORD size, void **ppData)
{
- // If audio is disabled or a track can't be constructed the return value will be NULL
- *ppData = audio_LoadTrackFromBuffer( pBuffer, size );
+ if ( audio_Disabled() == TRUE )
+ {
+ *ppData = NULL;
+ // No error occurred (sound is just disabled), so we return TRUE
+ return TRUE;
+ }
+// Load the track from a file
+ *ppData = sound_LoadTrackFromBuffer( pBuffer, size );
- if (*ppData == NULL)
- return FALSE;
-
- return TRUE;
+ return *ppData != NULL;
}
void dataAudioRelease( void *pData )
Index: lib/sound/audio.c
===
--- lib/sound/audio.c (revision 792)
+++ lib/sound/audio.c (working copy)
@@ -614,23 +614,8 @@
}
//*
-// ===
-// ===
//
-TRACK *audio_LoadTrackFromBuffer(char *pBuffer, UDWORD udwSize)
-{
- // if audio not enabled return TRUE to carry on game without audio
- if ( g_bAudioEnabled == FALSE )
- {
- return NULL;
- }
- return sound_LoadTrackFromBuffer( pBuffer, udwSize );
-}
-
-//*
-//
-
// Routine to convert wav filename into a track number
// ... This is really not going to be practical on the PSX is it?
//
Index: lib/sound/audio.h
===
--- lib/sound/audio.h (revision 792)
+++ lib/sound/audio.h (working copy)
@@ -36,7 +36,6 @@
extern BOOL audio_Disabled( void );
extern BOOL audio_LoadTrackFromFile( char szFileName[] );
-extern TRACK * audio_LoadTrackFromBuffer(char *pBuffer, UDWORD udwSize);
extern BOOL audio_SetTrackVals( char szFileName[], BOOL bLoop, int *piID,
int iVol, int iPriority, int iAudibleRadius );
extern BOOL audio_SetTrackValsHashName( UDWORD hash, BOOL bLoop, int iTrack, int iVol,
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] gdebbuger profiling result with vertex arrays
I am unable to make a comparison with old immediate mode,because I think devurandom's old gdebugger test with immediate mode didnt have a % and number of calls per frame info attached... just to list major hoggers:(scene:default view position in map rush with 'advanced base') without shadows: glDrawArrays - GL_TRIANGLE_FAN 18.73% 3012 times glInterleavedArrays 18.73% 3012 times glPopMatrix 14.06% 2261 times glPushMatrix 14.06% 2261 times glAlphaFunc 5.97% 960 times glDisable - GL_ALPHA_TEST 5.97% 960 times glEnable - GL_ALPHA_TEST 5.97% 960 times glBindTexture - GL_TEXTURE_2D 3.72% 599 times glEnable - GL_TEXTURE_2D 3.72% 599 times glTranslatef 2.08% 355 times with shadows: glDrawArrays - GL_TRIANGLE_FAN 19.07% 4000 times glInterleavedArrays 14.36% 3012 times glPopMatrix 10.78% 2261 times glPushMatrix 10.78% 2261 times glVertexPointer 9.42% 1976 times glAlphaFunc 4.77% 1000 times glDisable - GL_ALPHA_TEST 4.77% 1000 times glEnable - GL_ALPHA_TEST 4.77% 1000 times glDrawArrays - GL_TRIANGLE_STRIP 4.71% 988 times glBindTexture - GL_TEXTURE_2D 2.86% 599 times glEnable - GL_TEXTURE_2D 2.86% 599 times glVertex2f 1.70% 335 times glTexCoord2f 1.60% 210 times glTranslatef 1.60% 355 times glRotatef 1.00% 210 times seems the major problems are: 1.too many glPop and glPushMatrix 2.overused alphaFunc state change 3.inefficient drawing measures(apparently drawArrays and interleavedarrays got called per polygon,prolly it was even worse with immediate mode(drawArrays + interleavedarrays = glBegin() + glEnd() + glColor4ub() + glTexCoord2f + glVertex3f * numVerts ) ) 4.frequent texture binds 5.some fillrate problems related to textures Any hints/ideas/comments? :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Linux crashdumps
On 2/21/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: For those interested in signal handling and backtrace creation, this sample might be usefull. Dump caused by signal: SIGSEGV, Segmentation fault Backtrace: 0x8048513 0x315420 0x8048995 0x4b8ae4e4 0x8048451 At lines: /home/devel/warzone/gdmp.c:27 ??:0 /home/devel/warzone/gdmp.c:90 ??:0 ??:0 Did not seem to work very well here. I compiled with -g -O0. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Linux crashdumps
Wrote a crashdumper for Linux which I will integrate alongside the minidumper for Windows. For those interested in signal handling and backtrace creation, this sample might be usefull. Package contains of an app which dumps the crash informations into mdump.gdmp and another app which retrieves it from there. Make sure you compile gdmp.c with debugging enabled, otherwise addr2line will have a hard job getting usefull information... --Dennis gdmp.7z Description: application/7z pgp2FPZTuYrSx.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Evaluate AngelScript as an alternative to lua?
"-strict syntaxs indent is really painful for developers with different coding style(2 space indent,4 space indent,2 tab,4 tab,2space 2 tab etcetc)" Always 4 spaces by convention. I wouldn't call pythons syntax a drawback. Another + for python is that it probably have the best tool support of the listed candidates, though Lua is close behind with things like LuaEclipse. 2007/2/21, The Watermelon <[EMAIL PROTECTED]>: On 2/21/07, Gerard Krol <[EMAIL PROTECTED]> wrote: > > I'd say we'd better use a more mature alternative, as Lua or Python. > > A little comparison: > > Anglescript, call script function from C: > http://www.angelcode.com/angelscript/sdk/docs/manual/pages/man_callscriptfunc.html > Anglescript, call C function from script: > no clear example found > > Python, call script function from C: > http://docs.python.org/ext/pure-embedding.html > Needs quite some code. (but the example is quite complete) > Python, call C function from script: > http://docs.python.org/ext/extending-with-embedding.html > Really easy > > Lua, call script function from C: > http://www.lua.org/manual/2.1/subsection3_7_6.html > Clear > Lua, call C function from script: > http://www.lua.org/pil/26.1.html > Clear > > Please judge for yourself, but Python has my preference, as I have quite a lot of experience with the language. > > - Gerard > > > > -Original Message- > From: [EMAIL PROTECTED] on behalf of Kamaze > Sent: Wed 21-2-2007 0:11 > To: Development list > Subject: [Warzone-dev] Evaluate AngelScript as an alternative to lua? > > Website: > http://www.angelcode.com/angelscript/ > > Infos: > http://www.angelcode.com/angelscript/features.asp > > I read a bit about it and played a bit around with it. > It looks clean, fast, small and stable. And has a c/c++ syntax. > Binding of functions and vars seems to be very easy. > > Maybe you/we should make a closer look to it :) > > - Kamaze python's best companion is C++...lua is too old and rusty...angelcode script is somewhat unstable... python: +superior numeric computation +real arrays +useful for extending exist C/C++ functionalities with modifying the source +popular -implement is rather complicated -strict syntaxs indent is really painful for developers with different coding style(2 space indent,4 space indent,2 tab,4 tab,2space 2 tab etcetc) lua: +easier to implement +C syntax except the optional 'then' +less strict syntaxs +popular -no real arrays use universal 'table' instead -too slow for numeric computation -co-routine is useless in practice angel: never used,but it's unstable according to gd.net forum wz +no need to implement +C/C# like syntaxs +native to wz +real arrays and fast numeric computation +fully implemented trigger and co-routine designed specifically for wz(every [interval] trigger and event-driven callbacks) +implemented using flex,which is best tool for advanced ai scripting,superior ai scripting capability(though it seems pumpkin didnt have the time to make some intensive scripting to unlease its full potential),no other rts had ever achieved this imo -not many ppl are familiar with it -lack of documentation... -lack of examples... -lack of popularity... so I suggest using wz script...which requires no extra memory footprint and it's already implemented natively in wz...binding function is as easy as adding an entry in symbol tables... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev -- Venlig hilsen / Kind regards, Christian Vest Hansen. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Evaluate AngelScript as an alternative to lua?
On 2/21/07, Gerard Krol <[EMAIL PROTECTED]> wrote: I'd say we'd better use a more mature alternative, as Lua or Python. A little comparison: Anglescript, call script function from C: http://www.angelcode.com/angelscript/sdk/docs/manual/pages/man_callscriptfunc.html Anglescript, call C function from script: no clear example found Python, call script function from C: http://docs.python.org/ext/pure-embedding.html Needs quite some code. (but the example is quite complete) Python, call C function from script: http://docs.python.org/ext/extending-with-embedding.html Really easy Lua, call script function from C: http://www.lua.org/manual/2.1/subsection3_7_6.html Clear Lua, call C function from script: http://www.lua.org/pil/26.1.html Clear Please judge for yourself, but Python has my preference, as I have quite a lot of experience with the language. - Gerard -Original Message- From: [EMAIL PROTECTED] on behalf of Kamaze Sent: Wed 21-2-2007 0:11 To: Development list Subject: [Warzone-dev] Evaluate AngelScript as an alternative to lua? Website: http://www.angelcode.com/angelscript/ Infos: http://www.angelcode.com/angelscript/features.asp I read a bit about it and played a bit around with it. It looks clean, fast, small and stable. And has a c/c++ syntax. Binding of functions and vars seems to be very easy. Maybe you/we should make a closer look to it :) - Kamaze python's best companion is C++...lua is too old and rusty...angelcode script is somewhat unstable... python: +superior numeric computation +real arrays +useful for extending exist C/C++ functionalities with modifying the source +popular -implement is rather complicated -strict syntaxs indent is really painful for developers with different coding style(2 space indent,4 space indent,2 tab,4 tab,2space 2 tab etcetc) lua: +easier to implement +C syntax except the optional 'then' +less strict syntaxs +popular -no real arrays use universal 'table' instead -too slow for numeric computation -co-routine is useless in practice angel: never used,but it's unstable according to gd.net forum wz +no need to implement +C/C# like syntaxs +native to wz +real arrays and fast numeric computation +fully implemented trigger and co-routine designed specifically for wz(every [interval] trigger and event-driven callbacks) +implemented using flex,which is best tool for advanced ai scripting,superior ai scripting capability(though it seems pumpkin didnt have the time to make some intensive scripting to unlease its full potential),no other rts had ever achieved this imo -not many ppl are familiar with it -lack of documentation... -lack of examples... -lack of popularity... so I suggest using wz script...which requires no extra memory footprint and it's already implemented natively in wz...binding function is as easy as adding an entry in symbol tables... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
RE: [Warzone-dev] Evaluate AngelScript as an alternative to lua?
I'd say we'd better use a more mature alternative, as Lua or Python. A little comparison: Anglescript, call script function from C: http://www.angelcode.com/angelscript/sdk/docs/manual/pages/man_callscriptfunc.html Anglescript, call C function from script: no clear example found Python, call script function from C: http://docs.python.org/ext/pure-embedding.html Needs quite some code. (but the example is quite complete) Python, call C function from script: http://docs.python.org/ext/extending-with-embedding.html Really easy Lua, call script function from C: http://www.lua.org/manual/2.1/subsection3_7_6.html Clear Lua, call C function from script: http://www.lua.org/pil/26.1.html Clear Please judge for yourself, but Python has my preference, as I have quite a lot of experience with the language. - Gerard -Original Message- From: [EMAIL PROTECTED] on behalf of Kamaze Sent: Wed 21-2-2007 0:11 To: Development list Subject: [Warzone-dev] Evaluate AngelScript as an alternative to lua? Website: http://www.angelcode.com/angelscript/ Infos: http://www.angelcode.com/angelscript/features.asp I read a bit about it and played a bit around with it. It looks clean, fast, small and stable. And has a c/c++ syntax. Binding of functions and vars seems to be very easy. Maybe you/we should make a closer look to it :) - Kamaze ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev <>___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
