Hello there, We have been using Angelscript for some time now, and have recently tried upgrading to a number of the newer versions without much luck. It seems that something in the internals has changed so that the functionality that we had working previously is no longer behaving as it was. Is anyone else seeing this kind of strange behavior? We originally were using 2.4 but have needed / wanted to move to 2.8 or newer as there are a number of things in the newer versions that our users have been looking forward to (classes, etc). The main reason we moved to 2.8 was to add proper PPC support (we are using the native function interface for registering functions / objects), and have done quite a bit of work on native PPC support as well, but until we resolve these issues we can't really move forward with the newer versions. It's difficult to even explain what is happening with the code, but it seems to be directly related to variable registration. I'm wondering if it has to do with the class / object-oriented support that has been added that is possibly changing the scoping of variables within angelscript. For example, we define a variable like so (outside of a script function, but within a single script): bool myVar; then within a script function, set the variable void MyFunction() { myVar = true; } then when we check the state of that variable in another function, it is not set (value is cleared) void MyFunction2() { if (myVar) Print("variable True!"); } The way that we are managing scripts is that each individual script is a single 'scope', but this scoping seems to have changed in the new release. Anyways, I can try to provide more detailed examples, but I'm just curious if there are any long-time users of AngelScript that are seeing this kind of strangeness in 2.8 or newer?

Are you referring to global variables being shared within a module? I believe global variables, within a module, are shared across contexts using that module.

Edit: sorry, I think I misread your post in my initial comment.
Do you have any other contexts accessing this module that might be resetting the global variable to false?

Are you using native calling conventions for PPC in the latest source?

Are you using the latest source from SVN or from the website download?

PPC support is buggy, except for PPC64 support. I completely rewrote the PPC support for PPC64 (PS3), but the original PPC (32 bit) support was not touched. There may be bugs related to using global booleans with setting and checking. What if you make your global variable an int instead of a bool?

Hi,

PPC support is probably not working that well yet. As midnite said, he added support for PS3 which uses 64bit PPC, but this probably won't help much for other PPC systems. I recently received a Mac Mini (from Martin Wengenmayer of Cheetah3D) so I'll be working on adding support for native calling conventions on Mac OS X (both with intel processor and PPC processors).

The scoping of global variables, as you say, have not been changed. Variables declared globally in a script have always been shared between all contexts referring to the same module.

You're probably suffering from the bug that was recently reported by other users. This bug presents itself with boolean variables which seems to either not be updated correctly, or not compared correctly in expressions. I was never able to reproduce this bug myself, but midnite sent me some updated code (currently in the SVN) that may have fixed this problem. The users that reported the original bug haven't been able to confirm nor deny the fix of the bug though.

I suggest you get the latest WIP from the SVN and try again.

Also, give midnite suggestion a try. Change the boolean variable to an int and see if that works.

Let me know how it goes. This bug has been bothering me for a while, and I really would like to know if it has been fixed.

BTW. What compiler and target system are you using?

Sorry, my fault - I mentioned the PPC support simply because of some work we've done to port the engine to other platforms (360, Mac OSX), but the issues that I'm seeing are prevalent on Windows as well.

If we can figure out what is going on with the windows version, we can finish the PPC native interface code that we've done and submit it to the project. We are very close for both the 360 and Mac OSX versions of the native interface.

We've tried a number of different versions that have all done the same thing (or stranger even).

The last attempt was to update to the svn head, which ended up diverging even further from the functionality that we had previously. Our original update was to 2.80a, which is what broke things initially, but the latest svn head has reduced us to even less functionality.

We are using the native interface for everything currently (which is why we wanted to write the native interface for PPC), but I may see if we can port our angelscript wrapper to use the non-native implementation to see if we can solve some problems.

The developer that we had working on the PPC assembly port seemed to think that it was something to do with the move from stack-based variable management to the register-based system that changed how variables are passed around internally within Angelscript, but beyond that we haven't been able to track down what exactly has changed that caused these problems.

I can revert back to 2.41 and things work fine again (except for the scripts that we've written to test the new angelscript functionality).

Thanx in advance
Mike W
GDGi

I cannot begin to imagine what is wrong. It`s definitely possible that the move to register based operations instead of stack based may be the cause of this, but all the tests I`ve made works just fine.

I definitely want to help you upgrade to the latest version of AngelScript. But I need help in finding the errors that are in AngelScript. Would it be possible for you to write a small test that reproduces your problem in the style of one of the ones in the test_feature application?

The PPC support is certainly welcome too, even if you don`t get to finish it. I should be able to add the Mac OS support myself now, but the 360 support is still beyond me.

Have you tried upgrading to just 2.5.0? Did that show the same problems?

Regards,
Andreas

One thing that we've fixed is that if the return value from a function was less than 64bits the return value in the stored in an angelscript VM register was only partially updated and the rest could contain garbage.

I'll try to see if we can come up with a small test app, that reproduced the issues - unfortunately it's a wierd situation, some scripts work, others don't - and since we have ~1000 script functions implemented in the engine, it's very time consuming to try and debug every single function to double check what's working and what isn't.

As far as I can tell, the issues are entirely related to variable passing, whether it's storing object handles or simply passing variables from the application to the scripting system.

I'll see what I can do for a test app and get back to you.

Great!

In the meantime I'll work on the Mac version of AngelScript. Maybe I'll come across some of the problems you're having, now that I have a second compiler and target system to work with.

Regards,
Andreas