| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
lithuanian: 5 changes by devbotas
portuguese (brazilian): 8 changes by Greavez
|
|
This because video-drivers might need to make changes to their
context, which for most video-drivers has to be done in the same
thread as the window was created; main thread in our case.
|
|
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.
|
|
|
|
the video buffer.
|
|
|
|
The video drivers using the OpenGL backend are currently our only
accelerated drivers. The options defaults to off for macOS builds and
to on everywhere else.
Co-authored-by: Michael Lutz <michi@icosahedron.de>
|
|
|
|
estonian: 6 changes by siimsoni
catalan: 3 changes by J0anJosep
latvian: 37 changes by lexuslatvia
portuguese (brazilian): 8 changes by Greavez
polish: 1 change by azabost
|
|
|
|
chinese (traditional): 5 changes by benny30111
estonian: 1 change by siimsoni
italian: 1 change by AlphaJack
ukrainian: 4 changes by StepanIvasyn
tamil: 37 changes by Aswn
portuguese (brazilian): 19 changes by Greavez
|
|
swedish: 1 change by kustridaren
spanish (mexican): 4 changes by absay
estonian: 80 changes by siimsoni
arabic (egypt): 13 changes by AviationGamerX
ukrainian: 1 change by StepanIvasyn
dutch: 1 change by Afoklala
portuguese (brazilian): 15 changes by Greavez
|
|
|
|
|
|
Reworked how the screenshot command works while keeping it backwards
compatible. It can now more freely understand arguments, and has
the ability to make SC_DEFAULTZOOM screenshots.
|
|
estonian: 22 changes by siimsoni
korean: 1 change by telk5093
serbian: 41 changes by nkrs
german: 1 change by Wuzzy2
romanian: 14 changes by ALEX11BR
russian: 5 changes by Ln-Wolf
finnish: 5 changes by hpiirai
ukrainian: 2 changes by StepanIvasyn
lithuanian: 105 changes by devbotas
spanish: 3 changes by MontyMontana
french: 5 changes by MalaGaM
portuguese (brazilian): 13 changes by Greavez
|
|
|
|
|
|
|
|
relation (#8801)
In other words, it should only (!) return true if A comes for B.
This promise was broken for the situation where two values are
identical. It would return true in these cases too. This is of
course not possible: if two values are identical, neither come
before the other. As such, the sorter was not imposing strict
weak ordering relations.
libstdc++ handled this scenario just fine, but libc++ crashes
badly on this, as it allowed comparing of [begin, end] instead
of [begin, end).
libc++ considered this not a bug (and by specs, they are correct;
just this way of crashing is of course a bit harsh):
https://bugs.llvm.org/show_bug.cgi?id=47903
|
|
This affected all screenshot types that render to an off-screen
buffer and don't copy the actual screen contents.
|
|
english (us): 4 changes by 2TallTyler
italian: 4 changes by troccoli
serbian: 251 changes by nkrs
german: 6 changes by ebla71, 2 changes by Wuzzy2
romanian: 3 changes by ALEX11BR
russian: 11 changes by Ln-Wolf
ukrainian: 2 changes by StepanIvasyn
lithuanian: 15 changes by devbotas
spanish: 2 changes by perezdidac
|
|
fullscreen.
|
|
fullscreen.
|
|
This is an easy mistake to make, so protect us against making such
mistakes, by validating it doesn't happen.
|
|
So any old game made with this setting was overflowing anyway;
not really a lot we can do about that now.
|
|
|
|
The bootstrap has the _switch_mode to SM_MENU, and never leaves
this mode. Neither is it considered a modal window (while in some
sense it really is). So .. we need to add another "draw anyway"
exception, to make sure bootstrap is being drawn.
|
|
Cause why not
*Update the formating
|
|
|
|
|
|
|
|
|
|
swedish: 4 changes by kustridaren
norwegian (bokmal): 3 changes by buzzCraft
spanish (mexican): 12 changes by absay
korean: 4 changes by telk5093
greek: 85 changes by sntovas
german: 4 changes by MagnumSociety
catalan: 5 changes by J0anJosep
tamil: 16 changes by Ramesh78dev
dutch: 4 changes by rcpaul
polish: 5 changes by pAter-exe
|
|
uint32 + uint32 can overflow, so cast it to uint64 first.
|
|
|
|
storage size (#8769)
|
|
czech: 1 change by LubosKolouch
|
|
|
