Files
@ r13257:4c5b8120be59
Branch filter:
Location: cpp/openttd-patchpack/source/src/core/geometry_type.hpp - annotation
r13257:4c5b8120be59
1.5 KiB
text/x-c++hdr
(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.
r8121:d05602c69734 r8121:d05602c69734 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r12768:980ae0491352 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8126:f5c3fc8ba0ab r8126:f5c3fc8ba0ab r8126:f5c3fc8ba0ab r8126:f5c3fc8ba0ab r8126:f5c3fc8ba0ab r8127:686810306867 r8127:686810306867 r8127:686810306867 r8127:686810306867 r8127:686810306867 r8127:686810306867 r8127:686810306867 r9077:eab62512cbb4 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r9077:eab62512cbb4 r8121:d05602c69734 r12252:2f455828d620 r12252:2f455828d620 r8121:d05602c69734 r8121:d05602c69734 r9077:eab62512cbb4 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r9077:eab62512cbb4 r9077:eab62512cbb4 r9077:eab62512cbb4 r9077:eab62512cbb4 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r9077:eab62512cbb4 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 r8121:d05602c69734 | /* $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 geometry_type.hpp All geometry types in OpenTTD. */
#ifndef GEOMETRY_TYPE_HPP
#define GEOMETRY_TYPE_HPP
#if defined(__AMIGA__)
/* AmigaOS already has a Point declared */
#define Point OTTD_Point
#endif /* __AMIGA__ */
#if defined(__APPLE__)
/* Mac OS X already has both Rect and Point declared */
#define Rect OTTD_Rect
#define Point OTTD_Point
#endif /* __APPLE__ */
/** Coordinates of a point in 2D */
struct Point {
int x;
int y;
};
/** Dimensions (a width and height) of a rectangle in 2D */
struct Dimension {
uint width;
uint height;
};
/** Specification of a rectangle with absolute coordinates of all edges */
struct Rect {
int left;
int top;
int right;
int bottom;
};
/**
* Specification of a rectangle with an absolute top-left coordinate and a
* (relative) width/height
*/
struct PointDimension {
int x;
int y;
int width;
int height;
};
/** A pair of two integers */
struct Pair {
int a;
int b;
};
#endif /* GEOMETRY_TYPE_HPP */
|