Define structures in hexadecimal blocks

[MatiDragon-YT]

It's not absolutely necessary, but it improves the readability of scripts.

The idea is to implement valid keywords in hexadecimal blocks that are converted to valid values for the script during compilation.

Of syntax is simple!

Structure(quantity)

Optional parameter, specifies the number of times the representation should be placed.

Structure	Hex string
Int()	00 00 00 00
Float()	00 00 00 00
RGBA()	00 00 00 00
Vec2()	00 00 00 00 00 00 00 00
Vec3()	00 00 00 00 00 00 00 00 00 00 00 00
Quat()	00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Examples

hex
    Int()              //  00 00 00 00
    Int(1)             //  00 00 00 00
    Int(2)             //  00 00 00 00 00 00 00 00
    Int(3)             //  00 00 00 00 00 00 00 00 00 00 00 00
    Int(2) Int(2)      //  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
end

A more practical example..
An advanced particle buffer

hex
//   particle_id  initial_xyz   final_xyz
     Int(10)       Vec3(10)     Vec3(10)

     Float()     //   progress (0.0 .. 1.0)
end

[x87]

Interesting idea, but seems oddly specific in current proposal. I would probably use those keywords to generate valid little-endian values without resorting to hex sequences, e.g. DWORD(0) would produce 00 00 00 00, DWORD(1) would produce (01 00 00 00), FLOAT(1.0) would produce (00 00 80 3F).

In theory, there could be some syntax to create higher-level structs out of basic primitives, to define, e.g. Vec3 as a combo of three floats, and then VEC3(0.0, 1.0, 0.0) would produce 00 00 00 00 00 00 80 3F 00 00 00 00

Adding lots of custom keywords just to substitute 00(size_of_struct) might be unreasonable

[MatiDragon-YT]

You can now write FLOAT and STRING in hexadecimal blocks, or so the Sanny Builder documentation shows.

There is no greater or lesser impact than continuing to write in the traditional way.

hex
  {Vec3} 0.0 5.0 2.5
  Vec3(0.0, 5.0, 2.5)
end

[x87]

You can now write FLOAT and STRING in hexadecimal blocks

Strings yes, floats no

[MatiDragon-YT]

And why not support it? And also allow the keywords above :)

[MiranDMC]

This is generally good idea.
Biggest shortcoming of the hex blocks is lack of simple way to put integer types there.
There is & prefix but it results in bytes count dependent on the provided value. Which makes it useless when defining any kind of structures.
Staying with current hex conventions declaring of two byte number with value of 6 could look like this: &(2)6
However it is far from intuitive notation.

Names WORD, DWORD are bit problematic as these are not used in current syntax at all.

I propose types: int, int8, int16
How to use them in context I have no idea. int(12) will look confusing next to declaration of byte 0 repeated 12 times: 00(12)
Maybe (12: int) then?

hex
    (1: int16) (2: int16) (3: int16)
end

This kind of notation also asks for support of other types SB handles, like ShortString and String \ LongString.

Floats support seems no-brainer as already mentioned:

hex
    {Vec3} 0.0 5.0 2.5
end

[MatiDragon-YT]

The idea stems from a question
"How can buffers that will be used as arrays be created more clearly?"

This is because you cannot include calculations that the compiler will solve, so that it can solve byte structures.

I thought about the syntax "structure(amount)", Because when compiling it, it doesn't matter how hundreds of "00"s are ordered, they are all "00"s.

The size of the hexadecimal blocks does not change. The displacements we make to each region are the same.It only changes the way we declare the blocks.

hex
   Vec3() // It's easier to read.
   0.0 0.0 0.0 // That's understandable...
   00(12) // It's disgusting.
   00 00 00 00 00 00 00 00 00 00 00 00 // It's worst thing in the world
end

[MiranDMC]

hex
   (0.0: float[3])
end

?

[MiranDMC]

This creeps into style of regular variables declaration. Then why not add field names:

hex MyStruct
   (status: int = false) // 00 00 00 00
   (position: float[3] = 0.0) // 3 x 0.0
   (name: longString = "empty") // 16 characters unterminated string
end

There was already idea for sizeof directive. Similar offsetof could be used then to get named fields from named hex blocks.
Uh and that's how we got into structs for SB.

Let's be reliable. There is ton of simpler features already stuck in long queue.
I would not put high hopes into seeing anything beside support of immediate floats in hex blocks.