32bit Windows build is VERY slow

[divVerent]

The loading screen on the 32bit build on a 64bit machine takes very long. The game also lags out for about half a second when touching the Leap of Faith checkpoint.

The main things taking long seem OggVorbis related, and I can not see any suspicious activity in ProcessMonitor.

Issue exists in current build and is unchanged in Ebitengine 2.5.

[divVerent]

Issue reproduces under WINE:

GOARCH=386 GOOS=windows mak && EBITENGINE_GRAPHICS_LIBRARY=opengl /opt/wine-stable/bin/wine aaaaxy.exe

[divVerent]

The fix made things much worse on Android. Reverted for now.

[divVerent]

Now I do not know WHY this commit broke things so badly, as it really should only affect loading - once loaded, sounds are in an in-memory buffer anyway.

[divVerent]

This fix made some sounds decode as 0 samples length, which together with loop_start made playing them VERY expensive.

This in particular affected platform rise and push sounds.

[divVerent]

Loading spends 14.92s in vorbis.imdct and children alone.

Of this, 9.73s in runtime.fadd32.

3.36s in runtime.fpack64.

Meanwhile the 64-bit build has just 0.06s in imdct.

[divVerent]

Wait, that's soft float... WHY?

Seems like if I build with GO386=sse2, this issue goes away. But the docs say that GO386=sse2 is default... wat?

[divVerent]

Apparently Go doesn't support FPU floating point - it's SSE2 or softfloat. I think I'll make the game require SSE2 then, even though most stuff the game itself does is integer (but all rendering uses float).

[divVerent]

$ GOARCH=386 GOOS=windows go env GO386
softfloat

Confirmed.

[divVerent]

That's a Debian patch:

# Always not use sse2. This is important to ensure that the binaries we build
# (both when compiling golang on the buildds and when users cross-compile for
# 386) can actually run on older CPUs (where old means e.g. an AMD Athlon XP
# 2400+). See http://bugs.debian.org/753160 and
# https://code.google.com/p/go/issues/detail?id=8152

I'll undo that.