| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
We assume a conforming C++11 compiler environment that has a valid <thread>-header.
Failure to run a real thread is handled gracefully.
|
|
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.
|
|
|
|
This is more in trend with other files, where if the driver is not
selected, we don't even attempt to compile it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libtimidity was introduced with the support for PSP. PSP has been
dropped almost a year ago, but this music driver was not. This
corrects that oversight.
timidity (via extmidi) still works fine. This purely removes the
libtimidity support, which was only really available for PSP.
|
|
In 10 years there is no commit to change how BeOS works, and we
have no active maintainer for it. It is unlikely it works in its
current state (but not impossible).
With the arrival of SDL2 (and removal of SDL), BeOS is no longer
support. SDL2 suggests to use Haiku instead of BeOS.
|
|
In 10 years there is no commit to change how MorphOS works, and we
have no active maintainer for it. It is unlikely it works in its
current state (but not impossible).
With the arrival of SDL2 (and removal of SDL), MorphOS is no longer
support. There is an SDL2 port for MorphOS, but it is not maintained
by upstream SDL2, and nobody can currently test it out.
If anyone wants to re-add MorphOS, please do (revert this patch,
fix the problems, and create a Pull Request). If you need any help
doing so, let us know! It is not that we don't like MorphOS, it is
that we don't have anyone fixing the problems :(
|
|
|
|
This is remove per-pixel overheads due to use of the SetPixel virtual
method.
These overheads included:
* expensive virtual method call which prevents inlining
* palette lookup for every pixel
* branch on whether palette animation is enabled on every pixel
Regenerate project files.
|
|
|
|
|
|
|
|
scripts and fix documentation.
|
|
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.
|
|
Uniscribe is sometimes producing different results compared to ICU, especially
when RTL and LTR content is mixed. Comparing the results to other programs
(like editors or web browsers) leads me to believe that the result are at least
not worse than ICU and possibly better.
|
|
Create a new blitter mode: 32bpp-sse2-anim, which is 32bpp-anim + this.
32bpp-sse2-anim is now used by default where 32bpp-anim would have been.
Also use this with the 32bpp-sse4-anim blitter.
See issue #6469.
|
|
|
|
MCI MIDI is poorly supported on newer versions of Windows and can cause large
delays at the beginning of tracks.
The new driver is based on a from-scratch reader for Standard MIDI Files. This
should be re-usable in other music drivers too, and can allow for finer control
of playback in general.
It also provides a better framework for reading MIDI data from other formats
than just SMF.
|
|
|
|
|
|
|
|
a file no its own. (Cif)
|
|
|
|
|
|
|
|
especially never should use
|
|
|
|
for a particular platform
|
|
page elements for a given page
|
|
|
|
|
|
|
|
|
|
With 32bpp base set about 15-20% faster in the Draw function (slower with 8bpp base set). Overall, with 32bpp base set, about 5% faster.
|
|
With 32bpp base set about 40% faster than 32bpp-optimized, or about 10% for 8bpp base sets in the Draw function. Respectively about 8 and 1% of total run time
|
|
With 32bpp base set about 35% faster than 32bpp-optimized, or about 10% for 8bpp base sets in the Draw function. Respectively about 6 and 1% of total run time
|
|
With 32bpp base set about 30% faster than 32bpp-optimized, or about 10% for 8bpp base sets in the Draw function. Respectively about 5 and 1% of total run time
|
