WitchLord

Moderators
  • Content count

    8039
  • Joined

  • Last visited

Community Reputation

4682 Excellent

1 Follower

About WitchLord

  • Rank
    Moderator - AngelCode

Personal Information

  1. AngelScript - changes to how string literals are handled

    I'll make sure to include a clarification for these things in the documentation for the release.
  2. This was the first I tried when attempting to reproduce the problem. I'm pretty sure this bug has already been fixed in the latest WIP version. Looking through the change log for throughout the year can see a couple of fixes that may very well have fixed this problem.
  3. Registering the copy constructor will work-around the problem, but it shouldn't be necessary. It is surely a bug in 2.31.1 that is causing this null pointer exception. I haven't been able to reproduce this problem with the latest WIP version from the svn yet. The version you are using is nearly one and a half year old. Would you mind giving the latest WIP version a try to see if you can reproduce the problem in that? float length = length2(s.getPosition() - capturePosition); In this code, can you tell me what s is? and how it was declared? Is it a script class? registered type? Is it a global variable, or a local variable? What is the signature of the method getPosition()? Does it return the vec3 by value or by reference? The capturePosition variable? is it global, local, or a function argument?
  4. AngelScript - changes to how string literals are handled

    I'm sorry, I missed your posts somehow. Can I assume you were able to resolve all your problems with the new string factory? The GetRawStringData is used when the script engine needs to know the original string content, for example when saving the bytecode. Currently it is also used during the compilation to make a copy of the string literals when finalizing the bytecode for a recently compiled script function. This is slightly unefficient and I'm looking into removing this, if I can find a better way. If I'm successful it will only be used when saving the bytecode.
  5. Hi valenn, this has the looks of being a bug in the AngelScript compiler. There shouldn't be any need to store the result of opSub in a variable before passing it on to the next function. I'll investigate it. You didn't say where the null pointer exception is coming from? Just a couple of tips (not necessarily related to the bug): - Instead of using the flags asOBJ_APP_CLASS_CDAK, use the asGetTypeTraits function. That way you don't have to guess what flags to use, e.g. asOBJ_VALUE | asOBJ_POD | asGetTypeTraits<Vec3Primitive>(). - Does your Vec3Primitive really have an explicit destructor that does anything? If not, I suggest skipping the registration of the destructor behaviour. That would be one less call that the script engine has to do. - Your length() and length2() functions are taking the argument by value. I suggest changing it to take it as const reference (i.e. const vec2 &in). This will allow the compiler to skip making a copy of the vector in some situations, thus improving the efficiency.
  6. a lot of strings causes assertion fail

    This restriction has now been removed in the latest WIP version. https://www.gamedev.net/forums/topic/693565-angelscript-changes-to-how-string-literals-are-handled/
  7. stringConstants larger than 65536

    This restriction has now been removed in the latest WIP version. https://www.gamedev.net/forums/topic/693565-angelscript-changes-to-how-string-literals-are-handled/
  8. AngelScript - changes to how string literals are handled

    The only impact is that the asBC_STR instruction is no longer used. So far it is still defined so any JIT compiler that does something with that will not fail to compile. But I will eventually remove the definition all together, and then the JIT compilers will have to be updated to remove it as well.
  9. I've changed how string literals are handled in the script engine. Now the compiler evaluates them at compile time and stores a pointer to the application native string type in the byte code. This avoids the need to create new instances of strings every time a script uses a string literal, which in turn translates to a performance improvement. A new asIStringFactory interface is used to perform the compile time evaluation. This also allows the application to keep track of the used string literals, and store them in a common pool to reduce memory consumption for duplicate string literals. With the factory interface there is also no need for the script engine to keep an internal copy of the string literals thus reducing memory consumption even further. Since the byte code now stores the pointer to the actual string object, the byte code instruction asBC_STR has no use anymore, and with that the restriction of a 2^16 maximum amount of string literals is eliminated. Besides the above benefits I should also be able to take this a step further as the compiler now knows that the life time of a string literal is guaranteed, so it should take advantage of that and avoid making unnecessary copies when passing string literals to functions, etc. Though this improvement has not yet been implemented. For existing scripts there shouldn't be any changes, except if the application currently registers the string factory to return a non-const string object instance. As the string literals are now evaluated at compile time it is no longer possible to have them treated as non-const, still I've made it so that the compiler can when needed implicitly convert to a non-const instance by making a local copy of the string literal at run-time. As the changes has been quite extensive, I decided to make it possible to temporarily turn off these changes until all bugs have been rooted out. To turn off the changes look for the #define AS_NEWSTRING in angelscript.h and comment out that line. Before I make the official release (hopefully before the end of the year) I'll remove this option completely. Let me know if you encounter any problems with this, so I can have it corrected before the official release. Regards, Andreas
  10. Constness questions

    Methods being const or non-const doesn't make a difference in terms of performance. If you have a const reference to an object, then you'll only be able to call const methods on that object. Declaring primtives and objects as const can help improve performance. The compiler is able to evaluate at compile time some operations involving constant primitives. Also when declaring function arguments, prefer the 'const type &in' variant as in some cases the compiler will be able to avoid making a copy of the value if it can determine that the original value has a guaranteed lifetime. As for the question about the switch statement. At this moment the switch cases must use literal constants that can be evaluated at compile time. It is not enough to be read-only objects, because these are not evaluated at compile time. On the VS2010 problem. Is there a specific reason why you're still using VS2010? Have you tried a newer version of VS? I believe VS2017 is already available (though I'm still using VS2015).
  11. Bitwise Operator

    Thanks for the suggestion. I'll certainly consider it.
  12. shared by default

    That looks quite nice. I'll add it to the to-do list for a potential future implementation, Thanks for the suggestion.
  13. Error compiling

    OK. Thanks for the confirmation. I'll see if I can reproduce the problem. It's been a while since I used Code::Blocks. Perhaps I need to upgrade to the latest version.
  14. Error compiling

    The error is probably due to gnuc optimizing out some parts, but since it cannot optimize the inline assembler this could be causing the conflict. Please show me the gnuc compiler arguments that you use when compiling for release mode. Also, are you compiling for 32bit or 64bit?