Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Today, 12:08 PM

#5249721 Lots of the same warnings when compiling under VS 2015

Posted by Andreas Jonsson on 30 August 2015 - 10:49 AM

Looks like Microsoft has added new warnings in the latest version of the compiler. 


It's nothing to worry about for now, but I'll take care of them once I upgrade to MSVC2015 myself (I'm still using MSVC2012). 




#5249094 Error when saving bytecode on x64

Posted by Andreas Jonsson on 26 August 2015 - 07:56 PM

I've fixed this bug in revision 2215.


Thanks for making it easy for me to reproduce the problem.

#5248657 AngelScript class property with indirection

Posted by Andreas Jonsson on 24 August 2015 - 07:09 PM

I downloaded the source code and reviewed the code. 


These are the problems I found:


  1. You're using version 2.30.0 WIP. Upgrade to 2.30.1 to get the support for registering the position member as a &. (while you're at it you might as well upgrade to 2.30.2 WIP to get the very latest code).
  2. You're registering the value types Transform, Vector3, etc with the flag asOBJ_ASHANDLE. This what is causing the problem you're facing.


I understand you came to the conclusion that you needed asOBJ_ASHANDLE because your members are pointers, but this is not what asOBJ_ASHANDLE is meant for. This flag has a very specific use case, which is to build a container class that should function as a handle. You can see its use in the ScriptHandle add-on.




Upgrade the library, change the code to remove the asOBJ_ASHANDLE in RegisterType<T>, and then change to register the Transform::position as:


r = engine->RegisterObjectProperty("Transform", "Vector3 &position", asOFFSET(Transform, position));




Doing this should make your code work as you want.

#5248426 AngelScript class property with indirection

Posted by Andreas Jonsson on 23 August 2015 - 04:35 PM

I don't see any immediate error in the code that you have shared so far.


As far as I can tell, it should work as you want it.


Perhaps you can show how you're calling the script's Update method. It might be that the problem is there.

#5248388 AngelScript class property with indirection

Posted by Andreas Jonsson on 23 August 2015 - 12:34 PM

Are you getting any errors when executing the script? Is asIScriptContext::Execute returning asEXECUTION_FINISHED or something else?


Why is the Transform::position registered as a handle (@) when Transform::rotation and Transform::scalling aren't? Is the Transform class allocating the position member in the constructor?


I suggest you debug your code to make sure the script is actually having the correct reference to the Transform object in the Actor class. 

#5243305 AngelScript WIP - anonymous functions

Posted by Andreas Jonsson on 28 July 2015 - 07:04 PM

I've added support for anonymous functions in the latest revision (2202) of the AngelScript WIP.


The syntax for using anonymous functions look like this:


void main()
   // Passing an anonymous function to a function expecting a function pointer
   DoSomethingWithACallback(function(a,b) {return a+b});
   // Store a pointer to an anonymous function for later use
   callback @cb = function(a,b) {return a*b;}
// The anonymous function will take on the signature that is expected by the target
funcdef int callback(int, int);
int DoSomethingACallback(callback @cb)
   return cb(1, 2);


Let me know your thoughts, and if you find any problem with this new feature please let me know so I can have it fixed before I make the official release.


Observe, the anonymous functions cannot be used as closures yet. That will have to wait for future time (if ever) as it would require a lot more changes in the compiler.







#5243241 Possible dictionary optimization

Posted by Andreas Jonsson on 28 July 2015 - 01:40 PM

Thanks for letting me know about this.


There is no specific reason for not using the shorter code that you propose. It is just that I never thought about using the operator[] on the std::map container. I never had a reason to look for a shorter implementation as the current one was good enough for me.


That's one of the things I love about C++. No matter how many years of experience you have, there is always something new to learn. biggrin.png



I'll make the changes. Not for the potential performance improvement, but for the sake of cleaner code.



BTW. It's quite useless to do performance comparisons in debug mode. Performance comparisons should always be done in release mode to get as close to the actual code you would use in a released project as possible. Comparing performance of two algorithms in debug mode can easily make you chose to worse of the two, especially when considering cache management, branch-prediction, and multicore features in current day CPUs. In debug mode many of these features are all but eliminated due to all the extra checks that the debug code executes to check the sanity of the code.


I've personally seen cases where algorithms that 'should' be faster due to doing less work, actually becomes a lot slower due to causing more cache-misses or incorrect branch-predictions.


What's worse is that different CPU families/brands behave differently. So never trust numbers you get from only a single machine.

#5241788 About using old objects after recompiling scripts

Posted by Andreas Jonsson on 21 July 2015 - 04:09 PM

AngelScript uses magic to make it work. :)



Discarding a module doesn't immediately remove the module if there are still live objects or other external references to the module. It will be kept in memory until all those references are released in order to avoid dangling pointers, or other lose ends that may cause crashes in the application.


However, this also means that the re-compiled script doesn't share anything with the previous script (unless the script entities have been explicitly declared as shared). Global variables, object types, etc will be distinct for each compilation.

#5238285 AngelScript 2.30.1 is out

Posted by Andreas Jonsson on 03 July 2015 - 07:24 PM

