Integrate for-loops for vertices in some internal packages

[hajimehoshi]

In theory it is possible to integrate for-loops for vertices into one, but this might violate the layer information.

[hajimehoshi]

Example: 4b64ead

[hajimehoshi]

Merge

ebiten/internal/atlas/image.go

Lines 324 to 354 in 5c79178

	if restorable.NeedsRestoring() {
	// If the underlying graphics driver requires restoring from the context lost, the pixel data is
	// needed. An image on an atlas must have its complete pixel data in this case.
	pixels := make([]byte, 4*i.width*i.height)
	for y := 0; y < i.height; y++ {
	for x := 0; x < i.width; x++ {
	r, g, b, a, err := i.at(graphicsDriver, x+paddingSize, y+paddingSize)
	if err != nil {
	return err
	}
	pixels[4*(i.width*y+x)] = r
	pixels[4*(i.width*y+x)+1] = g
	pixels[4*(i.width*y+x)+2] = b
	pixels[4*(i.width*y+x)+3] = a
	}
	}
	newI.replacePixels(pixels, nil)
	} else {
	// If the underlying graphics driver doesn't require restoring from the context lost, just a regular
	// rendering works.
	w, h := float32(i.width), float32(i.height)
	vs := graphics.QuadVertices(0, 0, w, h, 1, 0, 0, 1, 0, 0, 1, 1, 1, 1)
	is := graphics.QuadIndices()
	dr := graphicsdriver.Region{
	X: 0,
	Y: 0,
	Width: w,
	Height: h,
	}
	newI.drawTriangles([graphics.ShaderImageNum]*Image{i}, vs, is, affine.ColorMIdentity{}, graphicsdriver.CompositeModeCopy, graphicsdriver.FilterNearest, graphicsdriver.AddressUnsafe, dr, graphicsdriver.Region{}, [graphics.ShaderImageNum - 1][2]float32{}, nil, nil, false, true)
	}

and

ebiten/internal/graphicscommand/command.go

Lines 231 to 280 in 5c79178

	if graphicsDriver.HasHighPrecisionFloat() {
	n := q.nvertices / graphics.VertexFloatNum
	for i := 0; i < n; i++ {
	s := q.srcSizes[i]
	idx := i * graphics.VertexFloatNum
	// Convert pixels to texels.
	vs[idx+2] /= s.width
	vs[idx+3] /= s.height
	// Avoid the center of the pixel, which is problematic (#929, #1171).
	// Instead, align the vertices with about 1/3 pixels.
	x := vs[idx]
	y := vs[idx+1]
	ix := float32(math.Floor(float64(x)))
	iy := float32(math.Floor(float64(y)))
	fracx := x - ix
	fracy := y - iy
	switch {
	case fracx < 3.0/16.0:
	vs[idx] = ix
	case fracx < 8.0/16.0:
	vs[idx] = ix + 5.0/16.0
	case fracx < 13.0/16.0:
	vs[idx] = ix + 11.0/16.0
	default:
	vs[idx] = ix + 16.0/16.0
	}
	switch {
	case fracy < 3.0/16.0:
	vs[idx+1] = iy
	case fracy < 8.0/16.0:
	vs[idx+1] = iy + 5.0/16.0
	case fracy < 13.0/16.0:
	vs[idx+1] = iy + 11.0/16.0
	default:
	vs[idx+1] = iy + 16.0/16.0
	}
	}
	} else {
	n := q.nvertices / graphics.VertexFloatNum
	for i := 0; i < n; i++ {
	s := q.srcSizes[i]
	// Convert pixels to texels.
	vs[i*graphics.VertexFloatNum+2] /= s.width
	vs[i*graphics.VertexFloatNum+3] /= s.height
	}
	}

[hajimehoshi]

Integrating them to the atlas side might be impossible as the source image (internal) size might be changed before flushing.

EDIT: The source texture size should not be changed until the vertices are used. So this should not be a problem!

[hajimehoshi]

On the other hand, sending the color-scale factors to the graphicscommand package will increase the cost of merging commands... Hmm