Add FlxBuffer to hide Vector<Float> as a Array<T>

[Geokureli]

The Problem

Many rendering systems are littered with Array<Float>s meant to be used like so:

rects.push(rect.x);
rects.push(rect.y);
rects.push(rect.width);
rects.push(rect.height);

transforms.push(matrix.a);
transforms.push(matrix.b);
transforms.push(matrix.c);
transforms.push(matrix.d);
transforms.push(matrix.tx);
transforms.push(matrix.ty);

and

for (i in 0...list.length)
{
	final pos = j * 3;
	final charCode = Std.int(list[pos]);
	final x = list[pos + 1];
	final y = list[pos + 2];
	doSomething(charCode, x, y);
}

This can be both hard to read and susceptible to human error compared to using Array<FlxRect>, but not only does the current way greatly reduce objects that need to be garbage collected, many lime/open features specifically require Vector<Float> or Array<Float>, anyway

The Solution

FlxBuffer and FlxBufferArray, under the hood they actually an Array<Float> or Vector<Float>, but when writing code with them, you can easily deal with them as though they were an Array<{x:Float, y:Float}>. Truly the best of both worlds!

The above code, while compiling to nearly identical source code, will look like this:

rects.push(rect);
transforms.push(matrix);

and

for (item in list)
	doSomething(item.charCode, item.x, item.y);

To Do

• [x] Manually verify the compiled js/cpp never instantiates anonymous structs in any of the utilizing code
  • [x] js - source code section
  • [x] cpp - source code section
• [ ] Do benchmark tests, comparing the old code vs the new
  • [ ] Html5
  • [ ] hxcpp
  • [ ] hl
  • [ ] neko
  • [ ] flash
• [ ] Compare general speed of openfl.Vector vs Array
  • [ ] Html5
  • [ ] hxcpp
  • [ ] hl
  • [ ] neko
  • [ ] flash
• [ ] See if there's a way to automatically detect if changes cause items to be instantiated (might not be possible)

[MaybeMaru]

Pretty cool to see updates on this! Just make sure to not use typedefs structures stuff for the final thing since those are pretty slow compiling to dynamic

[Geokureli]

Pretty cool to see updates on this! Just make sure to not use typedefs structures stuff for the final thing since those are pretty slow compiling to dynamic

I don't know what you mean by "pretty slow compiling to dynamic", typedefs compile crazy fast to non-static targets. the goal here is to have seemingly typed arrays/vectors without incurring any garbage collection from instances of the types

I've done some initial tests and no types are actually used as everything is inlined away, see here: https://try.haxe.org/#ADa541d7 the build macro adds 0.091s of compile time, which i think it worth the added readability

But I plan to do actual benchmark tests with these flixel classes, too

[MaybeMaru]

In hxcpp (im not sure about other targets) typedefs compile has annonymous dynamic structures but yeah better to double check with benchmarks.

[Geokureli]

In hxcpp (im not sure about other targets) typedefs compile has annonymous dynamic structures but yeah better to double check with benchmarks.

Again I don't see why we're talking about compiling here, hxcpp takes me almost an hour to build from scratch, already and dynamic targets take an extra 10th of a second

The benchmarks I'm referring to are for runtime performance because I don't see any concern for compile time. It sound like maybe you're actually referring to runtime performance but for some reason keep using the word "compile"

[Geokureli]

@CrowPlexus and @NovaTheFurryDev, you voted thumbs down, care to share your concerns?

[crowplexus]

removing the DV, my biggest concern with this was perhaps it being slower than the current method, I will definitely give this a try later on a blank project to see if it makes a major difference in comparison to the old method

[Geokureli]

removing the DV

What's the DV?

[crowplexus]

removing the DV

What's the DV?

downvote or thumbs down

[SomeGuyWhoLovesCoding]

Is this a performance improvement thing or what?

[Geokureli]

Is this a performance improvement thing or what?

The goal is better readability and less human-error when maintaining or editing, at the hopes of not losing any performance

[SomeGuyWhoLovesCoding]

Is this a performance improvement thing or what?

The goal is better readability and less human-error when maintaining or editing, at the hopes of not losing any performance

I'd recommend switching from typedefs to classes for QuadRectRaw, QuadColorMult, and QuadColorOffset

[Geokureli]

I'd recommend switching from typedefs to classes for QuadRectRaw, QuadColorMult, and QuadColorOffset

the typedefs are never instantiated, they are inlined away at compile time, as you can see in this screenshot of the completed todo item

[SomeGuyWhoLovesCoding]

I tried this pr and the rendering was actually made slower than usual on hl

[Geokureli]

I tried this pr and the rendering was actually made slower than usual on hl

I have no plans to merge this atm, I still need to check a billion things and there's more important things to do, but if perf is worsened it means this will not ever get merged.

Also whenever you talk about performance it's always "i just ran it a bunch of times and it seems slower when I watched it". if you have an actual reproducible benchmark test, then share that, otherwise I'll assume you're just guessing

[Raltyro]

Really want to use this instead of transferring Vectors into Array just for ShaderParameter, etc. I guess it's not happening soon.

[Geokureli]

Really want to use this instead of transferring Vectors into Array just for ShaderParameter, etc. I guess it's not happening soon.

Yeah, it's cool in theory, but isn't panning out