jgrpp
tmp-jgrpp
master
mapgen-water-desert-removal-circular
wip-string-2
wip-string
diagonal_road_investigations
sse-blitter-set-alpha
desync-debugging
save_ext
tracerestrict
tracerestrict-sx
jgrpp-0.1
jgrpp-0.1.1
jgrpp-0.1.2
jgrpp-0.10.0
jgrpp-0.10.1
jgrpp-0.10.2
jgrpp-0.11.0
jgrpp-0.12.0
jgrpp-0.12.1
jgrpp-0.13.0
jgrpp-0.13.1
jgrpp-0.13.2
jgrpp-0.13.3
jgrpp-0.14.0
jgrpp-0.15.0
jgrpp-0.15.1
jgrpp-0.16.0
jgrpp-0.16.1
jgrpp-0.17.0
jgrpp-0.17.1
jgrpp-0.17.2
jgrpp-0.18.0
jgrpp-0.19.0
jgrpp-0.2.0
jgrpp-0.2.1
jgrpp-0.20.0
jgrpp-0.20.1
jgrpp-0.21.0
jgrpp-0.22.0
jgrpp-0.22.1
jgrpp-0.22.2
jgrpp-0.23.0
jgrpp-0.24.0
jgrpp-0.24.1
jgrpp-0.25.0
jgrpp-0.25.1
jgrpp-0.25.2
jgrpp-0.26.0
jgrpp-0.26.1
jgrpp-0.26.2
jgrpp-0.27.0
jgrpp-0.27.1
jgrpp-0.28.0
jgrpp-0.29.0
jgrpp-0.29.1
jgrpp-0.29.2
jgrpp-0.29.3
jgrpp-0.3.0
jgrpp-0.3.1
jgrpp-0.3.2
jgrpp-0.30.0
jgrpp-0.30.1
jgrpp-0.30.2
jgrpp-0.30.3
jgrpp-0.31.0
jgrpp-0.31.1
jgrpp-0.31.2
jgrpp-0.31.3
jgrpp-0.31.4
jgrpp-0.31.5
jgrpp-0.32-rc1
jgrpp-0.32-rc2
jgrpp-0.32-rc3
jgrpp-0.32-rc4
jgrpp-0.32-rc5
jgrpp-0.32.0
jgrpp-0.32.1
jgrpp-0.32.2
jgrpp-0.32.3
jgrpp-0.32.4
jgrpp-0.33.0
jgrpp-0.33.1
jgrpp-0.33.2
jgrpp-0.34-rc1
jgrpp-0.34.0
jgrpp-0.34.1
jgrpp-0.34.2
jgrpp-0.34.3
jgrpp-0.34.4
jgrpp-0.35.0
jgrpp-0.35.1
jgrpp-0.36.0
jgrpp-0.37.0
jgrpp-0.38.0
jgrpp-0.38.1
jgrpp-0.39.0
jgrpp-0.39.1
jgrpp-0.39.2
jgrpp-0.4.0
jgrpp-0.4.1
jgrpp-0.40.0
jgrpp-0.40.1
jgrpp-0.40.2
jgrpp-0.40.3
jgrpp-0.40.4
jgrpp-0.40.5
jgrpp-0.41.0
jgrpp-0.41.1
jgrpp-0.41.2
jgrpp-0.41.3
jgrpp-0.42.0
jgrpp-0.42.1
jgrpp-0.42.2
jgrpp-0.42.3
jgrpp-0.43.0
jgrpp-0.43.1
jgrpp-0.43.2
jgrpp-0.44-rc1
jgrpp-0.44.0
jgrpp-0.44.1
jgrpp-0.44.2
jgrpp-0.45.0
jgrpp-0.45.1
jgrpp-0.46-rc1
jgrpp-0.46-rc2
jgrpp-0.46.0
jgrpp-0.46.1
jgrpp-0.47.0
jgrpp-0.47.1
jgrpp-0.47.2
jgrpp-0.47.3
jgrpp-0.48.0
jgrpp-0.48.1
jgrpp-0.48.2
jgrpp-0.48.3
jgrpp-0.48.4
jgrpp-0.48.5
jgrpp-0.49.0
jgrpp-0.49.1
jgrpp-0.49.2
jgrpp-0.5.0
jgrpp-0.5.1
jgrpp-0.5.2
jgrpp-0.5.3
jgrpp-0.50.0
jgrpp-0.50.1
jgrpp-0.50.2
jgrpp-0.50.3
jgrpp-0.51.0
jgrpp-0.51.1
jgrpp-0.52.0
jgrpp-0.52.1
jgrpp-0.53.0
jgrpp-0.53.1
jgrpp-0.53.2
jgrpp-0.53.3
jgrpp-0.54.0
jgrpp-0.54.1
jgrpp-0.54.2
jgrpp-0.54.3
jgrpp-0.54.4
jgrpp-0.54.5
jgrpp-0.55.0
jgrpp-0.55.1
jgrpp-0.55.2
jgrpp-0.55.3
jgrpp-0.56.0
jgrpp-0.56.1
jgrpp-0.56.2
jgrpp-0.57.0
jgrpp-0.57.1
jgrpp-0.58.0
jgrpp-0.58.1
jgrpp-0.58.2
jgrpp-0.58.3
jgrpp-0.59.0
jgrpp-0.59.1
jgrpp-0.6.0
jgrpp-0.60.0
jgrpp-0.60.1
jgrpp-0.60.2
jgrpp-0.61.0
jgrpp-0.62.0
jgrpp-0.7.0
jgrpp-0.7.1
jgrpp-0.8.0
jgrpp-0.8.1
jgrpp-0.9.0
${ noResults }
5 Commits (dba90d725c197fab1cb67b78e681ca87d9c8b36f)
Author | SHA1 | Message | Date |
---|---|---|---|
rubidium | 87272273b5 | (svn r22405) -Document: some more "random-ish" tidbits | 14 years ago |
smatz | 548a3747e9 | (svn r20860) -Cleanup: remove some unused functions and variables | 14 years ago |
rubidium | 3ae91dbc34 | (svn r20823) -Codechange: enable/add some error/sanity checking in the pthread code | 14 years ago |
rubidium | 0307d13d0a |
(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. |
15 years ago |
rubidium | 533e3da493 | (svn r17339) -Codechange: move thread related files to their own directory (like done for video, music, sound, etc) | 15 years ago |