Closed GoogleCodeExporter closed 9 years ago
We also seem to have extraneous "use strict"; lines in the bench as well.
If someone is having a hard time spotting the audio disable/enable setting,
it's at
http://code.google.com/p/octane-benchmark/source/browse/trunk/gbemu.js#10689
Original comment by grantgal...@gmail.com
on 31 Aug 2012 at 7:59
Original comment by octane.t...@gmail.com
on 11 Sep 2012 at 2:58
> I noticed a bunch of core code in the latest github version is different than
what is used in Octane trunk.
> Specifically things like the APU core (A more efficient version has landed
since your copy of it) and XAudioJS
> library are out of date.
We need to stick to the version picked when Octane was made, if we update it,
we would change the score. We might think to update it in the future with a
newer version of Octane, but only if there are advantages from a benchmarking
point of view
> I'm also surprised that the Octane modification to make sure no audio is
generated was done within the
> audio library, rather than by changing the value stored at index 0 of the
settings array to false.
We wanted to make sure that the Resampler.interpolate gets called at least
once, also having audio library makes it easier to add other games.
> I'm also surprised Octane is passing a full dummy canvas object in rather
than having the emulator output
> to a fully hidden canvas.
We already implemented dummy canvas for other benchmarks and it was easier to
reuse it.
> Lastly, I noticed that the bench is said to require typed arrays, while the
official copy of GameBoy-Online
> explicitly does not require typed array support.
Our interpretation of the code was that if TypedArrays are present, they will
be used and there will be a fallback to normal types if not available. This is
not wished at the moment, since we need to know the same code is executed the
whole time, i.e. a test should not have two versions.
But we are reviewing this last point, perhaps we could mark what tests used
typed arrays and what not and allow all tests to fallback when desired.
Original comment by octane.t...@gmail.com
on 12 Sep 2012 at 1:52
I'm worried though that using the audio lib in an unrealistic manner (running
once versus many times over the course of even seconds) might affect the goal
of measuring realistic performance. The emulator was designed for performance
over hours, with no respect to startup time. It was designed for run-time
performance, not compile-time performance.
Original comment by grantgal...@gmail.com
on 21 Sep 2012 at 2:53
Original issue reported on code.google.com by
grantgal...@gmail.com
on 31 Aug 2012 at 7:55