Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

869 Good


About Solokiller

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Solokiller

    Read message from std::exception into script exception

    You could use C++11 and newer exception support to handle some of this more easily: http://en.cppreference.com/w/cpp/error/current_exception http://en.cppreference.com/w/cpp/error/uncaught_exception http://en.cppreference.com/w/cpp/error/rethrow_exception More: http://en.cppreference.com/w/cpp/header/exception You can use this to implement a callback to handle the exceptions without needing explicit support in Angelscript's code: void HandleASException( asIScriptContext* pContext ) { if( std::unhandled_exceptions() > 0 ) { try { std::rethrow_exception( std::current_exception() ); } catch( const std::exception& e ) { } catch( const MyException& e ) { } catch( ... ) { } } } (could also be a while ( std::unhandled_exceptions() > 0 ) loop) So what you need is a per-context or engine-global callback. This can be handled just like the line callback: http://www.angelcode.com/angelscript/sdk/docs/manual/classas_i_script_context.html#ae2747f643bf9a07364f922c460ef57dd
  2. Solokiller

    Git mirror for Angelscript SVN repository, CMake support

    I discovered that i used the wrong variable for config file generation. It seems that it causes no issues because the version is defined above as PROJECT_VERSION, but i've fixed it anyway to be sure. I've also added a CMake option to disable exceptions, since there is apparently no way to set preprocessor definitions from the command line. Both changes can be found in today's commits here: https://github.com/SamVanheer/Angelscript/commits/cmake-update
  3. Solokiller

    Git mirror for Angelscript SVN repository, CMake support

    Thanks, i'm starting work on upgrades now for AngelscriptUtils. I do have to correct one of my earlier statements regarding library dependencies though: CMake only keeps track of what the dependencies are, but you still have to find them yourself. In this case, you need to do this yourself: find_package( Threads REQUIRED ) Otherwise it complains about a missing target. This does not appear to apply to targets that are defined in the current context, so for example in my AngelscriptUtils repository, the test program will implicitly link Angelscript::angelscript and Threads::Threads when it links with AngelscriptUtils.
  4. Solokiller

    Call function with primitive ref parameter from C++

    The documentation seems to disagree with itself, just below that is an example of a reference to an int: // The context has been prepared for a script // function with the following signature: // int function(int, double, bool, int &out) // Put the arguments on the context stack, starting with the first one ctx->SetArgDWord(0, 1); ctx->SetArgDouble(1, 3.141592); ctx->SetArgByte(2, true); int val; ctx->SetArgAddress(3, &val); I use SetArgAddress for these arguments.
  5. Solokiller

    Git mirror for Angelscript SVN repository, CMake support

    A friend of mine found this: https://gist.githubusercontent.com/ticean/1556967/raw/f075637ea8c15c8861986f52b8720ef2cc9d78ce/SVN_Git_Mirror.md Seems that the work has to be done on the Git side. A script could run once a day to sync it, but it would probably have to run on a server to make this all work. Regarding CMake versions, 3.5 is about 2 years old so most users should have no issues using it. Requiring the latest version isn't really a good idea since most users won't have it installed so soon. On Linux CMake tends to be a few versions behind in package repositories so unless new features are required it should be fine as-is.
  6. Solokiller

    Git mirror for Angelscript SVN repository, CMake support

    I was suggesting a way to synchronize a Git mirror with the SVN repository, so that any commits made in the SVN repository are mirrored in Git as well, including tags. I don't know how to set this up myself as i have limited experience with SVN, but if it's possible it would make things a bit easier. I updated the CMake project file, you can find the files here: https://github.com/SamVanheer/Angelscript/tree/cmake-update/sdk/angelscript/projects/cmake What i've done is update the syntax to use the modern target_* commands, which are more explicit about how they work (the old commands can affect previously defined targets), let you specify how these properties are inherited and will avoid any issues if there are ever other libraries added to the Angelscript project. I've set the minimum CMake version required to 3.5, which is the last version to still support Visual Studio 1998 and 2002. I couldn't find any information on the minimum version that Angelscript supports, so i assumed the earliest version supported by modern versions of CMake. I've added installation rules to place the compiled binaries and the header file angelscript.h at the user defined installation path. The result is that 3 directories (2 if not building shared libraries) will be created: include, bin and lib. Additionally, several files are automatically placed in lib/cmake/Angelscript. These files are used by CMake's find_package command to locate the library and produce an imported target to link with. A user need only define Angelscript_DIR to point to the directory containing these files, and use the following CMake commands: find_package( Angelscript CONFIG REQUIRED ) target_link_libraries( MyProject Angelscript::angelscript ) This will locate the library and link with it. CMake takes care of the threading dependency on its own, so the Threads package is located and added automatically. You do not need to specify the include directory containing angelscript.h yourself, as this is also taken care of automatically. CMake also handles versioning automatically here, so it knows which version is specified by the file. For example: find_package( Angelscript CONFIG 2.32.1 REQUIRED ) Will give you this error: CMake Error at CMakeLists.txt:14 (find_package): Could not find a configuration file for package "Angelscript" that exactly matches requested version "2.32.1". The following configuration files were considered but not accepted: <install path>/lib/cmake/Angelscript/AngelscriptConfig.cmake, version: 2.32.0 This makes detecting version issues much easier since it won't even generate build files if the version has changed, so when using an automated build system you can detect compatibility issues right away (i use webhooks to get build failure notifications in Gitter). So yeah, this really makes using Angelscript with CMake a lot easier. I'm going to upgrade my own projects with this as well since it makes using them much easier.
  7. I'm looking to rework my Angelscript utility code to separate out the Angelscript library into its own repository. I figured that somebody else probably did it before, and so i searched for and found several repositories on Github containing old mirrors of the SDK, some with additional changes like CMake support. CMake support is provided in sdk/angelscript/projects/cmake, although it uses outdated syntax to support older versions of CMake. At least one of these (https://github.com/svn2github/angelscript) was set up to automatically mirror the commits, but it seems that none of these repositories are still actively mirroring the commits. So i'm wondering if there are any plans to set this up as part of the SVN repository's commit handling. Basically, a Github repository automatically receives commits as the SVN repository does, with tags pushed for version releases. It seems that commits that update version numbers always follow the same format: "Releasing major.minor.patch", so a script could detect this and add a tag to it. It would make using Angelscript in projects easier and make the other mirrors obsolete (and prevent the creation of even more, as i almost did this myself), so it's a win-win for everybody. On the subject of the CMake project file: there is no setup for install targets, which would usually install the library and the header file somewhere to be used. I'd suggest installing to <target>/angelscript_major_minor_patch, optionally installing shared libraries in lib/shared and static libraries in lib/static, with a FindXXX.cmake file to locate it automatically based on this. This is how Boost does it (specifically https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L1222), and lets you have multiple versions installed side by side. Of course, it is ultimately up to the end user so having it detect the version some other way (like parsing angelscript.h for ANGELSCRIPT_VERSION_STRING) might be better. Boost searches for config.hpp in paths that adhere to the version number approach i mentioned above: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L1240 Here's Boost's FindBoost file: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake And here's the documentation for it: https://cmake.org/cmake/help/v3.0/module/FindBoost.html Ideally with this done, getting started with Angelscript would involve cloning the repository, setting it up with the desired compile settings (e.g. AS_NO_EXCEPTIONS, which should be possible using a CMake variable like CMAKE_CXX_FLAGS), installing it and then using it in your own projects by calling: #Find this exact version of Angelscript, error if not found find_package( Angelscript 2.32.0 EXACT REQUIRED ) target_link_libraries( my_executable optimized Angelscript::Angelscript debug Angelscript::Angelscriptd ) And then using an imported target to link with it automatically. This target could have angelscript.h specified by adding an interface_include_directories property, making it even easier. I'm assuming that a debug version would be provided as a separate target here. Having each release push a tag would make it easy to get the version you want, and you can switch to WIP by pulling the latest commit. Once set up it should be as simple as recompiling and executing the install target to bring your projects up to date. With such a repository set up on Github, it may be possible to have additional hooks triggered there to do other things, but i assume this requires write access to the repository to set up. It could allow for automatic builds to test for breaking changes or compiler/platform specific issues as well.
  8. Solokiller

    implementing partial templates

    So you want to register template specializations? That sounds good, it should complement the existing validation system, but then the callback wouldn't be invoked for specializations, right?
  9. Solokiller

    implementing partial templates

    I think what's confusing to people new to the language is that C++ templates and Angelscript templates aren't the same thing. In C++ it's a specialization that relies on compile time code generation, in Angelscript it relies on storing an object's type along with the object. Unfortunately you can't just register a type vector<T> and use std::vector for it, unless you have a class that can store an Angelscript object. Even if you did, it'd be more efficient to use a specially designed container that only stores type T's type info instead, since that takes up less memory.
  10. Did you also register the copy constructor and assignment operator? You specified these as being present (asOBJ_APP_CLASS_CDAK) but you didn't show them. You may be having issues there. Also, you showed the registration for length but not length2, could you show the code for that?
  11. Solokiller

    Variadic arguments support

    You can use the generic calling convention along with variable parameters. You'll have to register one for each number of parameters but it'll work like you want it to.
  12. Are you sure setupScene isn't being called more than once? That could explain the different addresses.
  13. How is the dbg global variable declared in C++? What is its class hierarchy, is it a class with no base classes, does it use multiple inheritance, etc. Also, try using a const reference to the string. There may be an issue with pass by value use:
  14. The WriteConfigToStream function in scripthelper.cpp fails to reset the namespace when it writes out the string factory and array type. This can result in the wrong namespace being used. For example: prop "const uint ClientDisconnect" namespace "Hooks::Game" prop "const uint MapChange" // String factory strfactory "string" // Default array type defarray "array<T>" These are the last few lines of a config i'm reading in.   Should be easy enough to fix, just add the same code to reset the namespace. I would recommend refactoring that code so the logic is in its own function, perhaps turn these helpers into classes so the current namespace is kept as a member. That's simpler than passing in a reference.
  15. Solokiller

    Yet another C++ object instantiation question

    I'm glad you like my work, but some of the stuff in AngelscriptUtils is not yet finalized. I've been working on a tool that aims to automate the generation of C++ wrapper classes for inheritance. It would eliminate some of the lookup issues by performing them up front. The idea is that required methods (pure virtual) and commonly called methods (e.g. GetPosition()) would always be looked up, rarely called ones would be looked up on demand to reduce memory usage in terms of caching. By automating it it would make it easy to use with little to no overhead (no hash map of functions to cache things, just a member variable), you'd simply add an annotation to indicate the usage and the generator does the rest.   I'm using CMake to help with this by using its JSON compile commands database to process a codebase and extract the information, in addition to XML config file provided alternative annotations. Most of the inheritance code would thus become autogenerated, using Mustache templates to provide the class layout. libClang does the work of processing the codebase.   I was also thinking of generating function calls at compile time using C++11 variadic templates combined with template overloads for classes that provide metadata for application registered types, which would also be autogenerated. At compile time, the function would know that a CBaseEntity* is a reference type with no reference counter, that Vector& is a value type, etc.   AngelscriptUtils itself is intended to be more of a starter's kit than a fully functional implementation. You can easily implement Angelscript with it, but eventually you'll have to replace it with purpose built systems when you need more specific features. The features provided are designed to be usable on their own when possible, but that may not always make them applicable to your use cases.   I'd like to see built-in support for inheritance as well, but it's not always possible to integrate that into existing codebases. For example, i implemented it in the GoldSource engine, which has entity classes that have a rigid construction method that isn't easily adapted to Angelscript. I had to use the template based inheritance pattern to insert Angelscript support for every class that needs to be inherited from, and manually write every overrideable method, which is pretty painstaking and error prone. That's why i chose to focus on automated code generation, it eliminates most of the problems right off the bat, handles every edge case (e.g. converting std::string to char*) and lets you insert debug code to test things at runtime to validate that the usages of the generated code are correct. For example, even if you use a variadic function to set up a context for execution with compile time deduction, it won't prevent you from calling a function or method with a different signature than what you passed into the helper. That can only be validated using either a preprocessing tool (verify that the given function matches the given arguments, only possible if the function's signature is known at compile time) or by validating the call at runtime.   Automating it also has a major benefit in that you can extract documentation and generate API information from it. The tool would generate the adapter classes, and generate a list of all methods complete with the changes made to make them compatible with Angelscript. A method that takes a const char* would take const string& in in a script class, so the tool would transform the call and properly handle those calls. The documentation would be based off of libClang's Doxygen documentation interface output, transformed to match the parameter changes. It would then be output to an XML file, which can be fed as input to any program that can transform that data. I was thinking of writing a program that uses Mustache templates to generate HTML, text and Markdown versions for use on websites, minified documentation and Github wikis, respectively.   I haven't had the time to work this stuff out yet since i've taken a break from programming, but if you think you can make it work, it's possible.
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!