Question and conversation about Struct types

[Redhacker1]

I am relatively new here, and I don't know much about language design, edge cases, or design decisions. So I apologize for being ignorant. I am just curious and have a use case (maybe not a very valid one in your eyes), so I wanted to get the ball rolling...

I am currently working on exposing my rendering API to AngelScript, and I didn't come up with a satisfying answer for how to expose uniform data to my scripting API. When I was reading, I did come across in the todo list "Data structures," and I think it is likely almost, if not exactly, what I would be using in an ideal world, and you mention you don't know how useful it would be.

I was wondering if that was one of the things that would end up getting put on the "Probably won't ever implement" chopping block.

If it is not, my thoughts are as follows: "Handles can be safely used in the structures." Sounds like it might cause problems in the use cases structs would actually solve, things like "IPC to a native process, explicit layout in serialization, passing to native memory that expects an arbitrary C-compatible POD-esque structure". I feel like structs should only hold other structures and POD types, Script value, and Application value types that don't/minimally interact with the GC, and that reference types aren't all that useful (may need a flag to set this).

Second, standard handles and/or arrays probably should not be valid; my thoughts are, though, that at compile time a value type/struct, maybe denoted as fixed int ty[5] or similar, would be introduced, which would effectively build 5 int types sequentially in memory (with whatever padding rules are in place to mimic the alignment needed) and offer a generated opIndex() method into those types, similar to what is done for properties.

As for inheriting from other structures, I don't see that as being very useful, since everything is public, and honestly, interfaces sound like the bigger loss there; even then, defining functions that take a structure by reference does not sound too unfortunate.

As for lifetime issues, the only place I see it being an issue is if the struct is in a class; perhaps it could always force a copy in a class by value or box it if the caller is not the owning class's method or the class is not in scope? I don't know what you typically do with references to primitives or the like, but perhaps that same idea could be used to get started, even if not optimal?

I bet some of those are a lot of work, and I am not in any way suggesting this is how it should be done; those are my thoughts on some of what was mentioned.

[anjo76]

Can you elaborate on what you mean with "uniform data"? And why you need to expose it as-is to the script?

Yes, support for 'struct' is still on the to-do list. Will it implemented any time soon? Probably not. I just don't have enough arguments to prioritize this over other things that I judge more useful.

For the most part there is just no need to declare structs in the scripts. Why would the scripts care about the exact memory layout of the members? Script languages are usually supposed to hide complexity from the script writer, so perhaps another solution may be better suited.

[Redhacker1]

Sorry, it's been a minute, busy with other things. I would like to be able to allow the user to write their own Shader uniform blocks, or as OpenGL would call them, "Interface Blocks".

Right now, I have a weird opaque native type that you would pass in a structure definition to a factory function and then call this opaque object uniformBlock.Set(vector3df(...), name) or uniformBlock.Set(1.0f, "matrixValue[1][2]") and then it does a bunch of fairly expensive name lookups and resolution to identify where in memory the passed parameter goes, and then a buffer.UpdateBuffer(uniformBlock) call that internally copies the data to the buffer. This would be the "other solution," but it has problems.

This is fine for things that don't change, but tedious and expensive with things that change every frame, like some water parameters. Most current cases I should be able to design around. The other issue is that it introduces more complexity for both the native backend and the script. As the script author, I likely have both a bunch of uniforms in an object describing the material stuff anyway, so having to manually transfer them into another object to pass another function to update the buffer I want to fill with the data is a bit tedious and honestly I would argue more complicated.

It's something I could probably live without, especially since I use AngelScript to prototype, but it seems that a lot of people use custom materials for almost everything in the upstream engine I am modifying, and I would prefer, if at all possible, not to introduce performance regressions if its possible to avoid.

You might ask as to how the other engine handles scripted material uniforms; the engine upstream does not use AngelScript. That is my addition, but it does usually talk directly to the graphics API in a way I can't, since I use neither DX9 nor OpenGL 1.1, and with how everything is set up now, it has to accept arbitrary structure-like values (Interface Blocks are the only supported way of passing uniform data in).