Github provides a Travis CI integration which makes it easy to have a quick
check of a patch before a pull request is accepted. It is not enough to prove
the correctness of a contribution but at least helps to avoid some of the worst
build problems.
This feature *must* be enabled by the mupen64plus administrator *before this
commit is merged*:
- https://travis-ci.org/profile/mupen64plus
- Login via your Github account
- Make sure you are on "https://travis-ci.org/profile/mupen64plus"
- Switch repository to "On"
The -hlevideo plugin was just a quick hack to provide the functionality to
enable the DisplayListToGraphicsPlugin option. This is not the behavior
encouraged by mupen64plus-core because it already provides a configuration
system.
New configuration options are:
* DisplayListToGraphicsPlugin
Send display lists to the graphics plugin (hlevideo)
* AudioListToAudioPlugin
Send audio lists to the audio plugin
* WaitForCPUHost
Force CPU-RSP signals synchronization
* SupportCPUSemaphoreLock
Support CPU-RSP semaphore lock
The builds from the original author used SSSE3 in their default build but it
seems it is only supported by fairly recent Intel processors. Thus setting it
to SSE2 instead by default should be better for people building it from source.
The default builds by the original author of the plugin were optimized for
SSSE3 or SSE2. These build options were missing in this port. Both can now be
build by setting the make parameter SSE to either SSE2 or SSSE3. It can also be
set to none when no SSE optimizations should be activated by the Makefile (own
FLAGS can still be supplied using CFLAGS).
Both build will get an own postfix in the future but currently the postfix is
used by the HLEVIDEO compile option. The postfix will be activated when the
HLEVIDEO configuration is done through the mupen64plus configuration system.
The process of dedicating a piece of work under the public domain is not the
same under different legal systems. It is possible that different rights are
given away depending on the origin. Sometimes even the dedication of the work
under public domain is not possible at all. CC0 tries to provide an explicit
way to waive all rights to still provide a secure way for other parties to use
this work [1] and provides a fallback when parts of the license may be judged
invalid under any jurisdiction.
[1] http://creativecommons.org/about/cc0
The 3DNow! instruction set is not supported by Intel processors.
Although gcc will not likely emit 3DNow! instructions, it is
dangerous to permit 3DNow! instructions due to the fact that Intel
has never supported 3DNow! instructions.
This only affects long's which are used on an 64-bit system. The zilmar spec
with its DWORD is not touched because on 32 bit it is always 32 bit for common
systems. On Win64 systems it is also 32 bit because Microsoft adopted LLP64.
All other systems seem to use LP64 (IL32LP64), ILP64 or SILP64.
ILP64 and SILP64 would also need to have shorts and int (when the code expects
32 bit) to be changed to (u)int*_t counterparts. This is not done in here.
The wrong div operations result in wrong transformations in many roms.
This regression was introduced in 87210c71a5
("cleanups and rewrites to the vector divide class").
