Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About Dentoid

  • Rank
  1. Dentoid

    Assert when casting undeclared variable

    Quote:Original post by WitchLord The only way things would stop changing is if I stop developing more features. ;) Damn youth of today just needs to have new stuff all the time. In my day, we built our scripting languages out of pine cones and wrote our glue code with birch sap, and we didn't complain! Uhm, I mean, keep it up. ;)
  2. Dentoid

    Assert when casting undeclared variable

    Quote:Original post by WitchLord This was a typo right? There was no version 1.13. ;) Yeah, of course. Sorry. :) Quote:Original post by WitchLord The bug you found was fixed in 2.15.0, so you're just 2 months late. :) Well if stuff didn't keep changing I might update more often! ;) There is a bug in version 2.15.1 that you may want to apply a patch for. The solution for the bug is mentioned here: Script class factories don't work for more than 1 parameters. I've not yet checked in this bug fix in the SVN, but will hopefully be able to do so today.[/quote] I think I've actually manage to avoid using that somehow, so I should be safe. Thanks for the heads up though.
  3. Dentoid

    Assert when casting undeclared variable

    Just upgraded to 2.15.1 and there it works, so forget about it. :)
  4. Dentoid

    Assert when casting undeclared variable

    No problem :) I might add though that it was AS 1.13, so it might be fixed now. I guess I should update.
  5. Hey Just found a little bug in the compiler. If you try to explicitly type cast something that is undeclared, (e.g. "int foo = int(bar);" where "bar" isn't declared), the compiler first (correctly) says "bar" isn't declared, but then asserts at as_compiler.cpp:6891 ("asASSERT(ctx->type.dataType.IsReference());"); It's not really fatal (at least not for me) since it only happens with faulty scripts, but still. :)
  6. Dentoid

    AngelScript 2.14.1 is here

    Quote:Original post by SiCrane I noticed one of the changes is now scripts can define class and interface methods that can return const types. Is there any reason that that wasn't extended to global functions? Isn't the point of const methods that they don't alter the state of their objects, hence only make sense in the scope of an object? EDIT: Sorry, apparantly I didn't read what you wrote. I was thinking about "Script class methods can now be implemented as 'const'".
  7. Dentoid

    It was being too easy

    Hey As you said yourself, I think your problem is that you have C code that calls a script, that calls C code, that calls a script. I.e. 2 levels of script running. In my engine I've solved this problem by having a pool of contexts, so when something wants to call a script it grabs a context from the pool (which if it's empty creates a new context), and when the script has finished the context is returned to the pool. In std-ish pseudocode: Context* getContext() { if( contextPool.size() == 0 ) return new Context(); else return contextPool.pop(); } void releaseContext( Context* context ) { contextPool.push_back( context ); } Hope that helps :)
  8. Dentoid

    Script object property serialization

    Quote:Original post by WitchLord Keep in mind that AngelScript stores all non-primitives on the heap, including members of script objects. The script object member that holds another script object is actually just a reference, and should be handled as such. Do you think you could elaborate a bit more on what's returned from GetPropertyPointer? In the case of primitive members it seems to be just a direct pointer to the data, and in the case of handles it's pointer to a pointer to the data, right? But I haven't really managed to figure out what it points to in the case of non-handle members. (I realize that, as you say, they're actually just references, but... Somehow I can't figure out how it references it. I might just be blind tho. :)) Quote:Original post by WitchLord You'll need to translate the type ids, because there is no guarantee that the type ids will be the same on two different script compilations. If you store the types as script declarations, you can then find the correct type id by asking the engine at load time. Is this also true for types registered in the engine configuration? I mean types exposed from C++? Thanks in advance /Anders
  9. I'm just curious if you could explain if it's possible to serialize the data of script object properties, and if so; how? Primitive objects are easy, and I think I figured out handles, but I'm not sure how to do non-handle members of complex types. What I want to do is make it possible to recompile scripts in my engine without losing too much state. My idea was to scan through the script objects, store their properties (make a copy of the necessary data), recompile, and then write the members that still are available back. Is this at all feasible? Maybe type ids and stuff will go all haywire so there's no way to easily map it back?
  10. Dentoid

    Crash in 2.13.0

    Ah, well this class was just an example when I did a repro. In my real case it's a more complex class. :)
  11. Dentoid

    Crash in 2.13.0

    Hey I think I hit a bug in AS 2.13.0 (or I've registered something wrong). In my real case it's more complex, but I managed to reproduce it like this: 1. Register a very simple class engine->RegisterObjectType( "Test", sizeof(float), asOBJ_VALUE | asOBJ_POD | asOBJ_APP_CLASS_C ); (For testing I just pretend a float is a custom class.) 2. Register an operator for it: engine->RegisterGlobalBehaviour( asBEHAVE_ADD, "Test f(Test &in, Test &in)", asFUNCTION(add), asCALL_CDECL); ("add" is just implemented as a simple add operator for floats) 3. Register a function with 2+ arguments of our type: engine->RegisterGlobalFunction("void doStuff(Test, Test)", asFUNCTION(doStuff), asCALL_CDECL); (This function can to whatever, it'll never enter it anyway. :) 4. Make a simple script function that declares two variables of our class, and runs "doStuff" on it: Test test1, test2; doStuff( test1, test1 + test2 ); // This one will work doStuff( test1 + test2, test1 ); // This one will blow The second one crashes in as_callfunc_x86.cpp:298 memcpy(¶mBuffer[dpos], *(void**)(args+spos), descr->parameterTypes[n].GetSizeInMemoryBytes()); This is where it makes a copy of the argument, but the second argument (the "test1") has already been freed (I've traced it and it's freed, I think somewhere between the argument evaluation and the actual function call, but I'm not totally sure.) I don't know why this is happening and I'm not familiar enough with the compiler to figure it out, but the repro case is fairly easy. Shout if you need any more details. :)
  12. A #define macro is replaced with the value it's define to everywhere it's used at preprocessor time. This means it doesn't really exist anywhere in memory, so AngelScript doesn't have anything to bind to. To be able to bind it as a global, you need it to be in a variable (like "static const int blah = 5" or so). Hope that helps :)
  13. Dentoid

    AngelScript 2.11.2 is here

    Cool stuff! I'm eager to try out the ref-cast, whenever it arrives. It'll simplyfy my scriptcode a lot. :) Keep up the good work!
  14. Dentoid

    Creating "instances" of a script.

    Well, you actually can define classes in script (with members and methods), which you can instantiate either from script or from native code. Is that what you want?
  15. Dentoid

    New YAASB release

    Haven't tried it out, but reading through the readme it seems pretty cool. I like the fact that you use Doxygen, since that unifies things a lot (at least if you're already using Doxygen :) Keep up the good work!
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!