In this new version I had the fortune to get my hands on a MIPS Creator CI20 board, thanks to Alexandru Voica from Imagination Technologies, so I spent some time on adding support for native calling conventions for MIPS processors on Linux and Android.


Adding support for the native calling conventions on Linux was easy enough, since I had already done similar work with ARM, and AngelScript already had support for MIPS on PSP. The ABI used by Linux (MIPS O32) is different than what is used by PSP (MIPS N32) so I still had to do a fair bit of reverse engineering of the ABI by reading assembler code and figure out how values are passed in and out of functions, but the original implementation by Manu Evans for PSP back in 2006 still helped a lot.


The Android support took more time. Not because of the ABI itself, which turned out to be identical to Linux, but because I had never worked with Android myself before. But, I decided it was time to sit down and learn the tools, so I went ahead and installed Android Studio, and Android NDK. It took some time to figure out how it works, but I managed to get the regression test suite to compile and upload it to the CI20. I didn't manage to figure out how to debug the native code on Android, but luckily I didn't have to as the ABI worked perfectly so it was mostly a matter of figuring out how to setup the configurations in as_config.h.


It's been fun learning about Android. I'm still a newbie in this world, but perhaps sometime in the future I'll start writing apps for Android too.


Of course, support for native calling conventions on MIPS is not the only improvement with this version. I've made some optimizations, especially scripts that do a lot of array access operations should hopefully notice a boost in performance. Loading pre-compiled byte-code should also be a lot faster, especially on mobile devices that don't have so much raw computing power.


dkrusu contributed a small language enhancement: for-loops can now have multiple increment expressions separated by commas.


Other than that, there is the usual load of bug fixes and minor improvements throughout. Refer to the changelist for the details.




#5236241 Script builder addon does not detect duplicate scripts on Windows

Posted by Andreas Jonsson on 22 June 2015 - 06:38 PM

I've fixed this in revision 2182.




#5235541 Very slow loading of bytecode on iOS

Posted by Andreas Jonsson on 18 June 2015 - 01:33 PM

From the screenshot it looks like most of the time with loading the bytecode is spent in the function asCReader::ReadUsedFunctions, more specifically with the calls to IsSignatureEqual.


A trivial optimization would be to switch the order of the comparisons in the conditions. For example:


    for( asUINT i = 0; i < engine->scriptFunctions.GetLength(); i++ )
     asCScriptFunction *f = engine->scriptFunctions[i];
     if( f == 0 ||
      !func.IsSignatureEqual(f) ||                        // <-- make this the last check in the condition, since it is the most expensive
      func.objectType != f->objectType ||
      func.nameSpace != f->nameSpace )
     usedFunctions[n] = f;


Going a bit further but still keeping it simple, I would look into rearranging the logic inside IsSignatureEqual(). For example:


bool asCScriptFunction::IsSignatureEqual(const asCScriptFunction *func) const
 if( !IsSignatureExceptNameEqual(func) || name != func->name ) return false;  // <-- change this so the name is compared first
 return true;


Just these two simple changes has the potential of saving 1-2 seconds on your loading time.


Would you mind making the above changes and verifying if the improvement is worth it? If it is I'll have the changes checked in to the SVN for the next release.







A much more complex optimization can be done by storing the functions in a hash map so the lookup done in ReadUsedFunctions() isn't done linearly. This would require a considerable amount of work, and I'm not entirely sure how much time it would save (though I'd guess it would be in the range of 80% of the time).


If the trivial changes I proposed above are good enough, then it will probably not be worth it to spend this time to implement the hash map.

#5232221 Characters being offset by a pixel in BMFont

Posted by Andreas Jonsson on 01 June 2015 - 01:58 PM

This blurriness with the interpolated samples, plus the fact that it was almost correct with point sampling, tells me that you're likely getting samples that are offset by (0.5,0.5) texels, thus each pixel will be rendered as an average of the 4 nearby texels.


Try adjusting the UV coordinates with (0.5,0.5) texels, or perhaps the screen coordinates with (0.5,0.5) pixels.

#5232203 Characters being offset by a pixel in BMFont

Posted by Andreas Jonsson on 01 June 2015 - 12:33 PM

What is the difference between the two applications?



By the looks of the output, I have a feeling it may have something to do with the sampling of the font texture. Are you perhaps using point-sampling, i.e. no interpolation? Have you set up the transform matrices for pixel-perfect rendering? Specifically check the manual for how to adjust coordinates (if necessary) for pixel perfect sampling. It might be that you need to add (0.5,0.5) texels to the UV coordinates to get the best result.

#5230947 Channel information invalidating texture for BMFont

Posted by Andreas Jonsson on 25 May 2015 - 06:57 PM

The DWORD value 256 seen in hexadecimal looks like this 0x00000100. If you consider that each byte of the DWORD represent one channel you'll get (0,0,1,0). 


Then it is just a matter of knowing which byte represents which channel. 


From your vertex format you're telling DX11 that the DWORD should be interpreted as R8G8B8A8, i.e. (Red, Green, Blue, Alpha).

#5230897 Channel information invalidating texture for BMFont

Posted by Andreas Jonsson on 25 May 2015 - 02:40 PM

At least you know now what to investigate further to find the cause of the problem. :)


Let us know what it was when you find it.