WitchLord

Moderators
  • Content count

    8033
  • Joined

  • Last visited

Community Reputation

4681 Excellent

1 Follower

About WitchLord

  • Rank
    Moderator - AngelCode

Personal Information

  1. 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/
  2. 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/
  3. 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.
  4. 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
  5. 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).
  6. Bitwise Operator

    Thanks for the suggestion. I'll certainly consider it.
  7. 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.
  8. 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.
  9. 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?
  10. MSVC 2015 compiling error due to spaces in path

    Thanks. I've included this fix in revision 2424.
  11. sdk samples/asbuild

    I must apologize. Though it is not a bug in the code, the sample config.txt in the official release is outdated and no longer compatible with the latest version of the engine. That is the reason for the error you identified. I have now updated it in the latest SVN revision. The intention with asbuild is that you would generate your own config.txt based on the configuration you use in your own application. To generate your own config.txt you can use the WriteConfigToFile helper function from the add-ons.
  12. Constant integer corruption with VS2010

    I haven't been able to reproduce the problem you reported. I use MSVC2015, though I sincerely doubt it would be different with MSVC2010. I did the test like this: r = ExecuteString(engine, "const int64 a1 = 4287660160; assert(formatInt(a1, '0h', 8) == 'ff908080'); \n" "int64 a2 = 4287660160; assert(formatInt(a2, '0h', 8) == 'ff908080'); \n" "const int64 a3 = 4287660160.0f; assert(formatInt(a3, '0h', 8) == 'ff908000'); \n" // due to float precision the result is different, but correct "int64 a4 = 4287660160.0f; assert(formatInt(a4, '0h', 8) == 'ff908000'); \n" // due to float precision the result is different, but correct "const int64 a5 = 4287660160.0; assert(formatInt(a5, '0h', 8) == 'ff908080'); \n" "int64 a6 = 4287660160.0; assert(formatInt(a6, '0h', 8) == 'ff908080'); \n" ); if (r != asEXECUTION_FINISHED) TEST_FAILED; Note, 427660160.0f is not equal to 4287660160. The float type has only precision enough for 6 digits, so the 427660160.0f actually becomes 4287660032. (This of course depends on the way the float is represented in memory, but IEEE 754 standard is the most common on the CPUs).
  13. sdk samples/asbuild

    Hmm. It surprises me that this error is there in the official release. I use the same version of MSVC as you, and I always test all the samples before releasing an official version. Anyway, thanks for confirming which version you're using. I'll investigate what could be causing the problem.
  14. sdk samples/asbuild

    Which version of AngelScript are you using? Is it the latest WIP version from the svn? It's been a while since I've tested the samples in that version (I usually only do that before release). I'll give it a try as soon as I can and let you know if I can reproduce the problem.
  15. Constant integer corruption with VS2010

    That is very odd, more so that it only happens on MSVC, as it doesn't look like the type of problem that would only happen on one compiler/platform. I'll investigate it.