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
This change adds an optional function Draw to the Game interface.
With Draw function, the game logic and rendering are separate.
There are some benefits:
* The API is clearer and easier to understand.
* When TPS < FPS, smoother rendering can be performed without
changing the game logic depending on TPS.
* Porting to XNA, which has separate functions Update and Draw,
would be a little easier.
Draw is optional due to backward compatibility. Game interface was
already used before v1.11.x in mobile packages, and adding a
function would break existing code unfortunately. Then, we adopted
switching the behavior based on whether Draw is implemented or not
by type assertions.
IsDrawingSkipped will always return false when Draw is implemented.
Fixes#1104
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
On Windows, executable files must have .exe extension, or
exec.LookPath since exec.LookPath checks %PATHEXT%.
This fixes the issue that ebitenmobile didn't invoke the original
gobind wrapper and then didn't include and compile some Java files.
Fixes#1096
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).
