Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

4701 Excellent


About WitchLord

  • Rank
    Moderator - AngelCode

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. WitchLord

    `asCContext::CallScriptFunction` called with null

    Fixed in revision 2569. Regards, Andreas
  2. WitchLord

    `asCContext::CallScriptFunction` called with null

    Thanks for the detailed report and for finding the minimal code to reproduce the problem. I'll investigate and have this fixed as soon as possible.
  3. WitchLord

    Auto keyword behavior was changed?

    Are you sure you retrieved and recompiled with the code changes? The test case I added to test_feature matches your script, and before the fix it reproduced the problem.
  4. WitchLord

    Operator assignment question

    OK. Maybe it is the RegisterObjectType that is wrong, causing the native ABI to not understand how C++ is returning the CPoint. Try changing the RegisterObjectType to the following: Throw( pEngine->RegisterObjectType("CPoint", sizeof(CPoint<float>), asOBJ_VALUE | asOBJ_POD | asGetTypeTraits<CPoint<float>>() | asOBJ_APP_CLASS_ALLFLOATS ) ); Unfortunately I have not been able to reproduce the problem you're reporting, and without being able to debug the problem myself I can only guess what might be wrong. BTW, what compiler and OS are you using?
  5. WitchLord

    Auto keyword behavior was changed?

    checked in to revision 2568
  6. WitchLord

    Auto keyword behavior was changed?

    I've identified the problem here. The code path that the compiler took to compile Foo(Resources::GetSValue("")) when GetSValue returned an object was different from when it returned a primitive. In one case the resulting type was a 'Foo@' and the other just 'Foo'. However, instead of just fixing that I reflected a bit more on just what auto is supposed to do, and decided that auto should always prefer declaring the variable as a handle when possible as it is more efficient than as a value. So now, regardless of the right-hand expression being a 'Foo' or 'Foo@' the type of the variable will always become 'Foo@'. Check-in of the fix is still pending. I'll do that as soon as possible (probably in the next 10 hours).
  7. WitchLord

    Operator assignment question

    I suspect the problem is related to how you've registered the operators. You're not using 'const CPoint &in' for the arguments. The fact that you don't use 'const' causes the script compiler to have to make unnecessary copies of the object in order to guarantee that the value is not modified by the called function. Try changing how you register the operators and see if that works. Throw( pEngine->RegisterObjectMethod("CPoint", "CPoint & opAssign(const CPoint & in)", asMETHODPR(CPoint<float>, operator =, (const CPoint<float> &), CPoint<float> &), asCALL_THISCALL) ); Throw( pEngine->RegisterObjectMethod("CPoint", "CPoint opMul ( const CPoint & in )", asMETHODPR(CPoint<float>, operator *, (const CPoint<float> &) const, CPoint<float>), asCALL_THISCALL) ); Of course, if this turns out to be the cause, then there is a bug in the library that I need to fix, because it should work even without the 'const'.
  8. WitchLord

    Try/Catch Support

    I've opted for a quite simple solution. The compiler/VM only has a simple try/catch statement to capture any exception and unwind the stack. The application can then register its own methods for throwing exceptions explicitly and for inspecting caught exceptions. The standard add-on of course come with a couple of pre-implemented solutions that the applications can use if you prefer not to implement your own. Here's the excerpt from the doxygen source for the WIP version: \section try Try-catch blocks <pre> { try { DoSomethingThatMightThrowException(); // This is not executed if an exception was thrown } catch { // This is executed if an exception was thrown } } </pre> A try-catch block can be used if you're executing some code that might throw an exception and you want to catch that exception and continue with the exception rather than just abort the script. \subsection try_func Functions \note The standard <tt>throw</tt> and <tt>getExceptionInfo</tt> are only provided if the application \ref doc_addon_helpers_try "registers them". <b>void throw(const string &in exception)</b> Explicitly throw an exception. The string should identify the type of exception, for logging or treating. <b>string getExceptionInfo()</b> Get the exception string for the last exception thrown. One enhancement over the standard add-on that I can think of is to allow the throw and getExceptionInfo carry a dictionary with further information on the exception, e.g. location, callstack, and perhaps user defined parameters.
  9. WitchLord

    Operator assignment question

    Yes, it should be possible to do what you've done. There can be many different causes for the problem you're facing. The most likely is that something is wrong with how you've registered the CPoint type, but I cannot at this point exclude a possible bug in the library. Can you show how you've registered the CPoint (other than the operators). I need to see the RegisterObjectType, behaviours and also opAssign (if you have registered it). Also, does incPos take the CPoint by value or by reference? Can you show the declaration?
  10. WitchLord

    Crash in argument matching

    I've fixed this in revision 2564
  11. WitchLord

    Template Factory Return Type Bug

    I've fixed this in revision 2563
  12. WitchLord

    Crash on preparing context

    Just noticed you had posted the trace back I asked for (somehow I completely ignored the image). That clearly shows the crash is within Execute, and not in Prepare.
  13. WitchLord

    Crash on preparing context

    The way you registered the function shouldn't cause a crash in ctx->Prepare(), since Prepare doesn't actually call any of the registered functions. Are you sure the crash didn't happen within ctx->Execute()?
  14. WitchLord

    Auto keyword behavior was changed?

    The constructor is returning a handle, but the operation = without @ is a value assignment. In a way it does make sense that 'auto f = ...' is different than 'auto @f = ...' However, it doesn't make sense that the behaviour changes due to the constructor parameter, so there is definitely something wrong here. I haven't had the time to investigate it yet though.
  15. WitchLord

    Crash on preparing context

    There are no apparent errors in the code snippet you posted. With just this information it is not possible to identify the cause of the crash. Can you show the trace back on the stack when the crash happens? Have you tried debugging the code to see if you can identify the cause of the error? Have you made any customizations to the library? What engine configurations are you using?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!