Jump to content

  • Log In with Google      Sign In   
  • Create Account

Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Yesterday, 02:55 PM

#5230839 Channel information invalidating texture for BMFont

Posted by Andreas Jonsson on 25 May 2015 - 08:16 AM

Everything you've shown so far SEEMS to be correct, the problem is most likely a very specific little detail that we're not seeing.


I've yet to use DX11 so I can't say if the difference that behc mentioned would change anything. In my own code I use DX9 and the BLENDINDICES part of the vertex format uses the type D3DDECLTYPE_UBYTE4. I suppose this would be the same as DXGI_FORMAT_R8G8B8A8_UINT in DC11, but cannot confirm it.


You'll need to do some debugging. Let us know what the value of the channel is when you draw the 'testna' characters.


float4 PS( VS_OUTPUT input) : SV_Target 
   float4 pixel = textureDiffuse0.Sample(textureSampler0, input.Tex); 
   // Are we rendering a colored image, or 
   // a character from only one of the channels 
   if( dot(vector(1,1,1,1), input.channel) )                // input.channel should have the value vector(0,0,1,0) here (assuming ARGB order)
      // Get the pixel value 
      float val = dot(pixel, input.channel);                 // with vector(0,0,1,0) the dot function will return just the value of the green channel
      pixel.rgb = 1; 
      pixel.a = val;                                                     // the value of the green channel will be used for the alpha blending
   return pixel; 


