Jump to content

  • Log In with Google      Sign In   
  • Create Account


InvalidPointer

Member Since 04 Apr 2007
Offline Last Active Today, 07:47 AM
***--

Topics I've Started

Feature chat: Type/member annotations

07 November 2013 - 01:52 PM

While the compiler metadata feature has been around for some time, I've really been impressed by how powerful and elegant C#'s type/member annotation feature is. I feel we could cook up something pretty similar for AS using mostly pre-existing features (namely initializer lists and built-in arrays of interfaces) but for best results I really think this needs a solid, 'standards-compliant' official integration.

 

Brainstorming:

 

The actual creation/retrieval of metadata is pretty trivial. You'd probably want to have a basic (application-defined?) metadata interface stored in a built-in array. At a low level, the compiler could stow away anything in the square brackets, then parse the contents as an initializer list for your array. What is interesting is how the process would interact with bytecode precompilation, and specifically serialization. As of right now, there's no official AS object serialization framework, which means we can either A) develop something from scratch, B) create some sort of application interface (promising but obviously fragmenting/error-prone) or C) keep type metadata in plaintext, then parse it on bytecode deserialization.

 

As of right now, my vote goes for B; the differences between application interfaces mean that the loss of direct bytecode portability between AS implementations is essentially a non-issue. This also means that work/code could in theory be shared between the metadata engine and actual game functionalities like networking and/or game saves and thus be tailored to suit the needs of the specific use case(s).

 

Storing the metadata with the property/type is also going to be kind of interesting. I think keeping this as a script object makes the most sense, and I also think keeping the user data as a separate field is valuable. Therefore, I propose adding an extra void* member to store a pointer to the array. The pointer could then be cast as appropriate for use

 

The type would be fixed, and specifically the built-in array type with the subtype set to be references to the application metadata type.

 

Example application metadata type:

interface Annotation {};

Example AS storage type:

Annotation@[]

or alternately

Array<Annotation@>

For convenience, I also propose adding additional methods to asIScriptEngine with the following signatures

asIObjectType* GetMetadataBaseType() const;
asIObjectType* GetMetadataContainerType() const;

It may also be valuable to have different types of annotations for functions, fields and types, but that's what I'd like to interact with the library community on.


Delegates in AngelScript

17 September 2012 - 11:04 AM

Currently thinking about how delegates should work, as I find myself becoming really, really hamstrung without their inclusion in AngelScript. While I think I have some of the implementation worked out, I'm curious what people would want in an implementation and what the syntax should be. From a technical perspective, I think it's best approached at a single-subscriber level, with a delegate storing a function to call and an additional 'this' pointer; multicast delegates/events could be either a library add-on extending the built-in array type or something left to the application interface to provide.

What I'm not sure of, however, is how this should interact with garbage collection (as I understand it, this bites people in the ass with startling frequency in C#, do we need to have a language-level 'weak reference' construct too?) and cross-module function imports. Community, fire away.

Bytecode platform independence

03 December 2011 - 01:23 PM

I went to test my x86 project build the other day and the bytecode loader puked on me (I precompiled the source using a 64-bit tool) and I recall hearing something about there being some platform dependencies in bytecode yet. Twofold queston: 1) Is this still the case, and 2) if it is, where should I start looking to fix this?

C#-style property getters/setters

20 October 2011 - 04:27 PM

Just gauging interest in the concept, though I don't know what percentage of AS users frequent these forums. I've got a (second-generation, actually) implementation going that makes minimal changes to the actual back-end but makes a few enhancements to the parser/builder interfaces that let the compiler infer or generate function signatures on-the-fly. The net result is that you can now use the super-sexy C# property syntax like so:

In interfaces:
int TestProperty
{
	get;
	set;
}

AppInterface@ AltTestProperty
{
	get;
}

float AnotherTestProperty
{
	set;
}

In actual classes and/or global property definitions:
int SomeRandomInteger;

int AGlobalProperty
{
	set
	{
		// You even get the implicit 'value' parameter gratis!
		SomeRandomInteger = value;
	}
	get
	{
		return SomeRandomInteger;
	}
}

while still 'talking' to them via the bog-standard
AGlobalProperty = 50;
in external code. If anyone's interested, give me a holler here, but I'll probably just ship this off to WitchLord as soon as I work out a few parser kinks (for the interested, defining multiple getters/setters within a single property block doesn't fall-through quite as elegantly as I expected, the major result being some odd error messages) but at time of writing this does all compile and work more or less correctly. Next on the agenda is maybe using this to do some cool foreach trick :)

EDIT: I'll probably also make a few syntax tweaks to allow property getters to be optionally const, but I'm still thinking about how I want that to work.

D3D11 StructuredBuffer Ambiguity

11 February 2011 - 01:37 PM

Wow, it's certainly been a while since I've made a thread here, but I digress :)

Has anyone done much work with structured buffers? Specifically, I'm interested in using them as a vehicle for super-fast instancing (think big ol' global buffer of bone transforms) and wanted to know if:

- They have good vertex shader support on D3D10/D3D10.1-class hardware; that is, can I load from them without killing throughput

- I can specify data formats more explicitly app-side-- more to the point, I'd like to be able to use slightly more compact data formats for basic range/size compression and have the GPU upconvert them to 32-bit floats


Unfortunately the official MSDN docs are pretty sparse, to the effect of 'they exist, and are pretty cool with compute shaders.' (Additionally if anyone can refer that to a cleanup crew I think a lot of folks would be pretty happy)

Thoughts, concerns, suggestions? If anyone has personal experience with something else on the mass instancing front that's fine too.

PARTNERS