Has anyone tried using AngelScript with Marmalade (formerly known as the AirPlay SDK)? I'm having some problems, some of may just be newbie issues, but I've been poking around (trying to remember how C++ works) and I'm starting to think there's an incompatibility with the way AngelScript expects preprocessor directives and the way Marmalade sets them (Using VS2010 Express atm).

If you don't know how it works, Marmalade creates the VS project and solution files automatically from a platform agnostic .mdk file, so I don't have direct control over the settings (and they are not the defaults). I can change them, as long I don't mind losing those changes later. If you can suggest any options I might try, I'll give them a go and see what happens.

I also posted some details of my experiences so far over on the Marmalade forums, so I won't re-post it all here:
http://www.madewithm...vnet/forum/7207

Since those posts I've been trying to trace through the header dependencies to figure out what is trying to include the Win32-specific stuff, and so far I've tracked it back to a quagmire of conditional defines in as_config.h which I haven't picked through it in detail, but it looks like these could be making some assumptions about the platform that don't match the settings Marmalade is using.

At this point I'm getting a bit lost though, as my knowledge of C++ is too out of date to know what to try next, and the conditionals in as_config.h are pretty complicated. If my guess is correct, some of these conditionals might need tweaked to work with Marmalade, or perhaps changing some preprocessor directives is all that is needed? If you need any more detailed information about the compile options etc., let me know and I'll post them.

- Robert

as_config.h is indeed intended to identify compiler and target system, and it will do this using the well known preprocessor defines. If Marmalade uses different preprocessor defines, then it will be necessary to modify as_config.h to allow it to understand these defines.

The first thing to figure out is what preprocessor defines are given by default for Marmalade. Normally there is some option to allow the compiler to output the defines. Consult the manual for Marmalade to find out how to do that. If the option doesn't exist, then perhaps the defines are documented in the manual.

Ones you know which defines are provided, post them here and I'll help you determine the changes needed for as_config.h.

The first thing to figure out is what preprocessor defines are given by default for Marmalade.

OK thanks, I will see what I can do. I can easily give you my preprocessor command line options from VS. I'm not sure if there's another way to easily dump the preprocessor definitions. Any pointers you can give me on extracting the information would be a big help because I'm not fully up to speed with the way VS does this stuff - the last time I did any C++ it was Turbo C++ 3.0 for DOS!

However perhaps the bigger problem is going to be what happens when trying to compile for other platforms. Someone on the other forum has suggested that I wrap it up in a cross-platform subproject, so I'm going to give that a go and see if it helps any. This might help with getting it to compile on my Windows development system, or it might not, but I will try it and see if I can learn anything more in the process of doing it.

For reference here's my complete compiler command-line taken from the config window in VS:

/I"c:/marmalade/5.2/modules/iwutil/h" /I"c:/marmalade/5.2/modules/iwgeom/h" /I"c:/marmalade/5.2/modules/iwresmanager/h" /I"c:/marmalade/5.2/modules/iwgl/h" /I"c:/marmalade/5.2/modules/iwgx/h" /I"c:/marmalade/5.2/modules/iwgxfont/h" /I"c:/marmalade/5.2/modules/iw2d/h" /I"c:/marmalade/5.2/s3e/h" /I"c:/marmalade/5.2/s3e/h/ext" /I"c:/marmalade/5.2/s3e/h/std" /I"c:/marmalade/5.2/s3e/h/std/c++" /I"c:/marmalade/5.2/s3e/h/ext_legacy" /I"c:/marmalade/5.2/s3e/h/legacy" /I"." /ZI /nologo /W3 /WX- /Od /Oy- /D "_WIN32" /Gm /EHsc /RTC1 /MTd /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Debug_FirstGame_vc10_x86\FirstGame.pch" /Fa"Debug_FirstGame_vc10_x86\" /Fo"Debug_FirstGame_vc10_x86\" /Fd"Debug_FirstGame_vc10_x86\vc100.pdb" /Gd /showIncludes /analyze- /errorReport:queue

The project is called "FirstGame". Because Marmalade creates the VS project/solution automatically, it sticks _vc10 onto the end automatically, hence here it is called "FirstGame_vc10". Here I am compiling to x86 (Debug) / Win32. I also tried compiling to x86 (Release) / Win32 in case that makes a difference, but got exactly the same result.

Here's an edited compiler output with header dependency tracing on, so you can see what's happening:

1> as_atomic.cpp
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_atomic.h
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_config.h
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_memory.h
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_criticalsection.h
1> Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windows.h
1> Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\excpt.h
1> Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\crtdefs.h
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(44): fatal error C1189: #error : ERROR: Only Win32 target supported!

