Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!

Jason Goepel

Member Since 15 May 2013
Offline Last Active Dec 22 2014 08:25 AM

Topics I've Started

Multithreading - Creating a Module

04 November 2014 - 03:25 PM

I know that building multiple modules in separate threads that belong to the same engine is "thread safe" because the engine will only allow building one module at a time.


It looks like if multiple threads are calling "asIScriptEngine::GetModule" and "asIScriptModule::Discard" at the same time they calling code should acquire a lock first, since these functions modify an array belonging to the engine.  I'm not suggesting that the functions themselves should block.  I am just confirming that the burden is on the application to synchronize those module-related activities.

// Create a new script module
asIScriptModule *mod = engine->GetModule("module", asGM_ALWAYS_CREATE);

// Load and add the script sections to the module
string script;
LoadScriptFile("script.as", script);
mod->AddScriptSection("script.as", script.c_str());

// Build the module
int r = mod->Build();

// ... Do something with the module


C++ Compiler Warning

28 October 2014 - 08:00 AM

This is not a big deal, but I build my projects with Microsoft's VC++ compiler, and I set the warning level to 4.  When I build AngelScript targeting the x64 platform I get the following compiler warning.


>source\as_builder.cpp(240): warning C4267: 'initializing' : conversion from 'size_t' to 'AngelScript::asUINT', possible loss of data


I would recommend an explicit cast here so that the warning does not appear.


asUINT numTempl = (asUINT)engine->templateInstanceTypes.GetLength();


Implicit Convert Math Bug

09 October 2014 - 12:08 PM

I think there's a bug somewhere when compiling math operators and using implicit conversion functions.  The following test fails.

int x = 1;
class A
    int val;
    A(int x)
        val = x;
    int opImplConv()
        return val;

A myA(5);

void main()
    assert(myA + (x + 1) == myA + x + 1);

The error seems to be that after the CALLINTF instruction for A::opImplConv there is no following CpyRtoV4.  The error is in the bytecode generated on the left side of the comparison.


Also, if the global declaration of "x" is removed and a local declaration of "x" is added to the main function the bug is gone.


ActiveContext for Context and Module Cleanup

30 September 2014 - 02:06 PM

I have some script objects which call asGetActiveContext in their constructors, using information from the custom user data.  Since the asCModule::ResetGlobalVars function now takes a context pointer, those objects function properly.


I also need to have access to the context in the destruction of those objects, but there is no "active" context when a module is being discarded or when a context is being unprepared.  Could the asCModule::Discard function be changed to take a context, and could the asCContext::Unprepare function be changed to set itself to the active context before releasing objects?


I haven't provided a patch myself, because I'm not sure if those changes would clash with the design or if there is some subtle issue with setting a context to the active one as it is unprepared.



Ambiguous Enum Comparison

11 September 2014 - 01:15 PM

The following code will produce an error, even though the ambiguity could be resolved.

enum MyEnum1

enum MyEnum2

bool main()
    MyEnum1 e = cNo;
    return e == cYes;

I have attached a patch that resolves the ambiguity.