rubidium
7aeccb9bd0
(svn r18796) -Fix [FS#3521]: [SDL] possible deadlock when killing OpenTTD while starting it
2010-01-13 21:34:48 +00:00
peter1138
694470e325
(svn r18790) -Revert (r18001,r18177,FS#3515): Viewport could still jump under high CPU load. Revert as change caused more problems than it fixed.
2010-01-12 09:54:18 +00:00
peter1138
c3fffe7496
(svn r18790) -Revert (r18001,r18177,FS#3515): Viewport could still jump under high CPU load. Revert as change caused more problems than it fixed.
2010-01-12 09:54:18 +00:00
peter1138
ebe260f575
(svn r18709) -Fix (r10227,FS#3464): Animation buffer for 32bpp-anim blitter was only validated during sprite blitting, other drawing operations didn't check it. Initial startup and window resize could therefore lead to crash.
2010-01-04 02:32:36 +00:00
peter1138
abb147d974
(svn r18709) -Fix (r10227,FS#3464): Animation buffer for 32bpp-anim blitter was only validated during sprite blitting, other drawing operations didn't check it. Initial startup and window resize could therefore lead to crash.
2010-01-04 02:32:36 +00:00
rubidium
bc5d452e82
(svn r18547) -Fix [FS#3388]: missing thread synchronisation when changing the resolution for SDL via the in game menu
2009-12-19 19:29:01 +00:00
rubidium
c811f3bd21
(svn r18547) -Fix [FS#3388]: missing thread synchronisation when changing the resolution for SDL via the in game menu
2009-12-19 19:29:01 +00:00
frosch
440ab2cf84
(svn r18545) -Fix [FS#3292]: Assign '_screen.dst_ptr' as soon as it is allocated.
2009-12-19 18:46:40 +00:00
frosch
29d6491605
(svn r18545) -Fix [FS#3292]: Assign '_screen.dst_ptr' as soon as it is allocated.
2009-12-19 18:46:40 +00:00
peter1138
57bcb5f903
(svn r18390) -Fix (r17776): [SDL] Reinstate pointer update on 'idle' loop.
2009-12-03 08:24:39 +00:00
peter1138
3addf58f30
(svn r18390) -Fix (r17776): [SDL] Reinstate pointer update on 'idle' loop.
2009-12-03 08:24:39 +00:00
peter1138
dece4a4cfb
(svn r18177) -Fix (r18001): [SDL] Viewport could jump when mouse moved and right button pressed at the same time.
2009-11-18 23:07:29 +00:00
peter1138
b0049500a6
(svn r18177) -Fix (r18001): [SDL] Viewport could jump when mouse moved and right button pressed at the same time.
2009-11-18 23:07:29 +00:00
rubidium
639395b69f
(svn r18031) -Codechange: since basically r7157 adding up 'all' mouse movement isn't needed anymore because after each even that movement is handled and the counter is reset. As such simply assigning instead of adding works.
2009-11-09 16:07:03 +00:00
rubidium
88a7e23897
(svn r18031) -Codechange: since basically r7157 adding up 'all' mouse movement isn't needed anymore because after each even that movement is handled and the counter is reset. As such simply assigning instead of adding works.
2009-11-09 16:07:03 +00:00
peter1138
0314ad1a38
(svn r18001) -Codechange: [SDL] When the mouse cursor is locked into position when scrolling a viewport, warp the mouse pointer to the centre of the window. This gives maximum freedom of movement. The pointer position is restored when the lock is removed. Visually the mouse cursor stays where it was.
2009-11-07 21:41:41 +00:00
peter1138
723c19571f
(svn r18001) -Codechange: [SDL] When the mouse cursor is locked into position when scrolling a viewport, warp the mouse pointer to the centre of the window. This gives maximum freedom of movement. The pointer position is restored when the lock is removed. Visually the mouse cursor stays where it was.
2009-11-07 21:41:41 +00:00
smatz
c2f0845b92
(svn r17950) -Fix (r17776): _draw_mutex was never destroyed, _draw_thread was never joined
2009-11-02 13:36:17 +00:00
smatz
da54a01114
(svn r17950) -Fix (r17776): _draw_mutex was never destroyed, _draw_thread was never joined
2009-11-02 13:36:17 +00:00
smatz
bb56cd39b6
(svn r17949) -Fix (r17776): unlock mutex before deleting it when creating drawing thread failed
2009-11-02 12:12:13 +00:00
smatz
dc4b251dbd
(svn r17949) -Fix (r17776): unlock mutex before deleting it when creating drawing thread failed
2009-11-02 12:12:13 +00:00
rubidium
8e1f62993d
(svn r17815) -Fix [SDL]: asynchronious drawing caused extra unresponsiveness during map generation; disable the threading while generating a map
2009-10-19 20:32:05 +00:00
rubidium
cfcf3159b2
(svn r17815) -Fix [SDL]: asynchronious drawing caused extra unresponsiveness during map generation; disable the threading while generating a map
2009-10-19 20:32:05 +00:00
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.
2009-10-15 17:41:06 +00:00
rubidium
f4f4044859
(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.
2009-10-15 17:41:06 +00:00
rubidium
99d46e0ad7
(svn r17248) -Fix: add GPL license notice where appropriate
2009-08-21 20:21:05 +00:00
rubidium
7fbc33dae1
(svn r17248) -Fix: add GPL license notice where appropriate
2009-08-21 20:21:05 +00:00
rubidium
231626f98c
(svn r16699) -Fix [FS#3001]: if SDL fails to allocate a surface due to it being too large (and SDL doesn't crash!) fall back to another video driver.
2009-06-30 12:36:24 +00:00
rubidium
791187cd12
(svn r16699) -Fix [FS#3001]: if SDL fails to allocate a surface due to it being too large (and SDL doesn't crash!) fall back to another video driver.
2009-06-30 12:36:24 +00:00
alberth
c52fe937d5
(svn r16677) -Codechange: Dimension width and height are unsigned.
2009-06-27 20:53:45 +00:00
alberth
9b070b5405
(svn r16677) -Codechange: Dimension width and height are unsigned.
2009-06-27 20:53:45 +00:00
rubidium
241af768f0
(svn r16242) -Codechange: rework pausing
...
-Fix [FS#2864]: autopause and manual pausing conflict with eachother
-Fix: new game + pause on new game + autopause make the game not unpause on the first join
2009-05-06 15:06:57 +00:00
rubidium
2664f2a2d9
(svn r16242) -Codechange: rework pausing
...
-Fix [FS#2864]: autopause and manual pausing conflict with eachother
-Fix: new game + pause on new game + autopause make the game not unpause on the first join
2009-05-06 15:06:57 +00:00
smatz
9021c20b5e
(svn r15299) -Cleanup: remove many redundant includes
2009-01-31 20:16:06 +00:00
smatz
0d3f5e6e74
(svn r15299) -Cleanup: remove many redundant includes
2009-01-31 20:16:06 +00:00
glx
0d87169563
(svn r15233) -Fix (r15231): compilation with SDL broken on win32
2009-01-23 17:32:01 +00:00
glx
a3dc092ebc
(svn r15233) -Fix (r15231): compilation with SDL broken on win32
2009-01-23 17:32:01 +00:00
rubidium
2a76f869a3
(svn r15232) -Codechange: sprinklin' of coding style
2009-01-23 16:05:58 +00:00
rubidium
48125a6d5f
(svn r15232) -Codechange: sprinklin' of coding style
2009-01-23 16:05:58 +00:00
rubidium
8800294a33
(svn r15231) -Change: (sdl) check the full screen resolutions to determine what 'valid' resolutions we've got
2009-01-23 15:58:34 +00:00
rubidium
4ba90f6887
(svn r15231) -Change: (sdl) check the full screen resolutions to determine what 'valid' resolutions we've got
2009-01-23 15:58:34 +00:00
rubidium
913f51b2fb
(svn r14641) -Change [Allegro]: when making a debug build revert Allegro's hooks on SIGSEGV/SIGABRT so one can actually use gdb.
...
-Change: make it more clear that Allegro's failing to find a driver.
2008-11-29 01:28:13 +00:00
rubidium
cdec8f6b27
(svn r14641) -Change [Allegro]: when making a debug build revert Allegro's hooks on SIGSEGV/SIGABRT so one can actually use gdb.
...
-Change: make it more clear that Allegro's failing to find a driver.
2008-11-29 01:28:13 +00:00
rubidium
956c99e46c
(svn r14260) -Fix [FS#2277]: merge keycode for "normal" 0-9 keys and keypad 0-9 keys so people don't get confused that the keypad doesn't work as expected.
2008-09-07 11:55:28 +00:00
rubidium
3b7ffcf759
(svn r14260) -Fix [FS#2277]: merge keycode for "normal" 0-9 keys and keypad 0-9 keys so people don't get confused that the keypad doesn't work as expected.
2008-09-07 11:55:28 +00:00
rubidium
31d69a49e8
(svn r14047) -Codechange: move chatmessage handling to the network directory as that's the only case chat messages are used. Furthermore remove any trace of chatmessages when compiling without network support.
2008-08-11 22:45:11 +00:00
rubidium
d0c1a989a4
(svn r14047) -Codechange: move chatmessage handling to the network directory as that's the only case chat messages are used. Furthermore remove any trace of chatmessages when compiling without network support.
2008-08-11 22:45:11 +00:00
smatz
e00df941fa
(svn r13537) -Fix [FS#2090](r13523): QSortT won't work this way, use Dimension instead of uint16[2] for resolutions
2008-06-16 19:38:41 +00:00
smatz
2299181c4b
(svn r13537) -Fix [FS#2090](r13523): QSortT won't work this way, use Dimension instead of uint16[2] for resolutions
2008-06-16 19:38:41 +00:00
glx
b60a1326bf
(svn r13390) -Codechange: introduce usererror() for fatal but not openttd related errors. Now all error() will 'crash' openttd after showing the message in win32 releases (MSVC), creating a crash.log and crash.dmp (like the '!' hack used before). On the other hand, usererror() will just close the game. So use error() only when it can be helpful to debugging, else use usererror().
2008-06-05 20:54:52 +00:00
