Especially in the initial phase before calling Run/RunGame, the
window position is not reliable and then getting the device scale
factor does not make sense based on the window position. Avoid
using the window position, and instead use the glfw.Monitor in
this situation.
Revert "uidriver/glfw: Bug fix: compile error on Linux"
This reverts commit 0a5126f776.
This reverts commit 3e244d7a7c.
Reason: GetMonitor is available only on fullscreen mode
On Windows, the window could be maximized even when the window was
not resizable. This behavior is confusing. Forbid it so that the
behavior will be clearer.
Especially in the initial phase before calling Run/RunGame, the
window position is not reliable and then getting the device scale
factor does not make sense based on the window position. Avoid
using the window position, and instead use the glfw.Monitor.
This change changes the behavior of WindowPosition /
SetWindowPosition. The window position is now a relative position
and the origin position is the left-upper of the current monitor.
Fixes#1115
Now a window can be floating with SetWindowFloating, the functions
that have suffix 'IsBackground' seems misleading. However, we
cannot rename them due to backward compatibility. Then, let's add
aliases and revisit them when updating the major version of Ebiten.
Fixes#1102
This simple change brings my simple test project from 752 allocations per frame to 474 allocations per frame. It seems a shame that go's escape analysis is not smart enough to leave this variable on the stack.
GeoM is a 24-byte struct and there is a slight perf difference that we are storing it in stack, but also copying it around with this change (instead of an 8-byte pointer). This could make things faster (due to stack / CPU cache) or slower (due to copying more memory) - when I try a stress test (drawing 100K images per frame), I can't see any actual performance difference (but I do see 100K fewer allocations, and GC is no longer running almost all the time).
I've been doing some profiling of a very simple ebiten project, and noticed that thread.go was doing a bunch of unnecessary allocations to accomplish its work. This change seeks to reduce GC work.
Input.go was also doing some unnecessary allocations.
The thread.go change reduces the total number of allocations per frame from 1342 to 852 (~36% reduction). The input.go change reduces it further to 752 (~44% total reduction). Perf tests were done on windows.
This means that the whole offscreen is cleared correctly.
This change is a little breaking change: SetScreenSize or other
functions no longer works on ebitenmobile. Use Layout instead.
Fixes#1019
After the game loop is finished, any goroutines should not exist.
Otherwise, 'Go program has already exited' error can happen on
Wasm.
This change ensures that the goroutines are finished when the game
is finished. Note that time.Sleep was required to ensure that the
(*time.Ticker) ends.
Fixes#1027
This adds hooks on resuming/suspending the application, and
switches the foreground state there. This change also updates
the logic to suspend the game loop to be clearer.
Fixes#1037
Unfotunately, PBO might slow Android applications expecially when
coming back from context lost. Ebiten sends a lot of draw calls to
replace pixels in such case.
Until we find a good solution, let's not use PBO on Android.
Fixes#988
Now grpahicscommand saves the error and shows the error after a
while. This was good to simplify the API but was the cause to hide
some issues.
This change fixes all the errors to be returned immediately, and
buffer this in the ebiten package instead.
Fixes#971
Gamepad GUID is a SDL specific notion and, strictly speaking,
they are not GUID (UUID) since they don't follow UUID's
specifications.
Renaming the function makes the situation clearer.
Updates #1048
Mipmap calculation must be executed after the main loop starts
because the graphics driver's HasHighPrecisionFloat is needed.
Then, operations on mipmap images must be called from images in
buffered package.
Updates #1044
