c409f45ddd
Codechange: [Video] make the prototype of PollEvent() the same for all drivers
...
Additionally, call it from the draw-tick.
2021-02-24 21:58:47 +01:00
b427ddce88
Codechange: Switch to explicit wide strings
2021-02-23 11:25:39 +01:00
beeb9e0a1b
Remove: [Win32] Last pretenses of being able to build for Windows 95
2021-02-23 11:25:39 +01:00
06ca147a82
Fix 8706c36f: Change RELEASE code, too.
2021-02-22 23:16:46 +01:00
7af1fd3ffb
Add: [OSX] OpenGL video driver.
2021-02-22 22:16:07 +01:00
b4a3bc1ffe
Codechange: [OpenGL] Separate context state setup from general init.
2021-02-22 22:16:07 +01:00
7f55f0a264
Codechange: [OSX] Add support for (un)locking the video buffer.
2021-02-22 22:16:07 +01:00
2f25e9bdf8
Codechange: [OSX] Separate video driver into a base and a Quartz implementation.
2021-02-22 22:16:07 +01:00
421b599541
Codechange: [SDL2] Split driver in base-part and default backend
2021-02-22 22:16:07 +01:00
a303940372
Feature: [SDL2] OpenGL support
2021-02-22 22:16:07 +01:00
a77b202767
Codechange: [SDL] Move dirty_rect to class scope.
2021-02-22 22:16:07 +01:00
e75858ce5e
Codechange: [SDL2] Allow several places to hook into the SDL driver
...
This allows future subdrivers to use these to manage their
own flow.
2021-02-22 22:16:07 +01:00
101e394475
Codechange: [SDL2] Move functions and variables to class-scope
...
This allows future subdrivers to override them.
2021-02-22 22:16:07 +01:00
0d58bc9384
Codechange: [SDL2] Move SDLSurface code to its own function
...
This increases readability, and allow future subdrivers to not
use SDLSurface to draw.
2021-02-22 22:16:07 +01:00
6098811b49
Codechange: [SDL2] Split Start() in a few more functions
...
This makes it a bit easier to follow what is going on, and
allow future subdrivers to hook into a few of these functions.
Reworked the code slighly while at it, to return early where
possible.
2021-02-22 22:16:07 +01:00
86c309ea75
Codechange: [OpenGL] Let OpenGL clear the pixel buffer if possible.
2021-02-22 22:16:07 +01:00
ae7c63cc35
Codechange: [OpenGL] Use persistently mapped pixel buffers when supported.
2021-02-22 22:16:07 +01:00
200be7d20c
Add: [OpenGL] Support for a separate animation buffer that stores the palette values of the screen in addition to the colour buffer.
2021-02-22 22:16:07 +01:00
d62e302768
Change: [Win32] Prioritize the OpenGL video driver over the GDI one.
2021-02-22 22:16:07 +01:00
6bcc4884c2
Add: [OpenGL] Accelerated mouse cursor drawing.
2021-02-22 22:16:07 +01:00
bcd15b4dd2
Codechange: [OpenGL] Initialize backing store to opaque alpha to allow blending effects.
2021-02-22 22:16:07 +01:00
3e49aff35c
Codechange: Allow video drivers to handle the cursor themselves.
2021-02-22 22:16:07 +01:00
f94b2e73e1
Codechange: [Win32] Use an OpenGL core context instead of a compatibility one.
2021-02-22 22:16:07 +01:00
e8fc050b6e
Add: [OpenGL] Support for 8bpp blitters.
2021-02-22 22:16:07 +01:00
320072c8dc
Codechange: [OpenGL] Explicitly assign which framebuffer target receives the colour values.
2021-02-22 22:16:07 +01:00
821f30f735
Codechange: [OpenGL] Use GLSL version 1.50 if available.
2021-02-22 22:16:07 +01:00
90fd8f8cda
Codechange: [OpenGL] Use generic vertex attributes in the shader program.
2021-02-22 22:16:07 +01:00
acf59f6b68
Codechange: [OpenGL] Use shaders to display the video buffer on screen.
2021-02-22 22:16:07 +01:00
b181859629
Change: [Win32] Disable VSync for OpenGL by default.
2021-02-22 22:16:07 +01:00
9a069faa01
Codechange: [Win32] Try to get an OpenGL 3.2+ context if possible.
2021-02-22 22:16:07 +01:00
a990c497b5
Codechange: [OpenGL] Use a pixel buffer object to store the video buffer.
2021-02-22 22:16:07 +01:00
5af0cfd902
Codechange: [OpenGL] Use a vertex array object to store the vertex state for the video buffer.
2021-02-22 22:16:07 +01:00
acf2ce35f7
Codechange: [OpenGL] Use a vertex buffer object to store the vertex data for the video buffer.
2021-02-22 22:16:07 +01:00
8706c36fc0
Codechange: [Win32] Move remaing global _wnd variables into the video driver.
2021-02-22 22:16:07 +01:00
d6b6775888
Change: Lock the video buffer when drawing inside the game loop to properly account for threaded drawing.
2021-02-22 22:16:07 +01:00
73ed748deb
Codechange: [Win32] Move the global video buffer pointer into the driver class.
2021-02-22 22:16:07 +01:00
5ad545dcc1
Codechange: [OpenGL] Only update the dirty parts of the video buffer texture.
2021-02-22 22:16:07 +01:00
3a77ade6b2
Codechange: [OpenGL] Enable driver debug messages if supported.
2021-02-22 22:16:07 +01:00
d7b96a424f
Codechange: [OpenGL] Use new-style extension testing introduced with OpenGL 3.0.
2021-02-22 22:16:07 +01:00
ef478ade64
Add: [Win32] Video driver that uses OpenGL to transfer the video buffer to the screen.
2021-02-22 22:16:07 +01:00
af4d32357c
Codechange: [Win32] Move common initialization and finalization to the video driver base class.
2021-02-22 22:16:07 +01:00
78b8fc3e4f
Codechange: [Win32] Move GDI-specific variables and related functions into the GDI video driver class.
2021-02-22 22:16:07 +01:00
8b90d4abe0
Codechange: [Win32] Move GDI specific drawing code into the GDI video driver class.
2021-02-22 22:16:07 +01:00
59e0d9618b
Codechange: [Win32] Split the video driver into a base class and a GDI backend class.
2021-02-22 22:16:07 +01:00
78d96dad2a
Fix #6319 : [Win32] don't use clipping; draw whole screen every frame ( #8726 )
...
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?
2021-02-22 21:17:55 +01:00
88959f5595
Codechange: [OSX] remove final bits of old debugging code ( #8714 )
2021-02-21 15:58:26 +01:00
e1b1608dc6
Fix ec1dd0bf: missing override causing compiler warnings ( #8708 )
2021-02-20 22:14:26 +01:00
d16dc22fdf
Codechange: Use C++-ism for zeroing.
2021-02-20 21:14:44 +01:00
5ca979b1e2
Fix: [OSX] Don't wait on the event loop for drawing.
2021-02-20 21:14:44 +01:00
f3c192c63d
Codechange: [OSX] Only keep a total dirty rect for drawing.
...
When drawing an 8bpp screen buffer, palette resolving was done for each
dirty rectangle. In areas with high activity, this would mean a pixel might
have been resolved multiple times. Also, if too many individual updates
were queued, the whole screen would be refreshed, even if unnecessary.
All other drivers only keep one overall dirty rect, so do it here as well.
2021-02-20 21:14:44 +01:00
Patric Stout