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