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!


Member Since 27 May 2010
Offline Last Active Private

Topics I've Started

Compiler crash, r1777 -> r1778

03 May 2014 - 03:02 PM



The compiler crashes while trying to access the first element in engine->scriptFunctions which is null in CompileOverloadedDualOperator2() (Windows, x64). I tried a few different versions with relevant changelogs and found that the problem appears when upgrading from r1777 to r1778 (still happens with r1914).
Here's roughly what happens:

 	angelscript.dll!asCString::Compare(const char * str)  Line 291 + 0x23 bytes	C++
 	angelscript.dll!operator==(const asCString & a, const char * b)  Line 340 + 0xf bytes	C++
>	angelscript.dll!asCCompiler::CompileOverloadedDualOperator2(asCScriptNode * node, const char * methodName, asSExprContext * lctx, asSExprContext * rctx, asSExprContext * ctx, bool specificReturn, const asCDataType & returnType)  Line 10781 + 0x1c bytes	C++
 	angelscript.dll!asCCompiler::CompileOverloadedDualOperator(asCScriptNode * node, asSExprContext * lctx, asSExprContext * rctx, asSExprContext * ctx)  Line 10736 + 0x7b bytes	C++
 	angelscript.dll!asCCompiler::CompileInitialization(asCScriptNode * node, asCByteCode * bc, asCDataType & type, asCScriptNode * errNode, int offset, unsigned __int64 * constantValue, int isVarGlobOrMem)  Line 2373 + 0x32 bytes	C++
 	angelscript.dll!asCCompiler::CompileDeclaration(asCScriptNode * decl, asCByteCode * bc)  Line 2110 + 0x46 bytes	C++
 	angelscript.dll!asCCompiler::CompileStatementBlock(asCScriptNode * block, bool ownVariableScope, bool * hasReturn, asCByteCode * bc)  Line 1027	C++
 	angelscript.dll!asCCompiler::CompileFunction(asCBuilder * builder, asCScriptCode * script, asCArray<asCString> & parameterNames, asCScriptNode * func, asCScriptFunction * outFunc, sClassDeclaration * classDecl)  Line 552	C++
 	angelscript.dll!asCBuilder::CompileFunctions()  Line 724	C++
 	angelscript.dll!asCBuilder::Build()  Line 241	C++
 	angelscript.dll!asCModule::Build()  Line 230 + 0xe bytes	C++
(engine->scriptFunctions).array,8	0x0000000003a40100	asCScriptFunction * *
		[0]	0x0000000000000000 {refCount={...} gcFlag=??? engine=??? ...}	asCScriptFunction *
		[1]	0x0000000003c0bec0 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...}	asCScriptFunction *
		[2]	0x0000000003c0bd80 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...}	asCScriptFunction *
		[3]	0x0000000003c0bc40 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...}	asCScriptFunction *
		[4]	0x0000000003c0bb00 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...}	asCScriptFunction *
		[5]	0x0000000003c0b9c0 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...}	asCScriptFunction *
		[6]	0x0000000003c0b880 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...}	asCScriptFunction *
		[7]	0x0000000003c0b740 {refCount={...} gcFlag=false engine=0x0000000003c32040 ...}	asCScriptFunction *
(ot->methods).array,8	0x0000000003c35300	int *
		[0]	0	int
		[1]	103	int
		[2]	104	int
		[3]	105	int
		[4]	106	int
		[5]	107	int
		[6]	108	int
		[7]	109	int

The object that causes it is a vector3 pod with some typical math methods. What's interesting though is that removing the swizzler

template<uint a, uint b, uint c>
PxVec3 Float3Swizzle3F(const PxVec3 *p){
	return PxVec3((*p)[a],(*p)[b],(*p)[c]);

template<uint i>
class Float3Swizzle3{
	static inline void Do(asIScriptEngine *psg){
		char sw[32];
		sprintf(sw,"const float3 get_%c%c%c() const",i/9+0x78,(i/3)%3+0x78,i%3+0x78);
class Float3Swizzle3<0>{
	static inline void Do(asIScriptEngine *psg){
		psg->RegisterObjectMethod("float3","const float3 get_xxx() const",asFUNCTION((Float3Swizzle3F<0,0,0>)),asCALL_CDECL_OBJFIRST);


makes the problem vanish. It's strange because enabling a similar swizzler for vector4 type has no effect (despite the fact that it spams multiple times more methods than the code above). Currently I'm hacking around by putting some null-checks in some places.


I'll be happy to provide more info if needed...


Crash: class and array with initial size

10 March 2013 - 03:59 AM

There seems to be a small problem with arrays and classes when initializing with some initial size...
A bit modified version of TestArrayHandle() made the whole program crash:
class A{
float[] cts(12);

void TestArrayHandle()
A aa;
I'm using the latest version.

Unable to find interface in namespace

16 August 2012 - 07:01 AM

It seems like methods GetInterfaceCount() and GetInterface() are ignoring namespaced interfaces. For example:

//Code pretty much the same code as in the angelscript's game sample
asIObjectType *pt = 0;
bool f = false;
uint otc = pm->GetObjectTypeCount();
for(uint i = 0; i < otc; ++i){
  pt = pm->GetObjectTypeByIndex(i);
  uint ic = pt->GetInterfaceCount();
  for(uint j = 0; j < ic; ++j)
   if(strcmp(pt->GetInterface(j)->GetName(),pintfn) == 0){
	f = true;
  return false;

class SpectatorControl : Base::Control::IComponent{
SpectatorControl(Actor @t){
  @a = t;
Actor @a;
Probably not a feature? Or am I failing it again..?
I also tried nesting these methods in SetDefaultNamespace(), but it didn't make any difference.
Without namespaces the method above works correctly.

for -loop with empty expression not executed

09 April 2012 - 06:52 AM


Just upgraded to the latest revision 1264 and noticed that for(;;) is not executed anymore, is there a reason for this?
Adding an always-true expression (like for(; true;)) seems to be working though. Not a big deal I guess, but I've got for(x;;)'s all over the place Posted Image.

Rendering textured leaves

21 January 2012 - 11:28 AM

I knew I eventually would have a case that lead me here to ask for best practices. I have vegetation meshes that cannot be rendered correctly using sorting and alpha blending, since the leaves are just quads with alpha-enabled textures in a single mesh.

I read about linked list OIT in DX11 (https://graphics.sta...s-10-11-oit.pdf). At first I regarded this as the solution, but then I realized the memory requirements: over 120MB for full hd hdr(?) (and even more if I wanted to render a dense jungle)!! And I'm not sure about the performance either... Some say it's relatively bad.

A workaround: disabling z-writes, causes a lot artifacts, though.
Attached File  render_ndepthw.png   1.56MB   63 downloads

Regular blending. Most of the leaves are are covered by "transparent" triangles. Also, the ssao catches the edges of the quads...
Attached File  render_depthw.png   1.6MB   60 downloads

Any thoughts appreciated...