Jump to content
  • Advertisement
Sign in to follow this  
WitchLord

AngelScript 1.10.0 WIP 6 (2004/10/31)

This topic is 5432 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Dear subscribers, another update has been made. There's been a few changes to the interface to make it more consistent and easier to use. However, after receiving user feedback, I have kept backwards compatibility with 1.9.x. Though this backwards compatibility is only available if the library and host application is compiled with the preprocessor define AS_DEPRECATED. The methods that have changed are:
  • RegisterObjectBehaviour(), it only accepts true object behaviours now, i.e. the ones that you register with the first parameter naming the object. Another method, RegisterGlobalBehaviour(), has been created for the other behaviour functions.
  • GetFunctionName(), GetFunctionDeclaration(), GetGlobalVarName(), GetGlobalVarDeclaration(), GetImportedFunctionDeclaration(), and GetExceptionString() has changed to return const char * instead so that you no longer have to allocate the buffer before. The pointer that is returned is shared between these functions so you shouldn't store it for later use.
  • All methods that return a string, also take an optional parameter that allow the host to get the length of the returned string directly instead of calling strlen().
I've also started to add support for multithreading. Currently this only works on Win32 and with MSVC++, but I plan on expanding this to Linux (I'll need help on that one) and MinGW. I got some strange problem when trying to support multithreading with MinGW, the code compiled ok, but when testing it would crash at inlogical places, places that haven't been changed. I think it is somehow connected to including windows.h or STL map in the code. Anyway, the support that was added for multithreading was:
  • All reference counting is now threadsafe
  • asGetActiveContext() is working correctly
  • The shared string (mentioned above) is working by keeping a string buffer for each thread
  • Created a new global function asThreadCleanup() that should be called before terminating any secondary threads that have accessed the library. If it is not called the local data allocated for the thread will be cleaned up at application exit. Note, it is not necessary to call this function in a single threaded environment.
It should now be possible to use AngelScript and access the engine and modules from multiple threads at the same time. It still very experimental, but at least rudimentary support for multithreading is now available. Please let me know if you find some trouble or wish to help me provide support for Linux and MinGW as well. I've also made a bug fix in the optimization. I had mistakedly optimized subtractions as if they were associative, this could make calculations with subtractions give the wrong result. Many thanks to Lennart Denninger for helping me find that bug. Regards, Andreas Jönsson Author of AngelScript [Edited by - WitchLord on October 31, 2004 11:05:15 AM]

Share this post


Link to post
Share on other sites
Advertisement
One more update!!!! Way to go......glad I still have'nt updated from 1.7.x though. will take the giant step when 1.10.0 comes out

Share this post


Link to post
Share on other sites
EddHead: The more you wait, more work will be necessary to do the upgrade. Although for this latest version I'm trying to keep backwards compatibility.

Share this post


Link to post
Share on other sites
I didn't compile the library in release mode before uploading the latest WIP. Lennart let me know that there is some problem when doing so, but fortunately the fix is easy: Just turn on language extensions in Visual C++.

I will try to make the library fully working without Microsoft's language extensions.

Share this post


Link to post
Share on other sites
I've uploaded the second WIP of version 1.10.0.

This version brings a much improved ExecuteString() method. The improvements made to the function is:
- Calls to ExecuteString() can be recursive, i.e. ExecuteString() can call a function that in turn calls ExecuteString()
- The application can pass its own context to ExecuteString() for preparation and execution (or just preparation)
- ExecuteString() should work with multiple threads (I haven't tested this yet, but I don't see why not)
- Only one call to ExecuteString() and retrieve the asIContext for exception handling (pass a pointer to a variable that will receieve the context)
- GetContextForExecuteString() is deprecated.

The old functionality is still available by defining AS_DEPRECATED when compiling the library

I've improved the multithread code so that it now works with MinGW as well. I removed the include of windows.h by locally declaring the few functions needed for thread handling. std::map had to be replaced with my own code as I found that the STL library isn't all that well-working as it ought to be. Microsoft's implementation of the STL library doesn't compile when you turn off the language extensions, and MinGW's implementation causes run-time problems with other template codes. My own map class (found in as_map.cpp) isn't quite as well structured as STL's map, but it works. However, I will improve upon it and start using it for other purposes as well, for example for mapping strings to classes, which should improve script compile times as well.

Yes, I know of STLPort which is supposedly much better than any STL library that comes with the compilers, but I don't want to force people to download another library just to compile mine. I have been thinking about rewriting the interface of my classes to match those of STL though. That would make it possible to replace my implementation and save some bytes in the final application.

I also fixed a bug with SetArguments(). It didn't allow the application to pass a pointer to the memory where the script function should return application registered classes. Thanks goes to Thomas Suter for helping me discover that bug.

Regards,
Andreas Jönsson
Author of AngelScript

Share this post


Link to post
Share on other sites
I'm actually using 1.9.2 at the moment, but didn't AS used to protect scripts from dereferencing null pointers? In the past I thought that AS just quietly aborted the script call if the script tried to dereference null, but now it goes ahead and crashes. Or am I wrong?

Share this post


Link to post
Share on other sites
Apparently it is only a problem with ExecuteString:

Data* p = 0;
p->GetId();

Tested it with normal scripts and they aborted fine...

Share this post


Link to post
Share on other sites
It is a bug.

What is happening is that an exception is raised because of the null-pointer access. The crash happens when SetInternalException() is called. Because the functionID for ExecuteString is 65533 there is an illegal memory access with when calling GetScriptFunction(functionID).

If you're pressed for a bug fix you could simply check for this case and skip that call.

The bug was introduced in version 1.9.1 when I took out the line numbers from the bytecode and stored them in a separate array.

Share this post


Link to post
Share on other sites
Here's the complete list of bug fixes available in version 1.9.2a and 1.10.0 WIP 3:

- bug fix: Subtraction was optimized as if it was associative (thanks Lennart Denninger)
- bug fix: SetArguments() failed for script functions that returns registered object types by value. (thanks Thomas Suter)
- bug fix: The application would crash if an exception was raised in ExecuteString() (thanks Joe "Desdemona" Wright)
- bug fix: GetFunctionName() and GetFunctionDeclaration() now works for the ExecuteString() function id as well.
- bug fix: The compiler didn't warn when passing uninitialized variables to function parameters (thanks Alain "abrken" Bridel)
- bug fix: Constructors with parameters could cause assertion failure in GenerateExceptionHandler(). (thanks Alain "abrken" Bridel)

I've started work on incorporating the x86 assembler VM that Andres Carrera (Lioric) sent me. I hope to have this done by this weekend. Then we will see what kind of performance improvement we will really get.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!