testing library

A software device set up the way a test wants one, and the two fallback textures every renderer asks for.

import 'package:flutter3d_cpu/testing.dart';

final it = cpuTestDevice(width: 96, height: 72);
final renderer = Renderer.create(
  device: it.device,
  fallbackAlbedo: it.albedo,
  fallbackNormal: it.normal,
);

Fifteen lines that were in eight files: five tests in this package, the frame tests of three applications, and tool/dump_fixture.dart. Always the same device, always the same white albedo and the same flat normal, written out again each time — and a fallback normal typed (128, 128, 255) in seven places is a fallback normal that will be typed (128, 255, 128) in the eighth.

Why it stops where it does

It does not build the Renderer, and that is not laziness. This package must not depend on flutter3d: a backend that could not be compiled without the engine would not be an implementation of an interface, it would be a part of the engine, and no_backend_test.dart in flutter3d_hardware says so for the layer below. So the caller makes the renderer, from three values it no longer has to spell.

Functions

cpuTestDevice({int width = 96, int height = 72}) → ({TextureHandle albedo, CpuDevice device, TextureHandle normal})
A CpuDevice with the builtin shaders, and the fallbacks a renderer needs.
texelOn(CpuDevice device, List<int> rgba) → TextureHandle
A one-pixel texture of rgba, on device.