Files
@ r13257:4c5b8120be59
Branch filter:
Location: cpp/openttd-patchpack/source/src/table/track_land.h - annotation
r13257:4c5b8120be59
2.1 KiB
text/x-c
(svn r17776) -Codechange: [SDL] make "update the video card"-process 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.
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.
r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12425:833b231d2630 r9111:983de9c5a848 r8570:8edf335fd1b4 r11891:2527b9ffa6b2 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r11085:c87a330fb4c2 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r11085:c87a330fb4c2 r11085:c87a330fb4c2 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r11085:c87a330fb4c2 r11085:c87a330fb4c2 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r11085:c87a330fb4c2 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r8571:ede148e241b1 r8571:ede148e241b1 r8571:ede148e241b1 r8571:ede148e241b1 r5475:3f5cd13d1b63 r5475:3f5cd13d1b63 r8806:1fc0d9e1c2bf r8806:1fc0d9e1c2bf r8806:1fc0d9e1c2bf r8806:1fc0d9e1c2bf r8806:1fc0d9e1c2bf r8806:1fc0d9e1c2bf r5475:3f5cd13d1b63 r8567:454ccb3e651f r8567:454ccb3e651f r8567:454ccb3e651f | /* $Id$ */
/*
* This file is part of OpenTTD.
* OpenTTD is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
* OpenTTD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with OpenTTD. If not, see <http://www.gnu.org/licenses/>.
*/
/** @file track_land.h Sprites to use and how to display them for train depot tiles. */
#define TILE_SEQ_LINE(img, dx, dy, sx, sy) { dx, dy, 0, sx, sy, 23, {img, PAL_NONE} },
#define TILE_SEQ_END() { (int8)0x80, 0, 0, 0, 0, 0, {0, 0} }
static const DrawTileSeqStruct _depot_gfx_NE[] = {
TILE_SEQ_LINE(SPR_RAIL_DEPOT_NE | (1 << PALETTE_MODIFIER_COLOUR), 2, 13, 13, 1)
TILE_SEQ_END()
};
static const DrawTileSeqStruct _depot_gfx_SE[] = {
TILE_SEQ_LINE(SPR_RAIL_DEPOT_SE_1 | (1 << PALETTE_MODIFIER_COLOUR), 2, 2, 1, 13)
TILE_SEQ_LINE(SPR_RAIL_DEPOT_SE_2 | (1 << PALETTE_MODIFIER_COLOUR), 13, 2, 1, 13)
TILE_SEQ_END()
};
static const DrawTileSeqStruct _depot_gfx_SW[] = {
TILE_SEQ_LINE(SPR_RAIL_DEPOT_SW_1 | (1 << PALETTE_MODIFIER_COLOUR), 2, 2, 13, 1)
TILE_SEQ_LINE(SPR_RAIL_DEPOT_SW_2 | (1 << PALETTE_MODIFIER_COLOUR), 2, 13, 13, 1)
TILE_SEQ_END()
};
static const DrawTileSeqStruct _depot_gfx_NW[] = {
TILE_SEQ_LINE(SPR_RAIL_DEPOT_NW | (1 << PALETTE_MODIFIER_COLOUR), 13, 2, 1, 13)
TILE_SEQ_END()
};
static const DrawTileSprites _depot_gfx_table[] = {
{ {SPR_FLAT_GRASS_TILE, PAL_NONE}, _depot_gfx_NE },
{ {SPR_RAIL_TRACK_Y, PAL_NONE}, _depot_gfx_SE },
{ {SPR_RAIL_TRACK_X, PAL_NONE}, _depot_gfx_SW },
{ {SPR_FLAT_GRASS_TILE, PAL_NONE}, _depot_gfx_NW }
};
static const DrawTileSprites _depot_invisible_gfx_table[] = {
{ {SPR_RAIL_TRACK_X, PAL_NONE}, _depot_gfx_NE },
{ {SPR_RAIL_TRACK_Y, PAL_NONE}, _depot_gfx_SE },
{ {SPR_RAIL_TRACK_X, PAL_NONE}, _depot_gfx_SW },
{ {SPR_RAIL_TRACK_Y, PAL_NONE}, _depot_gfx_NW }
};
#undef TILE_SEQ_LINE
#undef TILE_SEQ_END
|