mirror of https://github.com/encounter/SDL.git
Fixed typos (thanks Martin!)
This commit is contained in:
parent
67950e101e
commit
14452e9550
|
@ -189,7 +189,7 @@ func_basename ()
|
|||
# to NONDIR_REPLACEMENT.
|
||||
# value returned in "$func_dirname_result"
|
||||
# basename: Compute filename of FILE.
|
||||
# value retuned in "$func_basename_result"
|
||||
# value returned in "$func_basename_result"
|
||||
# Implementation must be kept synchronized with func_dirname
|
||||
# and func_basename. For efficiency, we do not delegate to
|
||||
# those functions but instead duplicate the functionality here.
|
||||
|
@ -3276,7 +3276,7 @@ extern \"C\" {
|
|||
|
||||
/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests. */
|
||||
#if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
|
||||
/* DATA imports from DLLs on WIN32 con't be const, because runtime
|
||||
/* DATA imports from DLLs on WIN32 can't be const, because runtime
|
||||
relocations are performed -- see ld's documentation on pseudo-relocs. */
|
||||
# define LT_DLSYM_CONST
|
||||
#elif defined(__osf__)
|
||||
|
@ -4394,7 +4394,7 @@ EOF
|
|||
{
|
||||
/* however, if there is an option in the LTWRAPPER_OPTION_PREFIX
|
||||
namespace, but it is not one of the ones we know about and
|
||||
have already dealt with, above (inluding dump-script), then
|
||||
have already dealt with, above (including dump-script), then
|
||||
report an error. Otherwise, targets might begin to believe
|
||||
they are allowed to use options in the LTWRAPPER_OPTION_PREFIX
|
||||
namespace. The first time any user complains about this, we'll
|
||||
|
|
|
@ -64,7 +64,7 @@ level of indirection, we can do things like this:
|
|||
export SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0
|
||||
./MyGameThatIsStaticallyLinkedToSDL2
|
||||
|
||||
And now, this game that is staticallly linked to SDL, can still be overridden
|
||||
And now, this game that is statically linked to SDL, can still be overridden
|
||||
with a newer, or better, SDL. The statically linked one will only be used as
|
||||
far as calling into the jump table in this case. But in cases where no override
|
||||
is desired, the statically linked version will provide its own jump table,
|
||||
|
|
|
@ -23,7 +23,7 @@ Requirements
|
|||
typically do not include support for creating WinRT apps, to note.
|
||||
(The "Community" editions of Visual C++ do, however, support both
|
||||
desktop/Win32 and WinRT development).
|
||||
- Visual Studio 2017 can be used, however it is recommented that you install
|
||||
- Visual Studio 2017 can be used, however it is recommended that you install
|
||||
the Visual C++ 2015 build tools. These build tools can be installed
|
||||
using VS 2017's installer. Be sure to also install the workload for
|
||||
"Universal Windows Platform development", its optional component, the
|
||||
|
@ -33,7 +33,7 @@ Requirements
|
|||
earlier versions of Windows, such as Windows 7, is not always supported
|
||||
by Visual Studio, and you may get error(s) when attempting to do so.
|
||||
- Visual C++ 2012 can only build apps that target versions 8.0 of Windows,
|
||||
or Windows Phone. 8.0-targetted apps will run on devices running 8.1
|
||||
or Windows Phone. 8.0-targeted apps will run on devices running 8.1
|
||||
editions of Windows, however they will not be able to take advantage of
|
||||
8.1-specific features.
|
||||
- Visual C++ 2013 cannot create app projects that target Windows 8.0.
|
||||
|
@ -54,7 +54,7 @@ Requirements
|
|||
Status
|
||||
------
|
||||
|
||||
Here is a rough list of what works, and what doens't:
|
||||
Here is a rough list of what works, and what doesn't:
|
||||
|
||||
* What works:
|
||||
* compilation via Visual C++ 2012 through 2015
|
||||
|
|
|
@ -470,7 +470,7 @@ extern DECLSPEC Uint32 SDLCALL SDL_GetWindowPixelFormat(SDL_Window * window);
|
|||
* If the window is created with any of the SDL_WINDOW_OPENGL or
|
||||
* SDL_WINDOW_VULKAN flags, then the corresponding LoadLibrary function
|
||||
* (SDL_GL_LoadLibrary or SDL_Vulkan_LoadLibrary) is called and the
|
||||
* corrensponding UnloadLibrary function is called by SDL_DestroyWindow().
|
||||
* corresponding UnloadLibrary function is called by SDL_DestroyWindow().
|
||||
*
|
||||
* If SDL_WINDOW_VULKAN is specified and there isn't a working Vulkan driver,
|
||||
* SDL_CreateWindow() will fail because SDL_Vulkan_LoadLibrary() will fail.
|
||||
|
|
|
@ -3,14 +3,14 @@ From: https://github.com/descampsa/yuv2rgb
|
|||
C library for fast image conversion between yuv420p and rgb24.
|
||||
|
||||
This is a simple library for optimized image conversion between YUV420p and rgb24.
|
||||
It was done mainly as an exercise to learn to use sse instrinsics, so there may still be room for optimization.
|
||||
It was done mainly as an exercise to learn to use sse intrinsics, so there may still be room for optimization.
|
||||
|
||||
For each conversion, a standard c optimized function and two sse function (with aligned and unaligned memory) are implemented.
|
||||
The sse version requires only SSE2, which is available on any reasonnably recent CPU.
|
||||
The sse version requires only SSE2, which is available on any reasonably recent CPU.
|
||||
The library also supports the three different YUV (YCrCb to be correct) color spaces that exist (see comments in code), and others can be added simply.
|
||||
|
||||
There is a simple test program, that convert a raw YUV file to rgb ppm format, and measure computation time.
|
||||
Optionnaly, it also compares the result and computation time with the ffmpeg implementation (that uses MMX), and with the IPP functions.
|
||||
Optionally, it also compares the result and computation time with the ffmpeg implementation (that uses MMX), and with the IPP functions.
|
||||
|
||||
To compile, simply do :
|
||||
|
||||
|
|
Loading…
Reference in New Issue