Erich/openttd - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2015-02-22	(svn r27167) -Fix: [SDL, Windows] Right-mouse-button scrolling ↵	frosch
	scrolled/jumped way to far, when OpenTTD lagged during mouse event processing.
2014-04-28	(svn r26538) -Codechange: remove double accounting of the drivers	rubidium

2014-04-27	(svn r26522) -Add: A config-file-only setting to disable usage of 8bpp video ↵	frosch
	modes. -Remove: [win32] fullscreen_bpp setting, which is replaced by above setting. -Change: Disable usage of 8bpp blitters and video modes by default. Many modern OS and hardware cause issues with those.
2014-04-23	(svn r26489) -Codechange: properly account for the end of buffers in the ↵	rubidium
	file io code instead of assuming MAX_PATH is okay
2014-04-23	(svn r26486) -Codechange: replace a number of snprintfs with seprintf	rubidium

2014-04-23	(svn r26482) -Codechange: add an include that allows us to undefine/redefine ↵	rubidium
	"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
2014-02-16	(svn r26351) -Fix: Protect all VideoDriver_SDL methods with the _draw_mutex.	frosch

2014-01-02	(svn r26209) -Codechange: remove some template magic and simplify some code	rubidium

2013-11-12	(svn r25970) -Fix [FS#5787]: [SDL] Recursive mutex locking when changing blitter	rubidium

2013-08-05	(svn r25671) -Codechange: Pass character and key code separately to the ↵	michi_cc
	keyboard handler.
2013-06-29	(svn r25523) -Fix [FS#5587]: SDL does not give an event when an application ↵	rubidium
	gets mouse focus while going to full screen, so manually force the mouse-is-in-window state
2013-06-04	(svn r25318) -Fix: [SDL, FS#5580] Keyboard input stopped working after ↵	matthijs
	fullscreen toggle
2013-02-17	(svn r25017) -Fix [FS#5466]: crash after bootstrap download of 32bits base ↵	rubidium
	set due to referencing a deleted mutex
2013-02-15	(svn r25003) -Fix (r24993): [SDL] Keep a flag to remember if a hardware ↵	matthijs
	palette was requested. - Previously, the code would query the SDL_HWPALETTE flag, which doesn't always match the requested value. - This would cause SDL to be restarted on every window resize event, effectively breaking resizing.
2013-02-15	(svn r25002) -Doc: [SDL] Fix typo in comment.	matthijs

2013-02-14	(svn r24993) -Fix: [SDL] Improve 8bpp hardware palette support. Instead of ↵	matthijs
	always requesting SDL_HWPALETTE, it is now only done for 8bp blitters in fullscreen mode. - This fixes 32bpp blitters on 8bpp X11, which would only render garbage with SDL_HWPALETTE. - This prevents the colors of other applications from being messed up when running a 8bpp blitter on a 8bpp system. - When running a 8bpp blitter on an 8bpp system without SDL_HWPALETTE (e.g., in windowed mode), this uses a new shadow surface with color approximation. - The use of a hardware palette can be forced on and off using -v sdl:hw_palette=1 or -v sdl:hw_palette=0
2013-02-14	(svn r24992) -Codechange: [SDL] Make CreateMainSurface and PollEvent private ↵	matthijs
	methods instead of static functions.
2013-01-08	(svn r24900) -Fix [FS#5389]: Comments with typos (most fixes supplied by ↵	planetmaker
	Eagle_rainbow)
2012-02-23	(svn r23980) -Fix (r23977): crash when starting with the 32bpp anim blitter	rubidium

2012-02-23	(svn r23978) -Fix: [SDL] Palette update was done too late making switching ↵	rubidium
	from 8bpp -> 32bpp look ugly
2012-02-07	(svn r23910) -Fix: [SDL] Handle the SDL_VIDEOEXPOSE event.	matthijs
	- It seems this event is never triggered when using 1.2 (it has some autorefresh feature which seems to have been removed in 1.3), but in theory this event could also trigger on 1.2. - Note that this fixes redraw issues when compiling against SDL 1.3, but it still uses the "compatibility" rendering API using SDL_SetVideoMode and SDL_UpdateRects. Eventually (when 1.3 is stable and released as 2.0), this should probably be rewritting to use the new Windows and Renderers available in SDL 1.3.
2012-02-07	(svn r23909) -Fix: [SDL] Fix keyboard-related segfault when compiling ↵	matthijs
	against SDL 1.3.
2012-02-04	(svn r23891) -Fix-ish: compile failures with SDL 1.3	rubidium

2011-12-08	(svn r23451) -Codechange: [SDL] Move 32bpp-anim palette animation to the ↵	rubidium
	draw thread instead of the single threaded bit of the game loop. This causes a speedup of up to 15% when animation is turned on with the 32bpp-anim blitter
2011-12-08	(svn r23448) -Fix: keep a local copy of the palette in the 32bpp animated ↵	rubidium
	blitter so changes of the palette data during the game don't influence drawing (with SDL)
2011-12-08	(svn r23446) -Codechange: move _cur_palette and it's related first/count ↵	rubidium
	dirty variables into a single structure
2011-11-17	(svn r23241) -Codechange: make the decision when to go to the custom drawn ↵	rubidium
	cursor more prominently during the initialisation of OpenTTD
2011-10-04	(svn r23003) -Fix (r22999): Missing semicolon.	michi_cc

2011-10-04	(svn r22999) -Codechange: Allow changing the blitter during the running game.	michi_cc

2011-09-09	(svn r22910) -Fix [FS#4617]: icon would (almost) never be shown for SDL builds	rubidium

2011-08-21	(svn r22788) -Codechange: move modal progress related functions and ↵	rubidium
	variables to progress.cpp/h
2011-08-21	(svn r22785) -Codechange: rename IsGeneratingWorld to HasModalProgress	rubidium

2011-02-07	(svn r22021) -Fix (r22019): ofcourse make doesn't notice files are gone, so ↵	rubidium
	it doesn't recompile everything that needs to be recompiled...
2010-11-19	(svn r21252) -Codechange: introduce a constant for the number of ↵	rubidium
	milliseconds per game tick and use it
2010-07-19	(svn r20192) -Cleanup: bye bye variables.h, bye bye VARDEF... you won't be ↵	rubidium
	missed :)
2010-06-12	(svn r19965) -Cleanup: Use size of buffer, not magic number.	peter1138

2010-01-15	(svn r18809) -Codechange/Cleanup: remove unneeded headers from some files, ↵	rubidium
	if a header require a header make it include that header
2010-01-13	(svn r18796) -Fix [FS#3521]: [SDL] possible deadlock when killing OpenTTD ↵	rubidium
	while starting it
2010-01-12	(svn r18790) -Revert (r18001,r18177,FS#3515): Viewport could still jump ↵	peter1138
	under high CPU load. Revert as change caused more problems than it fixed.
2010-01-04	(svn r18709) -Fix (r10227,FS#3464): Animation buffer for 32bpp-anim blitter ↵	peter1138
	was only validated during sprite blitting, other drawing operations didn't check it. Initial startup and window resize could therefore lead to crash.
2009-12-19	(svn r18547) -Fix [FS#3388]: missing thread synchronisation when changing ↵	rubidium
	the resolution for SDL via the in game menu
2009-12-19	(svn r18545) -Fix [FS#3292]: Assign '_screen.dst_ptr' as soon as it is ↵	frosch
	allocated.
2009-12-03	(svn r18390) -Fix (r17776): [SDL] Reinstate pointer update on 'idle' loop.	peter1138

2009-11-18	(svn r18177) -Fix (r18001): [SDL] Viewport could jump when mouse moved and ↵	peter1138
	right button pressed at the same time.
2009-11-09	(svn r18031) -Codechange: since basically r7157 adding up 'all' mouse ↵	rubidium
	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-07	(svn r18001) -Codechange: [SDL] When the mouse cursor is locked into ↵	peter1138
	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-02	(svn r17950) -Fix (r17776): _draw_mutex was never destroyed, _draw_thread ↵	smatz
	was never joined
2009-11-02	(svn r17949) -Fix (r17776): unlock mutex before deleting it when creating ↵	smatz
	drawing thread failed
2009-10-19	(svn r17815) -Fix [SDL]: asynchronious drawing caused extra unresponsiveness ↵	rubidium
	during map generation; disable the threading while generating a map
2009-10-15	(svn r17776) -Codechange: [SDL] make "update the video card"-process ↵	rubidium
	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.