Age | Commit message (Collapse) | Author |
|
|
|
Vsync should be off by default, as for most players it will be
better to play without vsync. Exception exist, mainly people who
play in fullscreen mode.
|
|
|
|
in focus.
Handle printable input only when the matching WM_CHAR message is incoming.
Without an edit box, do the handling in keydown as usual to support hotkeys.
|
|
static buffers
|
|
buffer. (#8877)
|
|
|
|
This allows drawing to happen while the GameLoop is doing an
iteration too.
Sadly, not much drawing currently can be done while the GameLoop
is running, as for example PollEvent() or UpdateWindows() can
influence the game-state. As such, they first need to acquire a
lock on the game-state before they can be called.
Currently, the main advantage is the time spend in Paint(), which
for non-OpenGL drivers can be a few milliseconds. For OpenGL this
is more like 0.05 milliseconds; in these instances this change
doesn't add any benefits for now.
This is an alternative to the former "draw-thread", which moved
the drawing in a thread for some OSes. It has similar performance
gain as this does, although this implementation allows for more
finer control over what suffers when the GameLoop takes too
long: drawing or the next GameLoop. For now they both suffer
equally.
|
|
There really is no need to make an extra call to the OS in
these cases.
|
|
Drawing in a thread is a bit odd, and often leads to surprising
issues. For example, OpenGL would only allow it if you move the
full context to the thread. Which is not always easily done on
all OSes.
In general, the advise is to handle system events and drawing
from the main thread, and do everything else in other threads.
So, let's be more like other games.
Additionally, putting the drawing routine in a thread was only
done for a few targets.
Upcoming commit will move the GameLoop in a thread, which will
work for all targets.
|
|
Basically, the window was not invalidated, so it was never redrawn.
This made it look like it wasn't working, but it really was.
|
|
fullscreen.
|
|
fullscreen.
|
|
By default this setting is set to 2500% normal game speed.
|
|
|
|
|
|
Additionally, call it from the draw-tick.
|
|
|
|
|
|
|
|
palette values of the screen in addition to the colour buffer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
account for threaded drawing.
|
|
|
|
|
|
|
|
the screen.
|
|
driver base class.
|
|
the GDI video driver class.
|
|
class.
|
|
backend class.
|
|
When we clip the region that is only been redrawn, something
weird happens on Windows. When pushing 60 frames per second on a
60Hz monitor, it appears that the clipped region is often shown
of another frame, instead of the current.
Examples of this are:
- pause the game, move your mouse to the left, and at the right
speed it totally disappears.
- fast aircrafts seem to be in several places at once, weirdly
lagging behind.
- in title screen, moving your mouse gives you the idea it is
jumping places, instead of smooth movements.
In the end, if you do nothing, everything is correct, so it is
eventually consistent. Just when we are firing many BitBlt in
a clipped region, the in-between is not.
What goes wrong exactly, I honestly do not know. On every frame
that we push to the DC is a mouse painted, but visually it
sometimes appears like it is not. Recording with external software
shows it really is there.
It is also not our eyes playing tricks on us, as the first example
makes it really clear the mouse pointer really is not painted.
And to be clear, with the mouse this is easiest reproduceable,
as high-speed objects are influences by this most. But this happens
for all movement that redraws small regions.
Either way, not using clipped regions resolves the issue completely,
and there appears to be little to no penalty (I failed to measure
any impact of drawing the full screen). So better have a good game
than fast code, I guess?
|
|
|
|
They were all identical, so better put this in a single place
hoping it is less likely to break.
|
|
These were special settings only for the win32-drivers, and
introduced in the very first version we track.
Time kinda had caught up with those variables, so it is time to
say farewell.
force_full_redraw was most likely a debug functionality "in case
our dirty-rect fails". This should no longer be needed.
display_hz was cute, as it had a max of 120. That is kinda
out-dated information, but I also doubt anyone was really using
this.
|
|
|
|
Additionally, make sure this is a class method. Later commits
will make use of this.
|
|
Also move this function to be a class member. This to allow
further deduplicating of code in a later commit.
|
|
|
|
|
|
It was of all the drivers the only one doing this slightly different.
When trying to unify more code, that was rather annoying.
|
|
Win32 was the only video driver doing this. It is just a bit too
much random.
|
|
WM_PAINT hits when-ever Windows feels like, but always after we
marked the screen as dirty. In result, it was lagging behind,
giving a sub-60fps experience.
With the new draw-tick there is no longer a need to be driven by
WM_PAINT, so it is better anyway to drive the drawing ourself. As
an added bonus this makes the win32 driver more like the others.
|
|
shouldn't be closed yet
The higher your refresh-rate, the more likely this is. Mostly you
notice this when creating a new game or when abandoning a game.
This is a bit of a hack to keep the old behaviour, as before this
patch the game was already freezing your mouse while it was changing
game-mode, and it does this too after this patch. Just now it
freezes too a few frames earlier, to prevent not drawing windows
people still expect to see.
|