| Age | Commit message (Collapse) | Author |
|---|
|
gets mouse focus while going to full screen, so manually force the mouse-is-in-window state
|
|
fullscreen toggle
|
|
set due to referencing a deleted mutex
|
|
palette was requested.
- Previously, the code would query the SDL_HWPALETTE flag, which doesn't always match the requested value.
- This would cause SDL to be restarted on every window resize event, effectively breaking resizing.
|
|
|
|
always requesting SDL_HWPALETTE, it is now only done for 8bp blitters in fullscreen mode.
- This fixes 32bpp blitters on 8bpp X11, which would only render garbage with SDL_HWPALETTE.
- This prevents the colors of other applications from being messed up when running a 8bpp blitter on a 8bpp system.
- When running a 8bpp blitter on an 8bpp system without SDL_HWPALETTE (e.g., in windowed mode), this uses a new shadow surface with color approximation.
- The use of a hardware palette can be forced on and off using -v sdl:hw_palette=1 or -v sdl:hw_palette=0
|
|
methods instead of static functions.
|
|
Eagle_rainbow)
|
|
|
|
from 8bpp -> 32bpp look ugly
|
|
- It seems this event is never triggered when using 1.2 (it has some
autorefresh feature which seems to have been removed in 1.3), but in theory
this event could also trigger on 1.2.
- Note that this fixes redraw issues when compiling against SDL 1.3, but it
still uses the "compatibility" rendering API using SDL_SetVideoMode and
SDL_UpdateRects. Eventually (when 1.3 is stable and released as 2.0), this
should probably be rewritting to use the new Windows and Renderers
available in SDL 1.3.
|
|
against SDL 1.3.
|
|
|
|
draw thread instead of the single threaded bit of the game loop. This causes a speedup of up to 15% when animation is turned on with the 32bpp-anim blitter
|
|
blitter so changes of the palette data during the game don't influence drawing (with SDL)
|
|
dirty variables into a single structure
|
|
cursor more prominently during the initialisation of OpenTTD
|
|
|
|
|
|
|
|
variables to progress.cpp/h
|
|
|
|
it doesn't recompile everything that needs to be recompiled...
|
|
milliseconds per game tick and use it
|
|
missed :)
|
|
|
|
if a header require a header make it include that header
|
|
while starting it
|
|
under high CPU load. Revert as change caused more problems than it fixed.
|
|
was only validated during sprite blitting, other drawing operations didn't check it. Initial startup and window resize could therefore lead to crash.
|
|
the resolution for SDL via the in game menu
|
|
allocated.
|
|
|
|
right button pressed at the same time.
|
|
movement isn't needed anymore because after each even that movement is handled and the counter is reset. As such simply assigning instead of adding works.
|
|
position when scrolling a viewport, warp the mouse pointer to the centre of the window. This gives maximum freedom of movement. The pointer position is restored when the lock is removed. Visually the mouse cursor stays where it was.
|
|
was never joined
|
|
drawing thread failed
|
|
during map generation; disable the threading while generating a map
|
|
asynchronious. Profiling with gprof etc. hasn't shown us that DrawSurfaceToScreen takes a significant amount of CPU; only using TIC/TOC it became apparant that it was a heavy CPU-cycle user or that it was waiting for something.
The benefit of making this function asynchronious ranges from 2%-25% (real time) during fast forward on dual core/hyperthreading-enabled CPUs; 8bpp improvements are, in my test cases, significantly smaller than 32bpp improvements.
On single core non-hyperthreading-enabled CPUs the extra locking/scheduling costs up to 1% extra realtime in fast forward. You can use -v sdl:no_threads to disable threading and undo this loss.
During normal non-fast-forwarded games the benefit/costs are negligable except when the gameloop takes more than about 90% of the time of a tick.
Note that allegro's performance does not improve with this system, likely due to their way of getting data to the video card. It is not implemented for the OS X/Windows video backends, unless (ofcourse) SDL is used there.
Funny is that the performance of the 32bpp(-anim) blitter is, at least in some test cases, significantly faster (more than 10%) than the 8bpp(-optimized) blitter when looking at real time in fast forward on a dual core CPU; it was slower.
The idea comes from a paper/report by Idar Borlaug and Knut Imar Hagen.
|
|
|
|
being too large (and SDL doesn't crash!) fall back to another video driver.
|
|
|
|
-Fix [FS#2864]: autopause and manual pausing conflict with eachother
-Fix: new game + pause on new game + autopause make the game not unpause on the first join
|
|
|
|
|
|
|
|
what 'valid' resolutions we've got
|
|
hooks on SIGSEGV/SIGABRT so one can actually use gdb.
-Change: make it more clear that Allegro's failing to find a driver.
|
|
0-9 keys so people don't get confused that the keypad doesn't work as expected.
|
