| Age | Commit message (Collapse) | Author |
|---|
|
In 10 years there was no active development on DOS. Although it
turned out to still work, the FPS was very bad. There is little
interest in the current community to look into this.
Further more, we like to switch to c++11 functions for threads,
which are not implemented by DJGPP, the only current compiler
for DOS.
Additionally, DOS is the only platform which does not support
networking. It is the reason we have tons of #ifdefs to support
disabling networking.
By removing DOS support, we can both use c++11 functions for threads,
and remove all the code related to disabling network. Sadly, this
means we have to see DOS go.
Of course, if you feel up for the task, simply revert this commit,
and implement stub c++11 functions for threads and stub functions
for networking. We are more than happy to accept such Pull Request.
|
|
Frame rate and various game loop/graphics timing measurements and graphs. Accessible via the Help menu, and can print some stats in the console via the fps command.
|
|
|
|
scrolled/jumped way to far, when OpenTTD lagged during mouse event processing.
|
|
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
|
|
keyboard handler.
|
|
Eagle_rainbow)
|
|
moving with the allegro video driver
|
|
blitter so changes of the palette data during the game don't influence drawing (with SDL)
|
|
dirty variables into a single structure
|
|
cursor more prominently during the initialisation of OpenTTD
|
|
|
|
it doesn't recompile everything that needs to be recompiled...
|
|
milliseconds per game tick and use it
|
|
|
|
|
|
missed :)
|
|
|
|
consisted of unrelated values use static const (u)int
|
|
if a header require a header make it include that header
|
|
was only validated during sprite blitting, other drawing operations didn't check it. Initial startup and window resize could therefore lead to crash.
|
|
allocated.
|
|
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.
|
|
with some actions.
|
|
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.
|
|
|
|
|
|
card fall back to another driver
|
|
|
|
code style.
|
|
-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
|
|
|
|
hooks on SIGSEGV/SIGABRT so one can actually use gdb.
-Change: make it more clear that Allegro's failing to find a driver.
|
|
|
|
|
|
|
|
|
