Files
@ r13257:4c5b8120be59
Branch filter:
Location: cpp/openttd-patchpack/source/src/landscape.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.
r6343:4d2d12eee7b9 r6343:4d2d12eee7b9 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r9111:983de9c5a848 r6343:4d2d12eee7b9 r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r8121:d05602c69734 r8138:f851b4cbdad1 r8138:f851b4cbdad1 r8138:f851b4cbdad1 r8119:8fdb3a371896 r6343:4d2d12eee7b9 r10260:88d82a40120c r10260:88d82a40120c r6343:4d2d12eee7b9 r6343:4d2d12eee7b9 r10260:88d82a40120c r10260:88d82a40120c r6343:4d2d12eee7b9 r10260:88d82a40120c r10260:88d82a40120c r11206:4cc3157af9d3 r6343:4d2d12eee7b9 r6343:4d2d12eee7b9 r11962:0e3a6981e508 r6343:4d2d12eee7b9 r11962:0e3a6981e508 r11962:0e3a6981e508 r11962:0e3a6981e508 r11962:0e3a6981e508 r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r7728:ec77c9b03910 r7770:09918df1f6fd r10647:62911ec68e89 r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r7335:93bf5f4b6ce4 r7335:93bf5f4b6ce4 r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a r6453:b0b56773284a | /* $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 landscape.h Functions related to OTTD's landscape. */
#ifndef LANDSCAPE_H
#define LANDSCAPE_H
#include "core/geometry_type.hpp"
#include "tile_cmd.h"
#include "slope_type.h"
#include "direction_type.h"
enum {
SNOW_LINE_MONTHS = 12, ///< Number of months in the snow line table.
SNOW_LINE_DAYS = 32, ///< Number of days in each month in the snow line table.
};
/** Structure describing the height of the snow line each day of the year
* @ingroup SnowLineGroup */
struct SnowLine {
byte table[SNOW_LINE_MONTHS][SNOW_LINE_DAYS]; ///< Height of the snow line each day of the year
byte highest_value; ///< Highest snow line of the year
byte lowest_value; ///< Lowest snow line of the year
};
bool IsSnowLineSet();
void SetSnowLine(byte table[SNOW_LINE_MONTHS][SNOW_LINE_DAYS]);
byte GetSnowLine();
byte HighestSnowLine();
byte LowestSnowLine();
void ClearSnowLine();
uint GetPartialZ(int x, int y, Slope corners);
uint GetSlopeZ(int x, int y);
void GetSlopeZOnEdge(Slope tileh, DiagDirection edge, int *z1, int *z2);
int GetSlopeZInCorner(Slope tileh, Corner corner);
Slope GetFoundationSlope(TileIndex tile, uint *z);
static inline Point RemapCoords(int x, int y, int z)
{
Point pt;
pt.x = (y - x) * 2;
pt.y = y + x - z;
return pt;
}
static inline Point RemapCoords2(int x, int y)
{
return RemapCoords(x, y, GetSlopeZ(x, y));
}
uint ApplyFoundationToSlope(Foundation f, Slope *s);
void DrawFoundation(TileInfo *ti, Foundation f);
void DoClearSquare(TileIndex tile);
void RunTileLoop();
void InitializeLandscape();
void GenerateLandscape(byte mode);
#endif /* LANDSCAPE_H */
|