| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2021-04-25 | Fix: [OpenGL] Main loop expects to start with the video buffer unmapped. (#9100) | Michael Lutz | |
| 2021-04-22 | Codechange: [Win32] Try getting an OpenGL 4.5 context first before aiming at ↵ | Michael Lutz | |
| 3.2. | |||
| 2021-04-21 | Fix: [OpenGL] Check maximum supported texture size against screen resolution. | Michael Lutz | |
| 2021-04-11 | Fix: Check for a validly mapped OpenGL screen buffer during driver init. (#9007) | Michael Lutz | |
| 2021-04-11 | Feature: allow a toggle to enable/disable vsync | Patric Stout | |
| 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. | |||
| 2021-04-10 | Fix: Data races on cursor state in OpenGL backends | Jonathan G Rennison | |
| 2021-04-09 | Fix #8930: [Win32] Don't handle printable keys on keydown if an edit box is ↵ | Michael Lutz | |
| 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. | |||
| 2021-04-07 | Fix #8713: Change OTTD2FS and FS2OTTD to return string objects instead of ↵ | Niels Martin Hansen | |
| static buffers | |||
| 2021-03-20 | Fix #8871: [OpenGL] Initialize all buffers after resize and clear back ↵ | Michael Lutz | |
| buffer. (#8877) | |||
| 2021-03-09 | Add: Display refresh rate game option (#8813) | sean | |
| 2021-03-08 | Add: [Video] move GameLoop into its own thread | Patric Stout | |
| 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. | |||
| 2021-03-08 | Codechange: don't set the window position when changing blitter | Michael Lutz | |
| There really is no need to make an extra call to the OS in these cases. | |||
| 2021-03-08 | Remove: [Video] no longer draw in a thread | Patric Stout | |
| 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. | |||
| 2021-03-08 | Fix #8784: using alt+enter didn't update the fullscreen toggle visibly (#8820) | Patric Stout | |
| Basically, the window was not invalidated, so it was never redrawn. This made it look like it wasn't working, but it really was. | |||
| 2021-03-01 | Fix #8775: [Win32] Don't create the main window when alt-tabbing back into ↵ | Michael Lutz | |
| fullscreen. | |||
| 2021-03-01 | Fix: [Win32] Original window size was lost when tabbing in and out of ↵ | Michael Lutz | |
| fullscreen. | |||
| 2021-02-28 | Add: settings to limit your fast-forward game speed | Patric Stout | |
| By default this setting is set to 2500% normal game speed. | |||
| 2021-02-25 | Codechange: [OpenGL] Load all OpenGL functions dynamically. | Michael Lutz | |
| 2021-02-24 | Codechange: [Video] move InteractiveRandom() to the VideoDriver | Patric Stout | |
| 2021-02-24 | Codechange: [Video] make the prototype of PollEvent() the same for all drivers | Patric Stout | |
| Additionally, call it from the draw-tick. | |||
| 2021-02-23 | Codechange: Switch to explicit wide strings | Niels Martin Hansen | |
| 2021-02-23 | Remove: [Win32] Last pretenses of being able to build for Windows 95 | Niels Martin Hansen | |
| 2021-02-22 | Fix 8706c36f: Change RELEASE code, too. | Michael Lutz | |
| 2021-02-22 | Add: [OpenGL] Support for a separate animation buffer that stores the ↵ | Michael Lutz | |
| palette values of the screen in addition to the colour buffer. | |||
| 2021-02-22 | Add: [OpenGL] Accelerated mouse cursor drawing. | Michael Lutz | |
| 2021-02-22 | Codechange: [Win32] Use an OpenGL core context instead of a compatibility one. | Michael Lutz | |
| 2021-02-22 | Add: [OpenGL] Support for 8bpp blitters. | Michael Lutz | |
| 2021-02-22 | Change: [Win32] Disable VSync for OpenGL by default. | Michael Lutz | |
| 2021-02-22 | Codechange: [Win32] Try to get an OpenGL 3.2+ context if possible. | Michael Lutz | |
| 2021-02-22 | Codechange: [OpenGL] Use a pixel buffer object to store the video buffer. | Michael Lutz | |
| 2021-02-22 | Codechange: [Win32] Move remaing global _wnd variables into the video driver. | Michael Lutz | |
| 2021-02-22 | Change: Lock the video buffer when drawing inside the game loop to properly ↵ | Michael Lutz | |
| account for threaded drawing. | |||
| 2021-02-22 | Codechange: [Win32] Move the global video buffer pointer into the driver class. | Michael Lutz | |
| 2021-02-22 | Codechange: [OpenGL] Only update the dirty parts of the video buffer texture. | Michael Lutz | |
| 2021-02-22 | Codechange: [OpenGL] Use new-style extension testing introduced with OpenGL 3.0. | Michael Lutz | |
| 2021-02-22 | Add: [Win32] Video driver that uses OpenGL to transfer the video buffer to ↵ | Michael Lutz | |
| the screen. | |||
| 2021-02-22 | Codechange: [Win32] Move common initialization and finalization to the video ↵ | Michael Lutz | |
| driver base class. | |||
| 2021-02-22 | Codechange: [Win32] Move GDI-specific variables and related functions into ↵ | Michael Lutz | |
| the GDI video driver class. | |||
| 2021-02-22 | Codechange: [Win32] Move GDI specific drawing code into the GDI video driver ↵ | Michael Lutz | |
| class. | |||
| 2021-02-22 | Codechange: [Win32] Split the video driver into a base class and a GDI ↵ | Michael Lutz | |
| backend class. | |||
| 2021-02-22 | Fix #6319: [Win32] don't use clipping; draw whole screen every frame (#8726) | Patric Stout | |
| 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-20 | Codechange: Use C++-ism for zeroing. | Michael Lutz | |
| 2021-02-20 | Codechange: deduplicate tick-handlers of all video drivers | Patric Stout | |
| They were all identical, so better put this in a single place hoping it is less likely to break. | |||
| 2021-02-20 | Change: [Win32] Remove force_full_redraw and display_hz settings | Patric Stout | |
| 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. | |||
| 2021-02-20 | Codechange: [Win32] simplify when/where GdiFlush() is called | Patric Stout | |
| 2021-02-20 | Codechange: be consistent in what CheckPaletteAnim() does and when it is called | Patric Stout | |
| Additionally, make sure this is a class method. Later commits will make use of this. | |||
| 2021-02-20 | Codechange: be consistent in naming the paint function Paint() | Patric Stout | |
| Also move this function to be a class member. This to allow further deduplicating of code in a later commit. | |||
| 2021-02-20 | Codechange: use (Un)LockVideoBuffer() to manage video buffer | Patric Stout | |
| 2021-02-20 | Codechange: move all input-handling of video-drivers into InputLoop | Patric Stout | |
| 2021-02-20 | Codechange: [Win32] make fast-forward check the same as with other drivers | Patric Stout | |
| It was of all the drivers the only one doing this slightly different. When trying to unify more code, that was rather annoying. | |||
 |
index : Erich/openttd | |
| Unnamed repository; edit this file 'description' to name the repository. |
| summaryrefslogtreecommitdiff |