The code I use can be found here (in case you haven't seen it before):


* acgfx_font.cpp (.h)

* acgfx_dynrender.cpp(.h)

#5230747 Channel information invalidating texture for BMFont

Posted by Andreas Jonsson on 24 May 2015 - 06:08 PM

What value are you placing in the vertex' channel argument? It should be a vector with only one of the red, green, blue, or alpha channels set to 1 (or 255). Which channel to set to 1 is given in the .fnt file for the character that you're drawing.


From the first image all characters in the word 'testna' are in the green channel, so you'll want to use the value (0,0,1,0) assuming th order of the channels is (A,R,G,B).

#5229709 Inheriting from application registered class

Posted by Andreas Jonsson on 18 May 2015 - 04:54 PM

Oops. The article in the manual is obviously missing an important piece. I'll have that corrected a.s.a.p.


Anyway, the factory function can for example be implemented like this:


static FooScripted *FooScripted::Factory()
  asIScriptContext *ctx = asGetActiveContext();

  // Get the function that is calling the factory so we can be certain it is the FooScript class
  asIScriptFunction *func = ctx->GetFunction(0);
  if( func->GetObjectType() == 0 || std::string(func->GetObjectType()->GetName()) != "FooScripted" )
    ctx->SetException("Invalid attempt to manually instantiate FooScript_t");
    return 0;

  // Get the this pointer from the calling function
  asIScriptObject *obj = reinterpret_cast<asIScriptObject*>(ctx->GetThisPointer(0));

  return new FooScripted(obj);


The test code available in the svn might help give more clarity too (beware, the code has not really been written as a tutorial so it may be a bit confusing wink.png)

#5221332 QtScript vs AngelScript

Posted by Andreas Jonsson on 04 April 2015 - 09:21 AM

I implemented a special bytecode instruction for calling registered class methods with signature 'type &obj::func(int)' in revision 2147. With this there are almost no runtime decisions that has to be made when making the function call, so the overhead is greatly reduced.


In my tests, a script that accesses array members 20 million times took about 1.2 seconds without this new bytecode instruction, and with it it was reduced to about 0.4 seconds. 


In comparison, the same logic implemented directly in C++, takes about 0.04 seconds. So the script is approximately 10 times slower than C++ now. With the use of a JIT compiler this difference should be reduced even further (though I haven't tried it).




I did experiment with implementing the opIndex call as direct access by inlining the call as bytecode instructions, and the performance was about the same as with the new bytecode instruction. For now I've decided to put this option on hold, as the effort to get it to work is too great compared to the benefits it will have. 

#5215552 Register handle as reference

Posted by Andreas Jonsson on 09 March 2015 - 07:27 PM

I've finally added support for registering class members as references, e.g.


engine->RegisterObjectProperty("type", "complex &cmplx", asOFFSET(type, cmplx));


This is available in revision 2142.




#5214602 Errors produced by classes in namespaces accessing global properties

Posted by Andreas Jonsson on 04 March 2015 - 07:37 PM

I've fixed this in revision 2139.




#5213395 **== and >>>==

Posted by Andreas Jonsson on 27 February 2015 - 03:54 PM

These are compound assignment operators.


A **= B;  means A = A ** B;  (** is power-of or exponent operator)


A >>>= B; means A = A >>> B; (>>> is arithmetic shift right)

#5212836 Virtual property compound assignment on temporary object handle (v2.30.0)

Posted by Andreas Jonsson on 24 February 2015 - 09:06 PM

I've fixed this bug in revision 2137. 

#5212279 AngelScript 2.30.0 is here

Posted by Andreas Jonsson on 22 February 2015 - 09:58 AM

It's been almost exactly 4 months since the last release. This is longest period I've gone without making a new release since this project started back in 2003. This does not mean that development has slowed down though, I merely restrained myself from releasing the code so I could fit more improvements into it. If you take a peek at the change log you'll see that this is by far the largest update too.


As always, when I change the middle version number there are some changes in the interface. The changes are not dramatic, but might require some minor code changes. The most dramatic change in the interface is the removal of the behaviours asBEHAVE_REF_CAST and asBEHAVE_VALUE_CAST (+implicit versions). These behaviours should now be registered as object methods with the names opCast and opConv, respectively. The implementation of the functions in the application doesn't change, just how they are registered with the engine.


I've improved the internal memory management so that less objects will be placed in the garbage collector. This translates into improved performance as less CPU will be required to clean up the dead objects in the GC. The change will perhaps not be too noticeable at runtime, but during recompilation of scripts and engine shutdown you should definitely see a significant improvement.


The script language has gotten some improvements too. The ternary condition operator can now be used as lvalue (as long as both options are lvalues of the same type). Script classes can implement the opCast and opConv operator overloads. Compound assignments can now be used with virtual properties too. Class members can be declared as protected, with the same meaning as in other languages.


There are of course enhancements in the add-ons too, but I'll leave the discovery of those to the reader.




#5211555 @ with handle properies doesn't work

Posted by Andreas Jonsson on 18 February 2015 - 04:18 PM

The bug was still present in 2.30.0 WIP. I've fixed it now in revision 2132.




#5204717 How to get public member variables from script class in AngelScript

Posted by Andreas Jonsson on 16 January 2015 - 09:10 AM

If you need to know which of the members were inherited from a base class, then you need to check if the same member is declared in the parent class too. You can get the parent class with the method asIObjectType::GetBaseType.


If you want to know if the member was declared as public you'll need to check the indicator isPrivate returned from asIObjectType::GetProperty. (Note, in 2.30.0 WIP I've added support for protected members too, so a second indicator isProtected is also available. If neither is true, then the member is public).



You may also want to look into using meta data in the script classes to for example allow the script to inform the editor what values are allowed. The CScriptBuilder add-on shows one way of how meta data can be implemented and collected from scripts, if you wish to use that.

#5204037 inheritance problem in AngelScript

Posted by Andreas Jonsson on 13 January 2015 - 03:26 PM

Yes, it's correct. It works the same way as in C++ and other languages that support polymorphism.

#5198775 Serializing C++ objects with references

Posted by Andreas Jonsson on 17 December 2014 - 09:34 AM

The serializer logic must keep track of which object instances have already been serialized, so that when a reference to the same object is seen from somewhere else it just stores some identifier to that first serialized instance instead of serializing it again.



Using your example, you could serialize it to the following text buffer:


object 0001 type "Foo" value "Yay"

variable "foo" type "Foo@" value ref to 0001

variable "foo2" type "Foo@" value null

object 0002 type "Bar" value ref to 0001

variable "bar" type "Bar@" value ref to 0002

object 0003 type "Bar value ref to 0001

variable "bar2" type "Bar@" value ref to 0003


It's obviously invented syntax, but hopefully you can easily understand that there are 3 object instances (1 Foo, and 2 Bar). Each are identifier with a sequence number. The 4 variables from the original script are serialized by the name and refer to the serialized objects by the sequence number.



De-serializing this into the hot-loaded script would work as following:


1. Create an instance of "Foo" and store in a map with key 0001

2. Skip the variable "foo" since it is no longer present in the script module

3. Skip the variable "foo2" since it is no longer present in the script module

4. Create an instance of "Bar", and populate its member to refer to the instance of "Foo" found in the map with key 0001. The instance is stored in the map with key 0002

5. Set the variable "bar" to refer to the instance of "Bar" stored in the map with key 0002

6. Create an instance of "Bar", and populate its member to refer to the instance of "Foo" found in the map with key 0001. The instance is stored in the map with key 0003

7. Set the variable "bar2" to refer to the instance of "Bar" stored in the map with key 0003



The above shows how it might work if you serialize Foo by storing its content. If instead you only serialize the reference to Foo, then the serializer need to increment the refCount so the object is not destroyed too early, and then release it after you've hot-loaded the script.

#5198171 Casting value objects.

Posted by Andreas Jonsson on 14 December 2014 - 01:27 PM

Polymorphic value types is tricky in a "safe" language like AngelScript. In order to be able to send a value type by reference to a function AngelScript sometimes has to make a copy of the value type in order to guarantee that the reference will stay safe throughout the function call. When this is done on the base type, the data from the derived type is lost in the copy, which is probably why you see the object as empty.


With reference types AngelScript does not have to make the copy of the object, since the lifetime is guaranteed by the existing references, so here it is perfectly OK to use polymorphic types.


asOBJ_REF | asOBJ_NOCOUNT with no factory behaviour is a valid combination. asOBJ_NOCOUNT tells AngelScript that it is not necessary to count the references to the object, since the lifetime of the object is managed by the application. no factory behaviour tells AngelScript that no instances of the type can be created by the scripts, any instances that should be created has to be created by the application.




#5193033 Compiler warnings with latest stable version

Posted by Andreas Jonsson on 15 November 2014 - 05:09 PM

I've fixed the compiler warnings you mentioned in revision 2059.