|
Michael Lutz
|
r23586:11b470d4cee6
|
6 years ago
|
|
Codechange: Replace custom mutex code with C++11 mutex'es.
A conforming compiler with a valid <mutex>-header is expected. Most parts of the code assume that locking a mutex will never fail unexpectedly, which is generally true on all common platforms that don't just pretend to be C++11. The use of condition variables in driver code is checked.
|
|
Henry Wilson
|
r23497:a0ab44ebd2fa
|
6 years ago
|
|
Codechange: Use override specifer for overriding member declarations
This is a C++11 feature that allows the compiler to check that a virtual member declaration overrides a base-class member with the same signature.
Also src/blitter/32bpp_anim_sse4.hpp +38 is no longer erroneously marked as virtual despite being a template.
|
|
Michael Lutz
|
r22780:58edd93c83ed
|
7 years ago
|
|
|
|
frosch
|
r22463:71520ac0d007
|
8 years ago
|
|
|
|
rubidium
|
r21383:942c32fb8b0e
|
10 years ago
|
|
|
|
frosch
|
r21261:35860f07395a
|
11 years ago
|
|
|
|
rubidium
|
r17624:f2c5f47dceaa
|
13 years ago
|
|
|
|
smatz
|
r16154:2589af63711f
|
14 years ago
|
|
|
|
rubidium
|
r16117:55df70039929
|
14 years ago
|
|
|
|
rubidium
|
r13257:4c5b8120be59
|
15 years ago
|
|
(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.
|
|
rubidium
|
r12839:daeca5b0e6db
|
15 years ago
|
|
|