Age | Commit message (Collapse) | Author |
|
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.
|
|
During fast-forward, the game was drawing as fast as it could. This
means that the fast-forward was limited also by how fast we could
draw, something that people in general don't expect.
To give an extreme case, if you are fully zoomed out on a busy
map, fast-forward would be mostly limited because of the time it
takes to draw the screen.
By decoupling the draw-tick and game-tick, we can keep the pace
of the draw-tick the same while speeding up the game-tick. To use
the extreme case as example again, if you are fully zoomed out
now, the screen only redraws 33.33 times per second, fast-forwarding
or not. This means fast-forward is much more likely to go at the
same speed, no matter what you are looking at.
|
|
|
|
|
|
|
|
|
|
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
|
|
GUI-less video driver.
|
|
|
|
allocated.
|
|
|
|
|
|
|
|
Dimension instead of uint16[2] for resolutions
|
|
something more than whitespace as description of files that don't have a description.
|
|
|
|
operation' attempt. Previously, only visual clues were available.
-Fix[FS#1519]: When you can not use this resolution at full screen, now you'll know that it failed.
As for the reason it did not work, each computer/OS has its reason.
|
|
|
|
'global' window related types, on that defined 'global' window functions and one that defines functions and types only used by *_gui.cpps.
|
|
null ticks value
|
|
long it should run (-vnull:ticks=10000)
|
|
sound/music/video drivers, using self-registration based on the blitter-model.
|
|
API: blitter
-Codechange: introduced a hierachy of blitters to avoid a lot of code duplication
Note: this allows much easier adding other types of video-drivers, like OpenGL
|
|
code directly accesses the video-buffer
-Add: added NULL blitter and renderer, which are always used for -vnull
-Add: dedicated driver doesn't blit nor render by default. Can be overruled by user. (-D -b 8bpp-optimized)
-Remove: removed CTRL+D from win32, which is incompatible with above
-Add: extended screenshot support for PNG and BMP
-Codechange: remove all hardcoded 8bpp references and replace them with more dynamic ones
-Codechange: minor stuff in blitters
|
|
|
|
|
|
stillunknown and pv2b.
|
|
renamed to .cpp)
|