(edit: The indentation makes it look like there's a line missing - I just double checked this, there isn't, it's just the way the trace is rendering on the forum)

BTW, I had a look in crtdefs.h to see what was causing the error, and it's the following lines (starting line #43):


#if !defined(_WIN32)
#error ERROR: Only Win32 target supported!
#endif


And you may have noticed that _WIN32 appears to be defined in the command-line options, so I don't know what's causing that.

Someone over on the other forum has got it working, with a number of modifications, some of which could possibly be improved - see:

http://www.madewithm...vnet/forum/7207

I'm still in the process of experimenting with what they've posted.

The Marmalade community seems to be really thriving. You got lots of useful tips from them in a very short time frame.

I haven't really had the time to check out what Marmalade really is, but if it is using the MSVC10 compiler on Windows I see no reason why you cannot use the windows libraries to compile on Windows too. For the same reason I really think the default as_config.h should work without the need for changes (though I'll happily make changes if you find that something does need to be modified).

I'm not sure what's up with the _WIN32 define. I do not explicitly define this in my projects, yet it still works. I should think it is a compiler flag for MSVC.

Have you installed the Windows Platform SDK? It doesn't come with the MSVC Express versions so you need to install it separately. This might be why some of the things don't work as-is.

AngelScript comes with a project for MSVC10. I suggest taking a look at that and comparing it against what Marmalade generated for you. Perhaps it might give you some hint of some other things that may be missing.

If the code for multithreading support is giving you a hard time you can turn it off all together by defining AS_NO_THREADS, that way you don't have to worry about the individual settings like AS_POSIX_THREADS and AS_NO_ATOMIC.

--

I knew about the article on codeplea, but I hadn't see the follow up tests by Pekuja. I'm happy to see my efforts to optimize AngelScript have paid off. Thanks for bringing that to my attention.

I haven't really had the time to check out what Marmalade really is, but if it is using the MSVC10 compiler on Windows I see no reason why you cannot use the windows libraries to compile on Windows too. For the same reason I really think the default as_config.h should work without the need for changes (though I'll happily make changes if you find that something does need to be modified).

I'm not sure what's up with the _WIN32 define. I do not explicitly define this in my projects, yet it still works. I should think it is a compiler flag for MSVC.

The really strange bit is that it is being defined - I can see it on the command-line - and yet when it gets to that part of the code, seemingly it is not defined. I don't recall it being possible to undefine a constant in C++ so this confuses me. I'll probably figure it out after I get more familiar with Visual Studio. I may have misunderstood how those command-line arguments work.

You are right that if the target platform is Windows then it should work. The only thing is, I'm not sure the target actually is Windows even though the config profile is called x86 Win32. It is definitely x86, but it compiles a binary that is run on an abstraction layer called S3E. When you compile and build your project, it loads up an S3E simulator, which acts like a phone or tablet in a window.

Have you installed the Windows Platform SDK? It doesn't come with the MSVC Express versions so you need to install it separately. This might be why some of the things don't work as-is.

I don't recall installing it explicitly, but I must have done because it's there - in fact you can see it in the header trace. I suppose it could be the wrong version. I will look into that.

AngelScript comes with a project for MSVC10. I suggest taking a look at that and comparing it against what Marmalade generated for you. Perhaps it might give you some hint of some other things that may be missing.

Also one of the first things I did - I was able to build the default project with no problems whatsoever, it just seems to be compiling with Marmalade options that creates problems. This also suggests that the SDK is correct.

If the code for multithreading support is giving you a hard time you can turn it off all together by defining AS_NO_THREADS, that way you don't have to worry about the individual settings like AS_POSIX_THREADS and AS_NO_ATOMIC.

That does sound like a possible cleaner way to make it work. I can add the custom define to the .mkb file (the Marmalade x-platform project file) which means it will "just work" ™ (in theory)... I'll give it a shot and see what happens.

Does AngelScript handle concurrency the same, regardless of whether or not it's compiled with AS_NO_THREADS? If it behaves differently, I may need to consider which behaviour is preferable, and whether it works consistently across all target platforms or not.

I knew about the article on codeplea, but I hadn't see the follow up tests by Pekuja. I'm happy to see my efforts to optimize AngelScript have paid off. Thanks for bringing that to my attention.

No problem, thanks for all the hard work on AngelScript and the help with this

Maybe you should ask Lewis from Codeplea if he could do some updated graphs with newer versions of the languages he compared. I nearly ruled AngelScript out of my initial shortlist on the basis that the performance was worse than several others in all categories, but the later version appears to be better in almost all performance tests and about average (small enough) in size. It's much harder to tell from the raw numbers than from looking at the graphs though. It would be good to see that, and also have the old ones up for reference, because the rate of improvement an interesting metric in itself (I would imagine Lua for example hasn't changed much at all over the same period - if anything, more mature languages tend to gradually become more bloated, not get both smaller and faster like AngelScript has)

