Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Jason Goepel

Member Since 15 May 2013
Offline Last Active Today, 01:07 PM

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.