Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Jul 2006
Offline Last Active Apr 22 2014 10:35 AM

Topics I've Started

asCModule::Build() now deletes previous scripts before compiling new?

03 May 2012 - 11:31 AM

Hello there,

sorry for consuming your time once again, but I'm stuck at a strange AngelScript behaviour and I need a hint from the original author of this source to solve the issue.

I just upgraded from 2.20.3 to 2.23.1. Upgrading was done be simply copying over the new files, removing the one asm-file that seems to be gone, and adding every new source to the solution. Compiles fine, no apparent interface changes, good thing. But suddenly all but one of my scripts are not executed anymore.

I do the following for hundreds of times:

asIScriptModule::AddScriptSection( "module", someCode);

which worked fine in 2.20.3. Now in 2.23.1 most of my script executions end up with an error "function 'prepare" with 'null'" or something. I stepped through the code for some hours and I finally noticed what I think is the problem. Whenever I call Build(), the InternalReset() function at as_module.cpp:196 destroys all my previously compiled script functions before compiling the new one. I end up with three script modules, each with exactly ONE script function inside. All application-registered types, functions, methods are still there, but all but one script functions compiled at startup are gone. What do I need to do to fix this problem?

Thanks for your time!

Bye, Thomas

Possible bug report: constant to const reference binding

19 September 2011 - 07:54 AM

Hello there,

I registered the following function at an AngelScript engine
 RegisterGlobalFunction( "void DoSomething( const float&)", asFUNCTIONPR( Helper::DoSomething, (const float&), void), AS_CDECL));

which results in an error "Not a valid reference" when I tried to compile the following statement
 DoSomething( 1.0f);

The const float& parameter isn't exactly necessary here, it was just the consequence of a template function specialised to float. After writing a little wrapper to take the parameter by value:
 RegisterGlobalFunction( "void DoSomething( float)", asFUNCTIONPR( Helper::DoSomething, (float), void), AS_CDECL));

the script statement compiles fine. So it seems to me as if AngelScript can't bind number literals to a constant reference. Is this intentional behaviour or an omission? I've solved it for myself now, but it might be useful for others, as well.

Best regards

Bye, Thomas

Global operator * not found in script function

06 July 2011 - 05:47 AM

Hi there,

I recently ported our AngelScript gluecode to a recent version (2.20.3). I've rewritten all classes and operator bindings to adhere to the new principle of named functions. Yet if I try to use operators in a script function, I get an error message.

This is the class in question - a simple vector class of 3 floats

mEngine->RegisterObjectType( "TVektor", sizeof(TVektor), asOBJ_VALUE | asOBJ_APP_CLASS_C);
mEngine->RegisterGlobalFunction( "float opMul(const TVektor &in, const TVektor &in)", asFUNCTIONPR( operator *, (const TVektor &, const TVektor &), float), asCALL_CDECL);
mEngine->RegisterGlobalFunction( "TVektor opMul(float, const TVektor &in)", asFUNCTIONPR( operator *, (float, const TVektor &), TVektor), asCALL_CDECL);
mEngine->RegisterGlobalFunction( "TVektor opMul(const TVektor &in, float)", asFUNCTIONPR( operator *, (const TVektor &, float), TVektor), asCALL_CDECL);

All calls are successful. Now I try to use the operator TVektor * float in a script function:

void DestroyTile_3(uint x, uint y, uint layer, TVektor direction, float damage)
  StartEffect( SomeEffectId, float(x), float(y), 0.0f, direction * damage);

and I get an error upon compilation:

No conversion from 'TVektor&' to math type available.

Any suggestion what I'm doing wrong? According to my understanding, operator * (TVektor, float) should be invoked, but it isn't. Any hint is appreciated.

Bye, Thomas

[DX9] Weird vertex constant register count in caps

10 November 2010 - 02:14 AM

Hello everyone,

I query the D3D9Caps structure to learn how many vertex shader constant registers the current GPU has. This works fine on the reference device (8192), but on my ATI Radeon HD 4870 it just reports 256. Well... isn't DX10-capable hardware supposed to have 16 constant buffers with 4096 float4 registers each? Why do I see 256 there, and not 65k or at least the 4096 of a single constant buffer? Is this a driver bug or is there a hidden constraint I don't know of?

Any hint is greatly appreciated. Background: I perform hardware skinning in a vertex shader. I try to handle as many bones as possible in one go. I query the caps vertex shader constant register count to learn how large I can specify the matrix palette in the vertex shader source before I have to fallback to software skinning. Specifying a larger matrix palette manually only results in compilation failure of the shader.

Bye, Thomas

[D3D9] Compiling and creating resources in parallel threads

18 July 2009 - 05:20 AM

Hey there, I'm in the progress of spreading expensive resource operations over several threads. This basically involves the following operations: Create shaders: D3DXCompileShader() IDirect3DDevice9::CreateVertexShader() IDirect3DDevice9::CreatePixelShader() Create textures: IDirect3DDevice9::CreateTexture() IDirect3DDevice9::CreateCubeTexture() Fill/update textures: IDirect3DTexture9::LockRect() IDirect3DTexture9::UnlockRect() IDirect3DDevice9::UpdateSurface() Create buffers: IDirect3DDevice9::CreateVertexBuffer() IDirect3DDevice9::CreateIndexBuffer() Fill/update buffers: IDirect3DVertexBuffer9::Lock() IDirect3DVertexBuffer9::Unlock() IDirect3DIndexBuffer9::Lock() IDirect3DIndexBuffer9::Unlock() Ok, that's the list. I now tried to find reliable statements about which of those function I'm allowed to call from a different thread than the one doing all the DrawPrimitive() stuff in the meantime. But the DX9 documentation seems to be vague about it. You don't find any threading information at the function's doc pages. The section on D3DCREATE_MULTITHREADED is short and vague, as well. I haven't found proper keywords to feed google with, yet. So if anyone of you has reliable informations on the threading behaviour of the functions mentioned above, please drop me a line. Any hint is greatly appreciated. The D3D device has been created with flag MULTITHREADED, but if you know some details about where it is actually necessary, I'd like to hear those as well :-) Thanks in advance! bye, Thomas