The really strange bit is that it is being defined - I can see it on the command-line - and yet when it gets to that part of the code, seemingly it is not defined. I don't recall it being possible to undefine a constant in C++ so this confuses me. I'll probably figure it out after I get more familiar with Visual Studio. I may have misunderstood how those command-line arguments work.

You are right that if the target platform is Windows then it should work. The only thing is, I'm not sure the target actually is Windows even though the config profile is called x86 Win32. It is definitely x86, but it compiles a binary that is run on an abstraction layer called S3E. When you compile and build your project, it loads up an S3E simulator, which acts like a phone or tablet in a window.

A define is undefined with #undef

Sounds like it isn't Windows after all. Which makes me wonder how MSVC comes into the picture.

Is the code always built to this S3E format, regardless on which platform your running Marmalade? I mean, is the compiled product platform independent, in the sense that the same file compiled on Windows can be executed on an S3E simulator running on Linux?

Does AngelScript handle concurrency the same, regardless of whether or not it's compiled with AS_NO_THREADS? If it behaves differently, I may
need to consider which behaviour is preferable, and whether it works consistently across all target platforms or not.

AngelScript can still be used in a multithreaded application, but the application will have to be extra careful to avoid having multiple threads accessing the engine in parallel.

Manual: Multithreading

I read a little about Marmalade. While I still have some doubts about how it handles the lowlevel stuff, such as function calling conventions across platforms, it is pretty clear to me that Marmalade should probably be considered a platform on its own, with its very own configuration in as_config.h.

As it is mostly targeted for mobile devices, I don't think you'll lose anything by declaring AS_NO_THREADS, however if you want to support multithreading you should likely use the AS_POSIX_THREADS, and you'll have to figure out from the team behind Marmalade, on how to do atomic operations. Using AS_NO_ATOMIC will work, but it is much slower than if the Marmalade provides proper atomic operations, because the AS_NO_ATOMIC simulates atomic operations with critical sections that needs to be entered, exited, with each access.

I'm very curious to know how Marmalade deals with all the different native calling conventions, but in the event that AngelScript doesn't work with the native calling conventions in the way that Marmalade does it you may need to define AS_MAX_PORTABILITY, which turns off support for native calling conventions. Instead you need to register the application functions using the generic calling conventions. The autowrapper in the add-ons will help you implement the wrappers with very little effort.

It would be good to know if there is a specific define that Marmalade provides for the code in as_config.h to automatically detect that the library is being compiled for Marmalade. If there is none, then I suggest you define MARMALADE in the project settings and change as_config.h to use that for detecting the situation.

I read a little about Marmalade. While I still have some doubts about how it handles the lowlevel stuff, such as function calling conventions across platforms, it is pretty clear to me that Marmalade should probably be considered a platform on its own, with its very own configuration in as_config.h.
....
It would be good to know if there is a specific define that Marmalade provides for the code in as_config.h to automatically detect that the library is being compiled for Marmalade. If there is none, then I suggest you define MARMALADE in the project settings and change as_config.h to use that for detecting the situation.

Yes, I've been going through the code that Kite posted over on the other forum (did you look at that btw?) and trying out a few things myself. I've come to the same conclusion: clearly there is a need for an additional define (Kite called it AS_MARMALADE in his version).

Marmalade doesn't define anything automatically, but it does allow you to add custom defines to your project with a block in the .mkb (or .mkf) file, like this:


defines {
AS_MARMALADE
AS_NO_THREADS
}


The only thing in Kite's version that (maybe) isn't necessary is the following:


#if defined(AS_MARMALADE) // Marmalade.
#define AS_POSIX_THREADS
#define AS_NO_ATOMIC
#else
#define AS_WINDOWS_THREADS
#endif


By also defining AS_NO_THREADS as you suggested, this bit isn't needed (and it's a bit of a hack anyway because it's in the Windows-specific part so there might still be build errors compiling for other platforms).

The other changes are necessary because certain functions are missing. For example, MSVC++ 9+ is detected so it is assumed that the _s (safe) versions of functions are available, but Marmalade does not provide these and does not include the default libraries (I presume it provides its own implementations of the ANSI libraries for S3E).

I don't know if the way Kite modified these files is the best option for full cross-platform support, or if it is better to include a conditional that sets up all the options for Marmalade irrespective of the compiler. I don't know what would happen now if you tried a compiler other than VC++ 10, but I suspect there could be similar issues with missing libraries. I'm not familiar enough with the structure to say for sure which would be best.

Kite's version does the job for me for now, but it would be good if a Marmalade configuration could be added to trunk. Using AS_MARMALADE as the de facto standard constant seems fair enough, as it's pretty easy to add to the Marmalade configuration.