mirror of
https://github.com/TorqueGameEngines/Torque3D.git
synced 2026-07-14 08:04:40 +00:00
update sdl to https://github.com/libsdl-org/SDL 22March 2022
This commit is contained in:
AzaezelX
parent
ee4253c982
commit
2614274639
1225 changed files with 148950 additions and 51674 deletions
|
|
@ -10,8 +10,7 @@ If you are using the older ant build process, it is no longer officially
|
|||
supported, but you can use the "android-project-ant" directory as a template.
|
||||
|
||||
|
||||
================================================================================
|
||||
Requirements
|
||||
Requirements
|
||||
================================================================================
|
||||
|
||||
Android SDK (version 26 or later)
|
||||
|
|
@ -23,8 +22,7 @@ https://developer.android.com/tools/sdk/ndk/index.html
|
|||
Minimum API level supported by SDL: 16 (Android 4.1)
|
||||
|
||||
|
||||
================================================================================
|
||||
How the port works
|
||||
How the port works
|
||||
================================================================================
|
||||
|
||||
- Android applications are Java-based, optionally with parts written in C
|
||||
|
|
@ -42,8 +40,7 @@ dispatches to native functions implemented in the SDL library:
|
|||
src/core/android/SDL_android.c
|
||||
|
||||
|
||||
================================================================================
|
||||
Building an app
|
||||
Building an app
|
||||
================================================================================
|
||||
|
||||
For simple projects you can use the script located at build-scripts/androidbuild.sh
|
||||
|
|
@ -120,8 +117,7 @@ Here's an explanation of the files in the Android project, so you can customize
|
|||
src/main/java/org/libsdl/app/SDLActivity.java - the Java class handling the initialization and binding to SDL. Be very careful changing this, as the SDL library relies on this implementation. You should instead subclass this for your application.
|
||||
|
||||
|
||||
================================================================================
|
||||
Customizing your application name
|
||||
Customizing your application name
|
||||
================================================================================
|
||||
|
||||
To customize your application name, edit AndroidManifest.xml and replace
|
||||
|
|
@ -151,8 +147,7 @@ Then replace "SDLActivity" in AndroidManifest.xml with the name of your
|
|||
class, .e.g. "MyGame"
|
||||
|
||||
|
||||
================================================================================
|
||||
Customizing your application icon
|
||||
Customizing your application icon
|
||||
================================================================================
|
||||
|
||||
Conceptually changing your icon is just replacing the "ic_launcher.png" files in
|
||||
|
|
@ -160,8 +155,7 @@ the drawable directories under the res directory. There are several directories
|
|||
for different screen sizes.
|
||||
|
||||
|
||||
================================================================================
|
||||
Loading assets
|
||||
Loading assets
|
||||
================================================================================
|
||||
|
||||
Any files you put in the "app/src/main/assets" directory of your project
|
||||
|
|
@ -189,8 +183,7 @@ disable this behaviour, see for example:
|
|||
http://ponystyle.com/blog/2010/03/26/dealing-with-asset-compression-in-android-apps/
|
||||
|
||||
|
||||
================================================================================
|
||||
Pause / Resume behaviour
|
||||
Pause / Resume behaviour
|
||||
================================================================================
|
||||
|
||||
If SDL_HINT_ANDROID_BLOCK_ON_PAUSE hint is set (the default),
|
||||
|
|
@ -205,13 +198,40 @@ app can continue to operate as it was.
|
|||
|
||||
However, there's a chance (on older hardware, or on systems under heavy load),
|
||||
where the GL context can not be restored. In that case you have to listen for
|
||||
a specific message, (which is not yet implemented!) and restore your textures
|
||||
manually or quit the app (which is actually the kind of behaviour you'll see
|
||||
under iOS, if the OS can not restore your GL context it will just kill your app)
|
||||
a specific message (SDL_RENDER_DEVICE_RESET) and restore your textures
|
||||
manually or quit the app.
|
||||
|
||||
You should not use the SDL renderer API while the app going in background:
|
||||
- SDL_APP_WILLENTERBACKGROUND:
|
||||
after you read this message, GL context gets backed-up and you should not
|
||||
use the SDL renderer API.
|
||||
|
||||
When this event is received, you have to set the render target to NULL, if you're using it.
|
||||
(eg call SDL_SetRenderTarget(renderer, NULL))
|
||||
|
||||
- SDL_APP_DIDENTERFOREGROUND:
|
||||
GL context is restored, and the SDL renderer API is available (unless you
|
||||
receive SDL_RENDER_DEVICE_RESET).
|
||||
|
||||
Mouse / Touch events
|
||||
================================================================================
|
||||
Threads and the Java VM
|
||||
|
||||
In some case, SDL generates synthetic mouse (resp. touch) events for touch
|
||||
(resp. mouse) devices.
|
||||
To enable/disable this behavior, see SDL_hints.h:
|
||||
- SDL_HINT_TOUCH_MOUSE_EVENTS
|
||||
- SDL_HINT_MOUSE_TOUCH_EVENTS
|
||||
|
||||
Misc
|
||||
================================================================================
|
||||
|
||||
For some device, it appears to works better setting explicitly GL attributes
|
||||
before creating a window:
|
||||
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
|
||||
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
|
||||
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);
|
||||
|
||||
Threads and the Java VM
|
||||
================================================================================
|
||||
|
||||
For a quick tour on how Linux native threads interoperate with the Java VM, take
|
||||
|
|
@ -226,8 +246,17 @@ your thread automatically anyway (when you make an SDL call), but it'll never
|
|||
detach it.
|
||||
|
||||
|
||||
================================================================================
|
||||
Using STL
|
||||
If you ever want to use JNI in a native thread (created by "SDL_CreateThread()"),
|
||||
it won't be able to find your java class and method because of the java class loader
|
||||
which is different for native threads, than for java threads (eg your "main()").
|
||||
|
||||
the work-around is to find class/method, in you "main()" thread, and to use them
|
||||
in your native thread.
|
||||
|
||||
see:
|
||||
https://developer.android.com/training/articles/perf-jni#faq:-why-didnt-findclass-find-my-class
|
||||
|
||||
Using STL
|
||||
================================================================================
|
||||
|
||||
You can use STL in your project by creating an Application.mk file in the jni
|
||||
|
|
@ -239,8 +268,7 @@ For more information go here:
|
|||
https://developer.android.com/ndk/guides/cpp-support
|
||||
|
||||
|
||||
================================================================================
|
||||
Using the emulator
|
||||
Using the emulator
|
||||
================================================================================
|
||||
|
||||
There are some good tips and tricks for getting the most out of the
|
||||
|
|
@ -252,8 +280,7 @@ Notice that this software emulator is incredibly slow and needs a lot of disk sp
|
|||
Using a real device works better.
|
||||
|
||||
|
||||
================================================================================
|
||||
Troubleshooting
|
||||
Troubleshooting
|
||||
================================================================================
|
||||
|
||||
You can see if adb can see any devices with the following command:
|
||||
|
|
@ -332,8 +359,7 @@ If you need to build without optimization turned on, you can create a file calle
|
|||
APP_OPTIM := debug
|
||||
|
||||
|
||||
================================================================================
|
||||
Memory debugging
|
||||
Memory debugging
|
||||
================================================================================
|
||||
|
||||
The best (and slowest) way to debug memory issues on Android is valgrind.
|
||||
|
|
@ -384,8 +410,7 @@ When you're done instrumenting with valgrind, you can disable the wrapper:
|
|||
adb shell setprop wrap.org.libsdl.app ""
|
||||
|
||||
|
||||
================================================================================
|
||||
Graphics debugging
|
||||
Graphics debugging
|
||||
================================================================================
|
||||
|
||||
If you are developing on a compatible Tegra-based tablet, NVidia provides
|
||||
|
|
@ -398,8 +423,7 @@ The Tegra Graphics Debugger is available from NVidia here:
|
|||
https://developer.nvidia.com/tegra-graphics-debugger
|
||||
|
||||
|
||||
================================================================================
|
||||
Why is API level 16 the minimum required?
|
||||
Why is API level 16 the minimum required?
|
||||
================================================================================
|
||||
|
||||
The latest NDK toolchain doesn't support targeting earlier than API level 16.
|
||||
|
|
@ -408,8 +432,7 @@ about 99% of the Android devices accessing Google Play support API level 16 or
|
|||
higher (January 2018).
|
||||
|
||||
|
||||
================================================================================
|
||||
A note regarding the use of the "dirty rectangles" rendering technique
|
||||
A note regarding the use of the "dirty rectangles" rendering technique
|
||||
================================================================================
|
||||
|
||||
If your app uses a variation of the "dirty rectangles" rendering technique,
|
||||
|
|
@ -427,8 +450,7 @@ screen each frame.
|
|||
Reference: http://www.khronos.org/registry/egl/specs/EGLTechNote0001.html
|
||||
|
||||
|
||||
================================================================================
|
||||
Ending your application
|
||||
Ending your application
|
||||
================================================================================
|
||||
|
||||
Two legitimate ways:
|
||||
|
|
@ -445,8 +467,7 @@ Don't call exit() as it stops the activity badly.
|
|||
NB: "Back button" can be handled as a SDL_KEYDOWN/UP events, with Keycode
|
||||
SDLK_AC_BACK, for any purpose.
|
||||
|
||||
================================================================================
|
||||
Known issues
|
||||
Known issues
|
||||
================================================================================
|
||||
|
||||
- The number of buttons reported for each joystick is hardcoded to be 36, which
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
Dynamic API
|
||||
================================================================================
|
||||
Originally posted by Ryan at:
|
||||
https://plus.google.com/103391075724026391227/posts/TB8UfnDYu4U
|
||||
# Dynamic API
|
||||
|
||||
Originally posted on Ryan's Google+ account.
|
||||
|
||||
Background:
|
||||
|
||||
|
|
@ -35,10 +34,12 @@ So here's what we did:
|
|||
SDL now has, internally, a table of function pointers. So, this is what SDL_Init
|
||||
now looks like:
|
||||
|
||||
UInt32 SDL_Init(Uint32 flags)
|
||||
{
|
||||
return jump_table.SDL_Init(flags);
|
||||
}
|
||||
```c
|
||||
UInt32 SDL_Init(Uint32 flags)
|
||||
{
|
||||
return jump_table.SDL_Init(flags);
|
||||
}
|
||||
```
|
||||
|
||||
Except that is all done with a bunch of macro magic so we don't have to maintain
|
||||
every one of these.
|
||||
|
|
@ -47,22 +48,26 @@ What is jump_table.SDL_init()? Eventually, that's a function pointer of the real
|
|||
SDL_Init() that you've been calling all this time. But at startup, it looks more
|
||||
like this:
|
||||
|
||||
Uint32 SDL_Init_DEFAULT(Uint32 flags)
|
||||
{
|
||||
SDL_InitDynamicAPI();
|
||||
return jump_table.SDL_Init(flags);
|
||||
}
|
||||
```c
|
||||
Uint32 SDL_Init_DEFAULT(Uint32 flags)
|
||||
{
|
||||
SDL_InitDynamicAPI();
|
||||
return jump_table.SDL_Init(flags);
|
||||
}
|
||||
```
|
||||
|
||||
SDL_InitDynamicAPI() fills in jump_table with all the actual SDL function
|
||||
pointers, which means that this _DEFAULT function never gets called again.
|
||||
pointers, which means that this `_DEFAULT` function never gets called again.
|
||||
First call to any SDL function sets the whole thing up.
|
||||
|
||||
So you might be asking, what was the value in that? Isn't this what the operating
|
||||
system's dynamic loader was supposed to do for us? Yes, but now we've got this
|
||||
level of indirection, we can do things like this:
|
||||
|
||||
export SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0
|
||||
./MyGameThatIsStaticallyLinkedToSDL2
|
||||
```bash
|
||||
export SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0
|
||||
./MyGameThatIsStaticallyLinkedToSDL2
|
||||
```
|
||||
|
||||
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
|
||||
|
|
@ -94,7 +99,9 @@ SDL's function pointers (which might be statically linked into a program, or in
|
|||
a shared library of its own). If so, it loads that library and looks for and
|
||||
calls a single function:
|
||||
|
||||
SInt32 SDL_DYNAPI_entry(Uint32 version, void *table, Uint32 tablesize);
|
||||
```c
|
||||
SInt32 SDL_DYNAPI_entry(Uint32 version, void *table, Uint32 tablesize);
|
||||
```
|
||||
|
||||
That function takes a version number (more on that in a moment), the address of
|
||||
the jump table, and the size, in bytes, of the table.
|
||||
|
|
@ -116,6 +123,7 @@ Steam Client, this isn't a bad option.
|
|||
|
||||
Finally, I'm sure some people are reading this and thinking,
|
||||
"I don't want that overhead in my project!"
|
||||
|
||||
To which I would point out that the extra function call through the jump table
|
||||
probably wouldn't even show up in a profile, but lucky you: this can all be
|
||||
disabled. You can build SDL without this if you absolutely must, but we would
|
||||
|
|
|
|||
19
Engine/lib/sdl/docs/README-git.md
Normal file
19
Engine/lib/sdl/docs/README-git.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
git
|
||||
=========
|
||||
|
||||
The latest development version of SDL is available via git.
|
||||
Git allows you to get up-to-the-minute fixes and enhancements;
|
||||
as a developer works on a source tree, you can use "git" to mirror that
|
||||
source tree instead of waiting for an official release. Please look
|
||||
at the Git website ( https://git-scm.com/ ) for more
|
||||
information on using git, where you can also download software for
|
||||
macOS, Windows, and Unix systems.
|
||||
|
||||
git clone https://github.com/libsdl-org/SDL
|
||||
|
||||
If you are building SDL via configure, you will need to run autogen.sh
|
||||
before running configure.
|
||||
|
||||
There is a web interface to the Git repository at:
|
||||
http://github.com/libsdl-org/SDL/
|
||||
|
||||
|
|
@ -1,22 +1,4 @@
|
|||
Mercurial
|
||||
=========
|
||||
We are no longer hosted in Mercurial. Please see README-git.md for details.
|
||||
|
||||
The latest development version of SDL is available via Mercurial.
|
||||
Mercurial allows you to get up-to-the-minute fixes and enhancements;
|
||||
as a developer works on a source tree, you can use "hg" to mirror that
|
||||
source tree instead of waiting for an official release. Please look
|
||||
at the Mercurial website ( https://www.mercurial-scm.org/ ) for more
|
||||
information on using hg, where you can also download software for
|
||||
Mac OS X, Windows, and Unix systems.
|
||||
|
||||
hg clone http://hg.libsdl.org/SDL
|
||||
|
||||
If you are building SDL via configure, you will need to run autogen.sh
|
||||
before running configure.
|
||||
|
||||
There is a web interface to the subversion repository at:
|
||||
http://hg.libsdl.org/SDL/
|
||||
|
||||
There is an RSS feed available at that URL, for those that want to
|
||||
track commits in real time.
|
||||
Thanks!
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
iOS
|
||||
======
|
||||
|
||||
==============================================================================
|
||||
Building the Simple DirectMedia Layer for iOS 5.1+
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -9,57 +8,29 @@ Requirements: Mac OS X 10.8 or later and the iOS 7+ SDK.
|
|||
|
||||
Instructions:
|
||||
|
||||
1. Open SDL.xcodeproj (located in Xcode-iOS/SDL) in Xcode.
|
||||
2. Select your desired target, and hit build.
|
||||
|
||||
There are three build targets:
|
||||
- libSDL.a:
|
||||
Build SDL as a statically linked library
|
||||
- testsdl:
|
||||
Build a test program (there are known test failures which are fine)
|
||||
- Template:
|
||||
Package a project template together with the SDL for iPhone static libraries and copies of the SDL headers. The template includes proper references to the SDL library and headers, skeleton code for a basic SDL program, and placeholder graphics for the application icon and startup screen.
|
||||
1. Open SDL.xcodeproj (located in Xcode/SDL) in Xcode.
|
||||
2. Select your desired target, and hit build.
|
||||
|
||||
|
||||
==============================================================================
|
||||
Build SDL for iOS from the command line
|
||||
==============================================================================
|
||||
|
||||
1. cd (PATH WHERE THE SDL CODE IS)/build-scripts
|
||||
2. ./iosbuild.sh
|
||||
|
||||
If everything goes fine, you should see a build/ios directory, inside there's
|
||||
two directories "lib" and "include".
|
||||
"include" contains a copy of the SDL headers that you'll need for your project,
|
||||
make sure to configure XCode to look for headers there.
|
||||
"lib" contains find two files, libSDL2.a and libSDL2main.a, you have to add both
|
||||
to your XCode project. These libraries contain three architectures in them,
|
||||
armv6 for legacy devices, armv7, and i386 (for the simulator).
|
||||
By default, iosbuild.sh will autodetect the SDK version you have installed using
|
||||
xcodebuild -showsdks, and build for iOS >= 3.0, you can override this behaviour
|
||||
by setting the MIN_OS_VERSION variable, ie:
|
||||
|
||||
MIN_OS_VERSION=4.2 ./iosbuild.sh
|
||||
|
||||
==============================================================================
|
||||
Using the Simple DirectMedia Layer for iOS
|
||||
==============================================================================
|
||||
|
||||
FIXME: This needs to be updated for the latest methods
|
||||
1. Run Xcode and create a new project using the iOS Game template, selecting the Objective C language and Metal game technology.
|
||||
2. In the main view, delete all files except for Assets and LaunchScreen
|
||||
3. Right click the project in the main view, select "Add Files...", and add the SDL project, Xcode/SDL/SDL.xcodeproj
|
||||
4. Select the project in the main view, go to the "Info" tab and under "Custom iOS Target Properties" remove the line "Main storyboard file base name"
|
||||
5. Select the project in the main view, go to the "Build Settings" tab, select "All", and edit "Header Search Path" and drag over the SDL "Public Headers" folder from the left
|
||||
6. Select the project in the main view, go to the "Build Phases" tab, select "Link Binary With Libraries", and add SDL2.framework from "Framework-iOS"
|
||||
7. Select the project in the main view, go to the "General" tab, scroll down to "Frameworks, Libraries, and Embedded Content", and select "Embed & Sign" for the SDL library.
|
||||
8. In the main view, expand SDL -> Library Source -> main -> uikit and drag SDL_uikit_main.c into your game files
|
||||
9. Add the source files that you would normally have for an SDL program, making sure to have #include "SDL.h" at the top of the file containing your main() function.
|
||||
10. Add any assets that your application needs.
|
||||
11. Enjoy!
|
||||
|
||||
Here is the easiest method:
|
||||
1. Build the SDL library (libSDL2.a) and the iPhone SDL Application template.
|
||||
2. Install the iPhone SDL Application template by copying it to one of Xcode's template directories. I recommend creating a directory called "SDL" in "/Developer/Platforms/iOS.platform/Developer/Library/Xcode/Project Templates/" and placing it there.
|
||||
3. Start a new project using the template. The project should be immediately ready for use with SDL.
|
||||
|
||||
Here is a more manual method:
|
||||
1. Create a new iOS view based application.
|
||||
2. Build the SDL static library (libSDL2.a) for iOS and include them in your project. Xcode will ignore the library that is not currently of the correct architecture, hence your app will work both on iOS and in the iOS Simulator.
|
||||
3. Include the SDL header files in your project.
|
||||
4. Remove the ApplicationDelegate.h and ApplicationDelegate.m files -- SDL for iOS provides its own UIApplicationDelegate. Remove MainWindow.xib -- SDL for iOS produces its user interface programmatically.
|
||||
5. Delete the contents of main.m and program your app as a regular SDL program instead. You may replace main.m with your own main.c, but you must tell Xcode not to use the project prefix file, as it includes Objective-C code.
|
||||
TODO: Add information regarding App Store requirements such as icons, etc.
|
||||
|
||||
|
||||
==============================================================================
|
||||
Notes -- Retina / High-DPI and window sizes
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -88,7 +59,7 @@ orthographic projection matrix using the size in screen coordinates
|
|||
(SDL_GetWindowSize()) can be used in order to display content at the same scale
|
||||
no matter whether a Retina device is used or not.
|
||||
|
||||
==============================================================================
|
||||
|
||||
Notes -- Application events
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -151,7 +122,6 @@ e.g.
|
|||
}
|
||||
|
||||
|
||||
==============================================================================
|
||||
Notes -- Accelerometer as Joystick
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -159,7 +129,7 @@ SDL for iPhone supports polling the built in accelerometer as a joystick device.
|
|||
|
||||
The main thing to note when using the accelerometer with SDL is that while the iPhone natively reports accelerometer as floating point values in units of g-force, SDL_JoystickGetAxis() reports joystick values as signed integers. Hence, in order to convert between the two, some clamping and scaling is necessary on the part of the iPhone SDL joystick driver. To convert SDL_JoystickGetAxis() reported values BACK to units of g-force, simply multiply the values by SDL_IPHONE_MAX_GFORCE / 0x7FFF.
|
||||
|
||||
==============================================================================
|
||||
|
||||
Notes -- OpenGL ES
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -179,7 +149,7 @@ OpenGL ES on iOS doesn't use the traditional system-framebuffer setup provided i
|
|||
|
||||
The above objects can be obtained via SDL_GetWindowWMInfo() (in SDL_syswm.h).
|
||||
|
||||
==============================================================================
|
||||
|
||||
Notes -- Keyboard
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -195,7 +165,12 @@ SDL_bool SDL_IsTextInputActive()
|
|||
-- returns whether or not text events are enabled (and the onscreen keyboard is visible)
|
||||
|
||||
|
||||
Notes -- Mouse
|
||||
==============================================================================
|
||||
|
||||
iOS now supports Bluetooth mice on iPad, but by default will provide the mouse input as touch. In order for SDL to see the real mouse events, you should set the key UIApplicationSupportsIndirectInputEvents to true in your Info.plist
|
||||
|
||||
|
||||
Notes -- Reading and Writing files
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -215,7 +190,7 @@ When your SDL based iPhone application starts up, it sets the working directory
|
|||
More information on this subject is available here:
|
||||
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html
|
||||
|
||||
==============================================================================
|
||||
|
||||
Notes -- iPhone SDL limitations
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -228,7 +203,7 @@ Textures:
|
|||
Loading Shared Objects:
|
||||
This is disabled by default since it seems to break the terms of the iOS SDK agreement for iOS versions prior to iOS 8. It can be re-enabled in SDL_config_iphoneos.h.
|
||||
|
||||
==============================================================================
|
||||
|
||||
Notes -- CoreBluetooth.framework
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -244,7 +219,7 @@ to your Info.plist:
|
|||
<key>NSBluetoothPeripheralUsageDescription</key>
|
||||
<string>MyApp would like to remain connected to nearby bluetooth Game Controllers and Game Pads even when you're not using the app.</string>
|
||||
|
||||
==============================================================================
|
||||
|
||||
Game Center
|
||||
==============================================================================
|
||||
|
||||
|
|
@ -282,7 +257,7 @@ e.g.
|
|||
return 0;
|
||||
}
|
||||
|
||||
==============================================================================
|
||||
|
||||
Deploying to older versions of iOS
|
||||
==============================================================================
|
||||
|
||||
|
|
|
|||
27
Engine/lib/sdl/docs/README-kmsbsd.md
Normal file
27
Engine/lib/sdl/docs/README-kmsbsd.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
KMSDRM on *BSD
|
||||
==================================================
|
||||
|
||||
KMSDRM is supported on FreeBSD and OpenBSD. DragonFlyBSD works but requires being a root user. NetBSD isn't supported yet because the application will crash when creating the KMSDRM screen.
|
||||
|
||||
WSCONS support has been brought back, but only as an input backend. It will not be brought back as a video backend to ease maintenance.
|
||||
|
||||
OpenBSD note: Note that the video backend assumes that the user has read/write permissions to the /dev/drm* devices.
|
||||
|
||||
|
||||
SDL2 WSCONS input backend features
|
||||
===================================================
|
||||
1. It is keymap-aware; it will work properly with different keymaps.
|
||||
2. It has mouse support.
|
||||
3. Accent input is supported.
|
||||
4. Compose keys are supported.
|
||||
5. AltGr and Meta Shift keys work as intended.
|
||||
|
||||
Partially working or no input on OpenBSD/NetBSD.
|
||||
==================================================
|
||||
|
||||
The WSCONS input backend needs read/write access to the /dev/wskbd* devices, without which it will not work properly. /dev/wsmouse must also be read/write accessible, otherwise mouse input will not work.
|
||||
|
||||
Partially working or no input on FreeBSD.
|
||||
==================================================
|
||||
|
||||
The evdev devices are only accessible to the root user by default. Edit devfs rules to allow access to such devices. The /dev/kbd* devices are also only accessible to the root user by default. Edit devfs rules to allow access to such devices.
|
||||
|
|
@ -9,22 +9,35 @@ at runtime, and you won't get a missing library error, at least with the
|
|||
default configuration parameters.
|
||||
|
||||
|
||||
================================================================================
|
||||
Build Dependencies
|
||||
================================================================================
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
Ubuntu 20.04, all available features enabled:
|
||||
|
||||
sudo apt-get install build-essential mercurial make cmake autoconf automake \
|
||||
libtool libasound2-dev libpulse-dev libaudio-dev libx11-dev libxext-dev \
|
||||
libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxxf86vm-dev \
|
||||
libxss-dev libgl1-mesa-dev libdbus-1-dev libudev-dev libgles2-mesa-dev \
|
||||
libegl1-mesa-dev libibus-1.0-dev fcitx-libs-dev libsamplerate0-dev \
|
||||
libsndio-dev libwayland-dev libxkbcommon-dev
|
||||
sudo apt-get install build-essential git make cmake autoconf automake \
|
||||
libtool pkg-config libasound2-dev libpulse-dev libaudio-dev libjack-dev \
|
||||
libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxfixes-dev libxi-dev \
|
||||
libxinerama-dev libxxf86vm-dev libxss-dev libgl1-mesa-dev libdbus-1-dev \
|
||||
libudev-dev libgles2-mesa-dev libegl1-mesa-dev libibus-1.0-dev \
|
||||
fcitx-libs-dev libsamplerate0-dev libsndio-dev libwayland-dev \
|
||||
libxkbcommon-dev libdrm-dev libgbm-dev
|
||||
|
||||
Fedora 35, all available features enabled:
|
||||
|
||||
sudo yum install gcc git-core make cmake autoconf automake libtool \
|
||||
alsa-lib-devel pulseaudio-libs-devel nas-devel pipewire-devel \
|
||||
libX11-devel libXext-devel libXrandr-devel libXcursor-devel libXfixes-devel \
|
||||
libXi-devel libXinerama-devel libXxf86vm-devel libXScrnSaver-devel \
|
||||
dbus-devel ibus-devel fcitx-devel systemd-devel mesa-libGL-devel \
|
||||
libxkbcommon-devel mesa-libGLES-devel mesa-libEGL-devel vulkan-devel \
|
||||
wayland-devel wayland-protocols-devel libdrm-devel mesa-libgbm-devel \
|
||||
libusb-devel pipewire-jack-audio-connection-kit-devel libdecor-devel \
|
||||
libsamplerate-devel
|
||||
|
||||
NOTES:
|
||||
- This includes all the audio targets except arts and esd, because Ubuntu
|
||||
(and/or Debian) pulled their packages, but in theory SDL still supports them.
|
||||
The sndio audio target is also unavailable on Fedora.
|
||||
- libsamplerate0-dev lets SDL optionally link to libresamplerate at runtime
|
||||
for higher-quality audio resampling. SDL will work without it if the library
|
||||
is missing, so it's safe to build in support even if the end user doesn't
|
||||
|
|
@ -34,9 +47,8 @@ NOTES:
|
|||
configure script to include DirectFB support. Send patches. :)
|
||||
|
||||
|
||||
================================================================================
|
||||
Joystick does not work
|
||||
================================================================================
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
If you compiled or are using a version of SDL with udev support (and you should!)
|
||||
there's a few issues that may cause SDL to fail to detect your joystick. To
|
||||
|
|
@ -66,8 +78,8 @@ you need to set up an udev rule to force this variable.
|
|||
A combined rule for the Saitek Pro Flight Rudder Pedals to fix both issues looks
|
||||
like:
|
||||
|
||||
SUBSYSTEM=="input", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
|
||||
SUBSYSTEM=="input", ATTRS{idProduct}=="0764", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
|
||||
SUBSYSTEM=="input", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
|
||||
SUBSYSTEM=="input", ATTRS{idProduct}=="0764", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
|
||||
|
||||
You can set up similar rules for your device by changing the values listed in
|
||||
idProduct and idVendor. To obtain these values, try:
|
||||
|
|
|
|||
286
Engine/lib/sdl/docs/README-macos.md
Normal file
286
Engine/lib/sdl/docs/README-macos.md
Normal file
|
|
@ -0,0 +1,286 @@
|
|||
# Mac OS X (aka macOS).
|
||||
|
||||
These instructions are for people using Apple's Mac OS X (pronounced
|
||||
"ten"), which in newer versions is just referred to as "macOS".
|
||||
|
||||
From the developer's point of view, macOS is a sort of hybrid Mac and
|
||||
Unix system, and you have the option of using either traditional
|
||||
command line tools or Apple's IDE Xcode.
|
||||
|
||||
# Command Line Build
|
||||
|
||||
To build SDL using the command line, use the standard configure and make
|
||||
process:
|
||||
|
||||
```bash
|
||||
mkdir build
|
||||
cd build
|
||||
../configure
|
||||
make
|
||||
sudo make install
|
||||
```
|
||||
|
||||
CMake is also known to work, although it continues to be a work in progress:
|
||||
|
||||
```bash
|
||||
mkdir build
|
||||
cd build
|
||||
cmake -DCMAKE_BUILD_TYPE=Release ..
|
||||
make
|
||||
sudo make install
|
||||
```
|
||||
|
||||
|
||||
You can also build SDL as a Universal library (a single binary for both
|
||||
64-bit Intel and ARM architectures), by using the build-scripts/clang-fat.sh
|
||||
script.
|
||||
|
||||
```bash
|
||||
mkdir build
|
||||
cd build
|
||||
CC=$PWD/../build-scripts/clang-fat.sh ../configure
|
||||
make
|
||||
sudo make install
|
||||
```
|
||||
|
||||
This script builds SDL with 10.6 ABI compatibility on 64-bit Intel and 11.0
|
||||
ABI compatibility on ARM64 architectures. For best compatibility you
|
||||
should compile your application the same way.
|
||||
|
||||
Please note that building SDL requires at least Xcode 4.6 and the 10.7 SDK
|
||||
(even if you target back to 10.6 systems). PowerPC support for Mac OS X has
|
||||
been officially dropped as of SDL 2.0.2. 32-bit Intel, using an older Xcode
|
||||
release, is still supported at the time of this writing, but current Xcode
|
||||
releases no longer support it, and eventually neither will SDL.
|
||||
|
||||
To use the library once it's built, you essential have two possibilities:
|
||||
use the traditional autoconf/automake/make method, or use Xcode.
|
||||
|
||||
|
||||
# Caveats for using SDL with Mac OS X
|
||||
|
||||
If you register your own NSApplicationDelegate (using [NSApp setDelegate:]),
|
||||
SDL will not register its own. This means that SDL will not terminate using
|
||||
SDL_Quit if it receives a termination request, it will terminate like a
|
||||
normal app, and it will not send a SDL_DROPFILE when you request to open a
|
||||
file with the app. To solve these issues, put the following code in your
|
||||
NSApplicationDelegate implementation:
|
||||
|
||||
|
||||
```objc
|
||||
- (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
|
||||
{
|
||||
if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
|
||||
SDL_Event event;
|
||||
event.type = SDL_QUIT;
|
||||
SDL_PushEvent(&event);
|
||||
}
|
||||
|
||||
return NSTerminateCancel;
|
||||
}
|
||||
|
||||
- (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
|
||||
{
|
||||
if (SDL_GetEventState(SDL_DROPFILE) == SDL_ENABLE) {
|
||||
SDL_Event event;
|
||||
event.type = SDL_DROPFILE;
|
||||
event.drop.file = SDL_strdup([filename UTF8String]);
|
||||
return (SDL_PushEvent(&event) > 0);
|
||||
}
|
||||
|
||||
return NO;
|
||||
}
|
||||
```
|
||||
|
||||
# Using the Simple DirectMedia Layer with a traditional Makefile
|
||||
|
||||
An existing autoconf/automake build system for your SDL app has good chances
|
||||
to work almost unchanged on macOS. However, to produce a "real" Mac binary
|
||||
that you can distribute to users, you need to put the generated binary into a
|
||||
so called "bundle", which is basically a fancy folder with a name like
|
||||
"MyCoolGame.app".
|
||||
|
||||
To get this build automatically, add something like the following rule to
|
||||
your Makefile.am:
|
||||
|
||||
```make
|
||||
bundle_contents = APP_NAME.app/Contents
|
||||
APP_NAME_bundle: EXE_NAME
|
||||
mkdir -p $(bundle_contents)/MacOS
|
||||
mkdir -p $(bundle_contents)/Resources
|
||||
echo "APPL????" > $(bundle_contents)/PkgInfo
|
||||
$(INSTALL_PROGRAM) $< $(bundle_contents)/MacOS/
|
||||
```
|
||||
|
||||
You should replace `EXE_NAME` with the name of the executable. `APP_NAME` is
|
||||
what will be visible to the user in the Finder. Usually it will be the same
|
||||
as `EXE_NAME` but capitalized. E.g. if `EXE_NAME` is "testgame" then `APP_NAME`
|
||||
usually is "TestGame". You might also want to use `@PACKAGE@` to use the
|
||||
package name as specified in your configure.ac file.
|
||||
|
||||
If your project builds more than one application, you will have to do a bit
|
||||
more. For each of your target applications, you need a separate rule.
|
||||
|
||||
If you want the created bundles to be installed, you may want to add this
|
||||
rule to your Makefile.am:
|
||||
|
||||
```make
|
||||
install-exec-hook: APP_NAME_bundle
|
||||
rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
|
||||
mkdir -p $(DESTDIR)$(prefix)/Applications/
|
||||
cp -r $< /$(DESTDIR)$(prefix)Applications/
|
||||
```
|
||||
|
||||
This rule takes the Bundle created by the rule from step 3 and installs them
|
||||
into "$(DESTDIR)$(prefix)/Applications/".
|
||||
|
||||
Again, if you want to install multiple applications, you will have to augment
|
||||
the make rule accordingly.
|
||||
|
||||
But beware! That is only part of the story! With the above, you end up with
|
||||
a barebones .app bundle, which is double-clickable from the Finder. But
|
||||
there are some more things you should do before shipping your product...
|
||||
|
||||
1. The bundle right now probably is dynamically linked against SDL. That
|
||||
means that when you copy it to another computer, *it will not run*,
|
||||
unless you also install SDL on that other computer. A good solution
|
||||
for this dilemma is to static link against SDL. On OS X, you can
|
||||
achieve that by linking against the libraries listed by
|
||||
|
||||
```bash
|
||||
sdl-config --static-libs
|
||||
```
|
||||
|
||||
instead of those listed by
|
||||
|
||||
```bash
|
||||
sdl-config --libs
|
||||
```
|
||||
|
||||
Depending on how exactly SDL is integrated into your build systems, the
|
||||
way to achieve that varies, so I won't describe it here in detail
|
||||
|
||||
2. Add an 'Info.plist' to your application. That is a special XML file which
|
||||
contains some meta-information about your application (like some copyright
|
||||
information, the version of your app, the name of an optional icon file,
|
||||
and other things). Part of that information is displayed by the Finder
|
||||
when you click on the .app, or if you look at the "Get Info" window.
|
||||
More information about Info.plist files can be found on Apple's homepage.
|
||||
|
||||
|
||||
As a final remark, let me add that I use some of the techniques (and some
|
||||
variations of them) in [Exult](https://github.com/exult/exult) and
|
||||
[ScummVM](https://github.com/scummvm/scummvm); both are available in source on
|
||||
the net, so feel free to take a peek at them for inspiration!
|
||||
|
||||
|
||||
# Using the Simple DirectMedia Layer with Xcode
|
||||
|
||||
These instructions are for using Apple's Xcode IDE to build SDL applications.
|
||||
|
||||
## First steps
|
||||
|
||||
The first thing to do is to unpack the Xcode.tar.gz archive in the
|
||||
top level SDL directory (where the Xcode.tar.gz archive resides).
|
||||
Because Stuffit Expander will unpack the archive into a subdirectory,
|
||||
you should unpack the archive manually from the command line:
|
||||
|
||||
```bash
|
||||
cd [path_to_SDL_source]
|
||||
tar zxf Xcode.tar.gz
|
||||
```
|
||||
|
||||
This will create a new folder called Xcode, which you can browse
|
||||
normally from the Finder.
|
||||
|
||||
## Building the Framework
|
||||
|
||||
The SDL Library is packaged as a framework bundle, an organized
|
||||
relocatable folder hierarchy of executable code, interface headers,
|
||||
and additional resources. For practical purposes, you can think of a
|
||||
framework as a more user and system-friendly shared library, whose library
|
||||
file behaves more or less like a standard UNIX shared library.
|
||||
|
||||
To build the framework, simply open the framework project and build it.
|
||||
By default, the framework bundle "SDL.framework" is installed in
|
||||
/Library/Frameworks. Therefore, the testers and project stationary expect
|
||||
it to be located there. However, it will function the same in any of the
|
||||
following locations:
|
||||
|
||||
* ~/Library/Frameworks
|
||||
* /Local/Library/Frameworks
|
||||
* /System/Library/Frameworks
|
||||
|
||||
## Build Options
|
||||
|
||||
There are two "Build Styles" (See the "Targets" tab) for SDL.
|
||||
"Deployment" should be used if you aren't tweaking the SDL library.
|
||||
"Development" should be used to debug SDL apps or the library itself.
|
||||
|
||||
## Building the Testers
|
||||
|
||||
Open the SDLTest project and build away!
|
||||
|
||||
## Using the Project Stationary
|
||||
|
||||
Copy the stationary to the indicated folders to access it from
|
||||
the "New Project" and "Add target" menus. What could be easier?
|
||||
|
||||
## Setting up a new project by hand
|
||||
|
||||
Some of you won't want to use the Stationary so I'll give some tips:
|
||||
|
||||
(this is accurate as of Xcode 12.5.)
|
||||
|
||||
* Click "File" -> "New" -> "Project...
|
||||
* Choose "macOS" and then "App" from the "Application" section.
|
||||
* Fill out the options in the next window. User interface is "XIB" and
|
||||
Language is "Objective-C".
|
||||
* Remove "main.m" from your project
|
||||
* Remove "MainMenu.xib" from your project
|
||||
* Remove "AppDelegates.*" from your project
|
||||
* Add "\$(HOME)/Library/Frameworks/SDL.framework/Headers" to include path
|
||||
* Add "\$(HOME)/Library/Frameworks" to the frameworks search path
|
||||
* Add "-framework SDL -framework Foundation -framework AppKit" to "OTHER_LDFLAGS"
|
||||
* Add your files
|
||||
* Clean and build
|
||||
|
||||
## Building from command line
|
||||
|
||||
Use `xcode-build` in the same directory as your .pbxproj file
|
||||
|
||||
## Running your app
|
||||
|
||||
You can send command line args to your app by either invoking it from
|
||||
the command line (in *.app/Contents/MacOS) or by entering them in the
|
||||
Executables" panel of the target settings.
|
||||
|
||||
# Implementation Notes
|
||||
|
||||
Some things that may be of interest about how it all works...
|
||||
|
||||
## Working directory
|
||||
|
||||
In SDL 1.2, the working directory of your SDL app is by default set to its
|
||||
parent, but this is no longer the case in SDL 2.0. SDL2 does change the
|
||||
working directory, which means it'll be whatever the command line prompt
|
||||
that launched the program was using, or if launched by double-clicking in
|
||||
the finger, it will be "/", the _root of the filesystem_. Plan accordingly!
|
||||
You can use SDL_GetBasePath() to find where the program is running from and
|
||||
chdir() there directly.
|
||||
|
||||
|
||||
## You have a Cocoa App!
|
||||
|
||||
Your SDL app is essentially a Cocoa application. When your app
|
||||
starts up and the libraries finish loading, a Cocoa procedure is called,
|
||||
which sets up the working directory and calls your main() method.
|
||||
You are free to modify your Cocoa app with generally no consequence
|
||||
to SDL. You cannot, however, easily change the SDL window itself.
|
||||
Functionality may be added in the future to help this.
|
||||
|
||||
# Bug reports
|
||||
|
||||
Bugs are tracked at [the GitHub issue tracker](https://github.com/libsdl-org/SDL/issues/).
|
||||
Please feel free to report bugs there!
|
||||
|
||||
|
|
@ -1,240 +0,0 @@
|
|||
Mac OS X
|
||||
==============================================================================
|
||||
|
||||
These instructions are for people using Apple's Mac OS X (pronounced
|
||||
"ten").
|
||||
|
||||
From the developer's point of view, OS X is a sort of hybrid Mac and
|
||||
Unix system, and you have the option of using either traditional
|
||||
command line tools or Apple's IDE Xcode.
|
||||
|
||||
Command Line Build
|
||||
==================
|
||||
|
||||
To build SDL using the command line, use the standard configure and make
|
||||
process:
|
||||
|
||||
./configure
|
||||
make
|
||||
sudo make install
|
||||
|
||||
You can also build SDL as a Universal library (a single binary for both
|
||||
32-bit and 64-bit Intel architectures), on Mac OS X 10.7 and newer, by using
|
||||
the gcc-fat.sh script in build-scripts:
|
||||
|
||||
mkdir mybuild
|
||||
cd mybuild
|
||||
CC=$PWD/../build-scripts/gcc-fat.sh CXX=$PWD/../build-scripts/g++-fat.sh ../configure
|
||||
make
|
||||
sudo make install
|
||||
|
||||
This script builds SDL with 10.5 ABI compatibility on i386 and 10.6
|
||||
ABI compatibility on x86_64 architectures. For best compatibility you
|
||||
should compile your application the same way.
|
||||
|
||||
Please note that building SDL requires at least Xcode 4.6 and the 10.7 SDK
|
||||
(even if you target back to 10.5 systems). PowerPC support for Mac OS X has
|
||||
been officially dropped as of SDL 2.0.2.
|
||||
|
||||
To use the library once it's built, you essential have two possibilities:
|
||||
use the traditional autoconf/automake/make method, or use Xcode.
|
||||
|
||||
==============================================================================
|
||||
Caveats for using SDL with Mac OS X
|
||||
==============================================================================
|
||||
|
||||
Some things you have to be aware of when using SDL on Mac OS X:
|
||||
|
||||
- If you register your own NSApplicationDelegate (using [NSApp setDelegate:]),
|
||||
SDL will not register its own. This means that SDL will not terminate using
|
||||
SDL_Quit if it receives a termination request, it will terminate like a
|
||||
normal app, and it will not send a SDL_DROPFILE when you request to open a
|
||||
file with the app. To solve these issues, put the following code in your
|
||||
NSApplicationDelegate implementation:
|
||||
|
||||
|
||||
- (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
|
||||
{
|
||||
if (SDL_GetEventState(SDL_QUIT) == SDL_ENABLE) {
|
||||
SDL_Event event;
|
||||
event.type = SDL_QUIT;
|
||||
SDL_PushEvent(&event);
|
||||
}
|
||||
|
||||
return NSTerminateCancel;
|
||||
}
|
||||
|
||||
- (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
|
||||
{
|
||||
if (SDL_GetEventState(SDL_DROPFILE) == SDL_ENABLE) {
|
||||
SDL_Event event;
|
||||
event.type = SDL_DROPFILE;
|
||||
event.drop.file = SDL_strdup([filename UTF8String]);
|
||||
return (SDL_PushEvent(&event) > 0);
|
||||
}
|
||||
|
||||
return NO;
|
||||
}
|
||||
|
||||
==============================================================================
|
||||
Using the Simple DirectMedia Layer with a traditional Makefile
|
||||
==============================================================================
|
||||
|
||||
An existing autoconf/automake build system for your SDL app has good chances
|
||||
to work almost unchanged on OS X. However, to produce a "real" Mac OS X binary
|
||||
that you can distribute to users, you need to put the generated binary into a
|
||||
so called "bundle", which basically is a fancy folder with a name like
|
||||
"MyCoolGame.app".
|
||||
|
||||
To get this build automatically, add something like the following rule to
|
||||
your Makefile.am:
|
||||
|
||||
bundle_contents = APP_NAME.app/Contents
|
||||
APP_NAME_bundle: EXE_NAME
|
||||
mkdir -p $(bundle_contents)/MacOS
|
||||
mkdir -p $(bundle_contents)/Resources
|
||||
echo "APPL????" > $(bundle_contents)/PkgInfo
|
||||
$(INSTALL_PROGRAM) $< $(bundle_contents)/MacOS/
|
||||
|
||||
You should replace EXE_NAME with the name of the executable. APP_NAME is what
|
||||
will be visible to the user in the Finder. Usually it will be the same
|
||||
as EXE_NAME but capitalized. E.g. if EXE_NAME is "testgame" then APP_NAME
|
||||
usually is "TestGame". You might also want to use `@PACKAGE@` to use the package
|
||||
name as specified in your configure.ac file.
|
||||
|
||||
If your project builds more than one application, you will have to do a bit
|
||||
more. For each of your target applications, you need a separate rule.
|
||||
|
||||
If you want the created bundles to be installed, you may want to add this
|
||||
rule to your Makefile.am:
|
||||
|
||||
install-exec-hook: APP_NAME_bundle
|
||||
rm -rf $(DESTDIR)$(prefix)/Applications/APP_NAME.app
|
||||
mkdir -p $(DESTDIR)$(prefix)/Applications/
|
||||
cp -r $< /$(DESTDIR)$(prefix)Applications/
|
||||
|
||||
This rule takes the Bundle created by the rule from step 3 and installs them
|
||||
into "$(DESTDIR)$(prefix)/Applications/".
|
||||
|
||||
Again, if you want to install multiple applications, you will have to augment
|
||||
the make rule accordingly.
|
||||
|
||||
|
||||
But beware! That is only part of the story! With the above, you end up with
|
||||
a bare bone .app bundle, which is double clickable from the Finder. But
|
||||
there are some more things you should do before shipping your product...
|
||||
|
||||
1) The bundle right now probably is dynamically linked against SDL. That
|
||||
means that when you copy it to another computer, *it will not run*,
|
||||
unless you also install SDL on that other computer. A good solution
|
||||
for this dilemma is to static link against SDL. On OS X, you can
|
||||
achieve that by linking against the libraries listed by
|
||||
|
||||
sdl-config --static-libs
|
||||
|
||||
instead of those listed by
|
||||
|
||||
sdl-config --libs
|
||||
|
||||
Depending on how exactly SDL is integrated into your build systems, the
|
||||
way to achieve that varies, so I won't describe it here in detail
|
||||
|
||||
2) Add an 'Info.plist' to your application. That is a special XML file which
|
||||
contains some meta-information about your application (like some copyright
|
||||
information, the version of your app, the name of an optional icon file,
|
||||
and other things). Part of that information is displayed by the Finder
|
||||
when you click on the .app, or if you look at the "Get Info" window.
|
||||
More information about Info.plist files can be found on Apple's homepage.
|
||||
|
||||
|
||||
As a final remark, let me add that I use some of the techniques (and some
|
||||
variations of them) in Exult and ScummVM; both are available in source on
|
||||
the net, so feel free to take a peek at them for inspiration!
|
||||
|
||||
|
||||
==============================================================================
|
||||
Using the Simple DirectMedia Layer with Xcode
|
||||
==============================================================================
|
||||
|
||||
These instructions are for using Apple's Xcode IDE to build SDL applications.
|
||||
|
||||
- First steps
|
||||
|
||||
The first thing to do is to unpack the Xcode.tar.gz archive in the
|
||||
top level SDL directory (where the Xcode.tar.gz archive resides).
|
||||
Because Stuffit Expander will unpack the archive into a subdirectory,
|
||||
you should unpack the archive manually from the command line:
|
||||
|
||||
cd [path_to_SDL_source]
|
||||
tar zxf Xcode.tar.gz
|
||||
|
||||
This will create a new folder called Xcode, which you can browse
|
||||
normally from the Finder.
|
||||
|
||||
- Building the Framework
|
||||
|
||||
The SDL Library is packaged as a framework bundle, an organized
|
||||
relocatable folder hierarchy of executable code, interface headers,
|
||||
and additional resources. For practical purposes, you can think of a
|
||||
framework as a more user and system-friendly shared library, whose library
|
||||
file behaves more or less like a standard UNIX shared library.
|
||||
|
||||
To build the framework, simply open the framework project and build it.
|
||||
By default, the framework bundle "SDL.framework" is installed in
|
||||
/Library/Frameworks. Therefore, the testers and project stationary expect
|
||||
it to be located there. However, it will function the same in any of the
|
||||
following locations:
|
||||
|
||||
~/Library/Frameworks
|
||||
/Local/Library/Frameworks
|
||||
/System/Library/Frameworks
|
||||
|
||||
- Build Options
|
||||
There are two "Build Styles" (See the "Targets" tab) for SDL.
|
||||
"Deployment" should be used if you aren't tweaking the SDL library.
|
||||
"Development" should be used to debug SDL apps or the library itself.
|
||||
|
||||
- Building the Testers
|
||||
Open the SDLTest project and build away!
|
||||
|
||||
- Using the Project Stationary
|
||||
Copy the stationary to the indicated folders to access it from
|
||||
the "New Project" and "Add target" menus. What could be easier?
|
||||
|
||||
- Setting up a new project by hand
|
||||
Some of you won't want to use the Stationary so I'll give some tips:
|
||||
* Create a new "Cocoa Application"
|
||||
* Add src/main/macosx/SDLMain.m , .h and .nib to your project
|
||||
* Remove "main.c" from your project
|
||||
* Remove "MainMenu.nib" from your project
|
||||
* Add "$(HOME)/Library/Frameworks/SDL.framework/Headers" to include path
|
||||
* Add "$(HOME)/Library/Frameworks" to the frameworks search path
|
||||
* Add "-framework SDL -framework Foundation -framework AppKit" to "OTHER_LDFLAGS"
|
||||
* Set the "Main Nib File" under "Application Settings" to "SDLMain.nib"
|
||||
* Add your files
|
||||
* Clean and build
|
||||
|
||||
- Building from command line
|
||||
Use pbxbuild in the same directory as your .pbproj file
|
||||
|
||||
- Running your app
|
||||
You can send command line args to your app by either invoking it from
|
||||
the command line (in *.app/Contents/MacOS) or by entering them in the
|
||||
"Executables" panel of the target settings.
|
||||
|
||||
- Implementation Notes
|
||||
Some things that may be of interest about how it all works...
|
||||
* Working directory
|
||||
As defined in the SDL_main.m file, the working directory of your SDL app
|
||||
is by default set to its parent. You may wish to change this to better
|
||||
suit your needs.
|
||||
* You have a Cocoa App!
|
||||
Your SDL app is essentially a Cocoa application. When your app
|
||||
starts up and the libraries finish loading, a Cocoa procedure is called,
|
||||
which sets up the working directory and calls your main() method.
|
||||
You are free to modify your Cocoa app with generally no consequence
|
||||
to SDL. You cannot, however, easily change the SDL window itself.
|
||||
Functionality may be added in the future to help this.
|
||||
|
||||
|
||||
Known bugs are listed in the file "BUGS.txt".
|
||||
|
|
@ -3,9 +3,9 @@ Simple DirectMedia Layer 2 for OS/2 & eComStation
|
|||
SDL port for OS/2, authored by Andrey Vasilkin <digi@os2.snc.ru>, 2016
|
||||
|
||||
|
||||
OpenGL, joystick and audio capture not supported by this port.
|
||||
OpenGL and audio capture not supported by this port.
|
||||
|
||||
Additional environment variables (optional) for OS/2 version:
|
||||
Additional optional environment variables:
|
||||
|
||||
SDL_AUDIO_SHARE
|
||||
Values: 0 or 1, default is 0
|
||||
|
|
@ -33,7 +33,7 @@ Compiling:
|
|||
|
||||
Open Watcom 1.9 or newer is tested. For the new Open Watcom V2 fork, see:
|
||||
https://github.com/open-watcom/ and https://open-watcom.github.io
|
||||
WATCOM ervironment variable must to be set to the Open Watcom install
|
||||
WATCOM environment variable must to be set to the Open Watcom install
|
||||
directory. To compile, run: wmake -f Makefile.os2
|
||||
|
||||
|
||||
|
|
@ -52,3 +52,41 @@ Installing:
|
|||
version installed, close all SDL2 applications before replacing the old
|
||||
copy. Also make sure that any other older versions of DLLs are removed
|
||||
from your system.
|
||||
|
||||
|
||||
Joysticks in SDL2:
|
||||
------------------
|
||||
|
||||
The joystick code in SDL2 is a direct forward-port from the SDL-1.2 version.
|
||||
Here is the original documentation from SDL-1.2:
|
||||
|
||||
The Joystick detection only works for standard joysticks (2 buttons, 2 axes
|
||||
and the like). Therefore, if you use a non-standard joystick, you should
|
||||
specify its features in the SDL_OS2_JOYSTICK environment variable in a batch
|
||||
file or CONFIG.SYS, so SDL applications can provide full capability to your
|
||||
device. The syntax is:
|
||||
|
||||
SET SDL_OS2_JOYSTICK=[JOYSTICK_NAME] [AXES] [BUTTONS] [HATS] [BALLS]
|
||||
|
||||
So, it you have a Gravis GamePad with 4 axes, 2 buttons, 2 hats and 0 balls,
|
||||
the line should be:
|
||||
|
||||
SET SDL_OS2_JOYSTICK=Gravis_GamePad 4 2 2 0
|
||||
|
||||
If you want to add spaces in your joystick name, just surround it with
|
||||
quotes or double-quotes:
|
||||
|
||||
SET SDL_OS2_JOYSTICK='Gravis GamePad' 4 2 2 0
|
||||
|
||||
or
|
||||
|
||||
SET SDL_OS2_JOYSTICK="Gravis GamePad" 4 2 2 0
|
||||
|
||||
Note however that Balls and Hats are not supported under OS/2, and the
|
||||
value will be ignored... but it is wise to define these correctly because
|
||||
in the future those can be supported.
|
||||
|
||||
Also the number of buttons is limited to 2 when using two joysticks,
|
||||
4 when using one joystick with 4 axes, 6 when using a joystick with 3 axes
|
||||
and 8 when using a joystick with 2 axes. Notice however these are limitations
|
||||
of the Joystick Port hardware, not OS/2.
|
||||
|
|
|
|||
|
|
@ -1,19 +1,36 @@
|
|||
PSP
|
||||
======
|
||||
SDL port for the Sony PSP contributed by
|
||||
Captian Lex
|
||||
SDL2 port for the Sony PSP contributed by:
|
||||
- Captian Lex
|
||||
- Francisco Javier Trujillo Mata
|
||||
- Wouter Wijsman
|
||||
|
||||
|
||||
Credit to
|
||||
Marcus R.Brown,Jim Paris,Matthew H for the original SDL 1.2 for PSP
|
||||
Geecko for his PSP GU lib "Glib2d"
|
||||
|
||||
Building
|
||||
--------
|
||||
To build for the PSP, make sure psp-config is in the path and run:
|
||||
make -f Makefile.psp
|
||||
## Building
|
||||
To build SDL2 library for the PSP, make sure you have the latest PSPDev status and run:
|
||||
```bash
|
||||
cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=$PSPDEV/psp/share/pspdev.cmake
|
||||
cmake --build build
|
||||
cmake --install build
|
||||
```
|
||||
|
||||
|
||||
## Getting PSP Dev
|
||||
[Installing PSP Dev](https://github.com/pspdev/pspdev)
|
||||
|
||||
To Do
|
||||
------
|
||||
PSP Screen Keyboard
|
||||
## Running on PPSSPP Emulator
|
||||
[PPSSPP](https://github.com/hrydgard/ppsspp)
|
||||
|
||||
[Build Instructions](https://github.com/hrydgard/ppsspp/wiki/Build-instructions)
|
||||
|
||||
|
||||
## Compiling a HelloWorld
|
||||
[PSP Hello World](https://psp-dev.org/doku.php?id=tutorial:hello_world)
|
||||
|
||||
## To Do
|
||||
- PSP Screen Keyboard
|
||||
- Dialogs
|
||||
|
|
@ -1,13 +1,12 @@
|
|||
Raspberry Pi
|
||||
================================================================================
|
||||
============
|
||||
|
||||
Requirements:
|
||||
|
||||
Raspbian (other Linux distros may work as well).
|
||||
|
||||
================================================================================
|
||||
Features
|
||||
================================================================================
|
||||
Features
|
||||
--------
|
||||
|
||||
* Works without X11
|
||||
* Hardware accelerated OpenGL ES 2.x
|
||||
|
|
@ -16,9 +15,8 @@ Raspbian (other Linux distros may work as well).
|
|||
* Hotplugging of input devices via UDEV
|
||||
|
||||
|
||||
================================================================================
|
||||
Raspbian Build Dependencies
|
||||
================================================================================
|
||||
Raspbian Build Dependencies
|
||||
---------------------------
|
||||
|
||||
sudo apt-get install libudev-dev libasound2-dev libdbus-1-dev
|
||||
|
||||
|
|
@ -28,18 +26,17 @@ OpenGL ES 2.x, it usually comes pre-installed, but in any case:
|
|||
sudo apt-get install libraspberrypi0 libraspberrypi-bin libraspberrypi-dev
|
||||
|
||||
|
||||
================================================================================
|
||||
NEON
|
||||
================================================================================
|
||||
NEON
|
||||
----
|
||||
|
||||
If your Pi has NEON support, make sure you add -mfpu=neon to your CFLAGS so
|
||||
that SDL will select some otherwise-disabled highly-optimized code. The
|
||||
original Pi units don't have NEON, the Pi2 probably does, and the Pi3
|
||||
definitely does.
|
||||
|
||||
================================================================================
|
||||
Cross compiling from x86 Linux
|
||||
================================================================================
|
||||
|
||||
Cross compiling from x86 Linux
|
||||
------------------------------
|
||||
|
||||
To cross compile SDL for Raspbian from your desktop machine, you'll need a
|
||||
Raspbian system root and the cross compilation tools. We'll assume these tools
|
||||
|
|
@ -92,9 +89,8 @@ To be able to deploy this to /usr/local in the Raspbian system you need to fix u
|
|||
|
||||
perl -w -pi -e "s#$PWD/rpi-sdl2-installed#/usr/local#g;" ./rpi-sdl2-installed/lib/libSDL2.la ./rpi-sdl2-installed/lib/pkgconfig/sdl2.pc ./rpi-sdl2-installed/bin/sdl2-config
|
||||
|
||||
================================================================================
|
||||
Apps don't work or poor video/audio performance
|
||||
================================================================================
|
||||
Apps don't work or poor video/audio performance
|
||||
-----------------------------------------------
|
||||
|
||||
If you get sound problems, buffer underruns, etc, run "sudo rpi-update" to
|
||||
update the RPi's firmware. Note that doing so will fix these problems, but it
|
||||
|
|
@ -108,17 +104,15 @@ See here how to configure this setting: http://elinux.org/RPiconfig
|
|||
Using a fixed gpu_mem=128 is the best option (specially if you updated the
|
||||
firmware, using CMA probably won't work, at least it's the current case).
|
||||
|
||||
================================================================================
|
||||
No input
|
||||
================================================================================
|
||||
No input
|
||||
--------
|
||||
|
||||
Make sure you belong to the "input" group.
|
||||
|
||||
sudo usermod -aG input `whoami`
|
||||
|
||||
================================================================================
|
||||
No HDMI Audio
|
||||
================================================================================
|
||||
No HDMI Audio
|
||||
-------------
|
||||
|
||||
If you notice that ALSA works but there's no audio over HDMI, try adding:
|
||||
|
||||
|
|
@ -128,9 +122,8 @@ to your config.txt file and reboot.
|
|||
|
||||
Reference: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=5062
|
||||
|
||||
================================================================================
|
||||
Text Input API support
|
||||
================================================================================
|
||||
Text Input API support
|
||||
----------------------
|
||||
|
||||
The Text Input API is supported, with translation of scan codes done via the
|
||||
kernel symbol tables. For this to work, SDL needs access to a valid console.
|
||||
|
|
@ -160,9 +153,9 @@ this determining the CAPS LOCK behavior:
|
|||
|
||||
sudo dpkg-reconfigure locales
|
||||
|
||||
================================================================================
|
||||
OpenGL problems
|
||||
================================================================================
|
||||
|
||||
OpenGL problems
|
||||
---------------
|
||||
|
||||
If you have desktop OpenGL headers installed at build time in your RPi or cross
|
||||
compilation environment, support for it will be built in. However, the chipset
|
||||
|
|
@ -177,9 +170,8 @@ environment variable:
|
|||
|
||||
export SDL_RENDER_DRIVER=opengles2
|
||||
|
||||
================================================================================
|
||||
Notes
|
||||
================================================================================
|
||||
Notes
|
||||
-----
|
||||
|
||||
* When launching apps remotely (via SSH), SDL can prevent local keystrokes from
|
||||
leaking into the console only if it has root privileges. Launching apps locally
|
||||
|
|
|
|||
41
Engine/lib/sdl/docs/README-riscos.md
Normal file
41
Engine/lib/sdl/docs/README-riscos.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
RISC OS
|
||||
=======
|
||||
|
||||
Requirements:
|
||||
|
||||
* RISC OS 3.5 or later.
|
||||
* [SharedUnixLibrary](http://www.riscos.info/packages/LibraryDetails.html#SharedUnixLibraryarm).
|
||||
* [DigitalRenderer](http://www.riscos.info/packages/LibraryDetails.html#DRendererarm), for audio support.
|
||||
* [Iconv](http://www.netsurf-browser.org/projects/iconv/), for `SDL_iconv` and related functions.
|
||||
|
||||
|
||||
Compiling:
|
||||
----------
|
||||
|
||||
Currently, SDL2 for RISC OS only supports compiling with GCCSDK under Linux. Both the autoconf and CMake build systems are supported.
|
||||
|
||||
The following commands can be used to build SDL2 for RISC OS using autoconf:
|
||||
|
||||
./configure --host=arm-unknown-riscos --prefix=$GCCSDK_INSTALL_ENV --disable-gcc-atomics
|
||||
make
|
||||
make install
|
||||
|
||||
The following commands can be used to build SDL2 for RISC OS using CMake:
|
||||
|
||||
cmake -Bbuild-riscos -DCMAKE_TOOLCHAIN_FILE=$GCCSDK_INSTALL_ENV/toolchain-riscos.cmake -DRISCOS=ON -DCMAKE_INSTALL_PREFIX=$GCCSDK_INSTALL_ENV -DCMAKE_BUILD_TYPE=Release -DSDL_GCC_ATOMICS=OFF
|
||||
cmake --build build-riscos
|
||||
cmake --build build-riscos --target install
|
||||
|
||||
|
||||
Current level of implementation
|
||||
-------------------------------
|
||||
|
||||
The video driver currently provides full screen video support with keyboard and mouse input. Windowed mode is not yet supported, but is planned in the future. Only software rendering is supported.
|
||||
|
||||
The filesystem APIs return either Unix-style paths or RISC OS-style paths based on the value of the `__riscosify_control` symbol, as is standard for UnixLib functions.
|
||||
|
||||
The audio, loadso, thread and timer APIs are currently provided by UnixLib.
|
||||
|
||||
GCC atomics are currently broken on some platforms, meaning it's currently necessary to compile with `--disable-gcc-atomics` using autotools or `-DSDL_GCC_ATOMICS=OFF` using CMake.
|
||||
|
||||
The joystick, locale and power APIs are not yet implemented.
|
||||
114
Engine/lib/sdl/docs/README-visualc.md
Normal file
114
Engine/lib/sdl/docs/README-visualc.md
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
Using SDL with Microsoft Visual C++
|
||||
===================================
|
||||
|
||||
### by [Lion Kimbro](mailto:snowlion@sprynet.com) with additions by [James Turk](mailto:james@conceptofzero.net)
|
||||
|
||||
You can either use the precompiled libraries from the [SDL](https://www.libsdl.org/download.php) web site, or you can build SDL
|
||||
yourself.
|
||||
|
||||
### Building SDL
|
||||
|
||||
0. To build SDL, your machine must, at a minimum, have the DirectX9.0c SDK installed. It may or may not be retrievable from
|
||||
the [Microsoft](https://www.microsoft.com) website, so you might need to locate it [online](https://duckduckgo.com/?q=directx9.0c+sdk+download&t=h_&ia=web).
|
||||
_Editor's note: I've been able to successfully build SDL using Visual Studio 2019 **without** the DX9.0c SDK_
|
||||
|
||||
1. Open the Visual Studio solution file at `./VisualC/SDL.sln`.
|
||||
|
||||
2. Your IDE will likely prompt you to upgrade this solution file to whatever later version of the IDE you're using. In the `Retarget Projects` dialog,
|
||||
all of the affected project files should be checked allowing you to use the latest `Windows SDK Version` you have installed, along with
|
||||
the `Platform Toolset`.
|
||||
|
||||
If you choose *NOT* to upgrade to use the latest `Windows SDK Version` or `Platform Toolset`, then you'll need the `Visual Studio 2010 Platform Toolset`.
|
||||
|
||||
3. Build the `.dll` and `.lib` files by right clicking on each project in turn (Projects are listed in the _Workspace_
|
||||
panel in the _FileView_ tab), and selecting `Build`.
|
||||
|
||||
You may get a few warnings, but you should not get any errors.
|
||||
|
||||
Later, we will refer to the following `.lib` and `.dll` files that have just been generated:
|
||||
|
||||
- `./VisualC/Win32/Debug/SDL2.dll` or `./VisualC/Win32/Release/SDL2.dll`
|
||||
- `./VisualC/Win32/Debug/SDL2.lib` or `./VisualC/Win32/Release/SDL2.lib`
|
||||
- `./VisualC/Win32/Debug/SDL2main.lib` or `./VisualC/Win32/Release/SDL2main.lib`
|
||||
|
||||
_Note for the `x64` versions, just replace `Win32` in the path with `x64`_
|
||||
|
||||
### Creating a Project with SDL
|
||||
|
||||
- Create a project as a `Win32 Application`.
|
||||
|
||||
- Create a C++ file for your project.
|
||||
|
||||
- Set the C runtime to `Multi-threaded DLL` in the menu:
|
||||
`Project|Settings|C/C++ tab|Code Generation|Runtime Library `.
|
||||
|
||||
- Add the SDL `include` directory to your list of includes in the menu:
|
||||
`Project|Settings|C/C++ tab|Preprocessor|Additional include directories `
|
||||
|
||||
*VC7 Specific: Instead of doing this, I find it easier to add the
|
||||
include and library directories to the list that VC7 keeps. Do this by
|
||||
selecting Tools|Options|Projects|VC++ Directories and under the "Show
|
||||
Directories For:" dropbox select "Include Files", and click the "New
|
||||
Directory Icon" and add the [SDLROOT]\\include directory (e.g. If you
|
||||
installed to c:\\SDL\\ add c:\\SDL\\include). Proceed to change the
|
||||
dropbox selection to "Library Files" and add [SDLROOT]\\lib.*
|
||||
|
||||
The "include directory" I am referring to is the `./include` folder.
|
||||
|
||||
Now we're going to use the files that we had created earlier in the *Build SDL* step.
|
||||
|
||||
Copy the following file into your Project directory:
|
||||
|
||||
- `SDL2.dll`
|
||||
|
||||
Add the following files to your project (It is not necessary to copy them to your project directory):
|
||||
|
||||
- `SDL2.lib`
|
||||
- `SDL2main.lib`
|
||||
|
||||
To add them to your project, right click on your project, and select
|
||||
`Add files to project`.
|
||||
|
||||
**Instead of adding the files to your project, it is more desirable to add them to the linker options: Project|Properties|Linker|Command Line
|
||||
and type the names of the libraries to link with in the "Additional Options:" box. Note: This must be done for each build configuration
|
||||
(e.g. Release,Debug).**
|
||||
|
||||
### Hello SDL2
|
||||
|
||||
Here's a sample SDL snippet to verify everything is setup in your IDE:
|
||||
|
||||
```
|
||||
#include "SDL.h"
|
||||
|
||||
int main( int argc, char* argv[] )
|
||||
{
|
||||
const int WIDTH = 640;
|
||||
const int HEIGHT = 480;
|
||||
SDL_Window* window = NULL;
|
||||
SDL_Renderer* renderer = NULL;
|
||||
|
||||
SDL_Init(SDL_INIT_VIDEO);
|
||||
window = SDL_CreateWindow("SDL2 Test", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, WIDTH, HEIGHT, SDL_WINDOW_SHOWN);
|
||||
renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);
|
||||
|
||||
SDL_DestroyRenderer(renderer);
|
||||
SDL_DestroyWindow(window);
|
||||
SDL_Quit();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
### That's it!
|
||||
|
||||
I hope that this document has helped you get through the most difficult part of using the SDL: installing it.
|
||||
Suggestions for improvements should be posted to the [Github Issues](https://github.com/libsdl-org/SDL/issues).
|
||||
|
||||
### Credits
|
||||
|
||||
Thanks to [Paulus Esterhazy](mailto:pesterhazy@gmx.net), for the work on VC++ port.
|
||||
|
||||
This document was originally called "VisualC.txt", and was written by [Sam Lantinga](mailto:slouken@libsdl.org).
|
||||
|
||||
Later, it was converted to HTML and expanded into the document that you see today by [Lion Kimbro](mailto:snowlion@sprynet.com).
|
||||
|
||||
Minor Fixes and Visual C++ 7 Information (In Green) was added by [James Turk](mailto:james@conceptofzero.net)
|
||||
30
Engine/lib/sdl/docs/README-vita.md
Normal file
30
Engine/lib/sdl/docs/README-vita.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
PS Vita
|
||||
=======
|
||||
SDL port for the Sony Playstation Vita and Sony Playstation TV
|
||||
|
||||
Credit to
|
||||
* xerpi, cpasjuste and rsn8887 for initial (vita2d) port
|
||||
* vitasdk/dolcesdk devs
|
||||
* CBPS discord (Namely Graphene and SonicMastr)
|
||||
|
||||
Building
|
||||
--------
|
||||
To build for the PSVita, make sure you have vitasdk and cmake installed and run:
|
||||
```
|
||||
cmake -S. -Bbuild -DCMAKE_TOOLCHAIN_FILE=${VITASDK}/share/vita.toolchain.cmake -DCMAKE_BUILD_TYPE=Release
|
||||
cmake --build build
|
||||
cmake --install build
|
||||
```
|
||||
|
||||
|
||||
Notes
|
||||
-----
|
||||
* gles1/gles2 support and renderers are disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PVR=ON`
|
||||
These renderers support 720p and 1080i resolutions. These can be specified with:
|
||||
`SDL_setenv("VITA_RESOLUTION", "720", 1);` and `SDL_setenv("VITA_RESOLUTION", "1080", 1);`
|
||||
* gles2 support via PIB is disabled by default and can be enabled by configuring with `-DVIDEO_VITA_PIB=ON`
|
||||
* By default SDL emits mouse events for touch events on every touchscreen.
|
||||
Vita has two touchscreens, so it's recommended to use `SDL_SetHint(SDL_HINT_TOUCH_MOUSE_EVENTS, "0");` and handle touch events instead.
|
||||
Individual touchscreens can be disabled with:
|
||||
`SDL_setenv("VITA_DISABLE_TOUCH_FRONT", "1", 1);` and `SDL_setenv("VITA_DISABLE_TOUCH_BACK", "1", 1);`
|
||||
* Support for L2/R2/R3/R3 buttons, haptic feedback and gamepad led only available on PSTV, or when using external ds4 gamepad on vita.
|
||||
|
|
@ -352,38 +352,41 @@ source file, such as, "main.cpp".
|
|||
your project, and open the file in Visual C++'s text editor.
|
||||
7. Copy and paste the following code into the new file, then save it.
|
||||
|
||||
|
||||
#include <SDL.h>
|
||||
```c
|
||||
#include <SDL.h>
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
SDL_DisplayMode mode;
|
||||
SDL_Window * window = NULL;
|
||||
SDL_Renderer * renderer = NULL;
|
||||
SDL_Event evt;
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
SDL_DisplayMode mode;
|
||||
SDL_Window * window = NULL;
|
||||
SDL_Renderer * renderer = NULL;
|
||||
SDL_Event evt;
|
||||
SDL_bool keep_going = SDL_TRUE;
|
||||
|
||||
if (SDL_Init(SDL_INIT_VIDEO) != 0) {
|
||||
return 1;
|
||||
} else if (SDL_GetCurrentDisplayMode(0, &mode) != 0) {
|
||||
return 1;
|
||||
} else if (SDL_CreateWindowAndRenderer(mode.w, mode.h, SDL_WINDOW_FULLSCREEN, &window, &renderer) != 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
if (SDL_Init(SDL_INIT_VIDEO) != 0) {
|
||||
return 1;
|
||||
while (keep_going) {
|
||||
while (SDL_PollEvent(&evt)) {
|
||||
if ((evt.type == SDL_KEYDOWN) && (evt.key.keysym.sym == SDLK_ESCAPE)) {
|
||||
keep_going = SDL_FALSE;
|
||||
}
|
||||
}
|
||||
|
||||
if (SDL_GetCurrentDisplayMode(0, &mode) != 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
if (SDL_CreateWindowAndRenderer(mode.w, mode.h, SDL_WINDOW_FULLSCREEN, &window, &renderer) != 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
while (1) {
|
||||
while (SDL_PollEvent(&evt)) {
|
||||
}
|
||||
|
||||
SDL_SetRenderDrawColor(renderer, 0, 255, 0, 255);
|
||||
SDL_RenderClear(renderer);
|
||||
SDL_RenderPresent(renderer);
|
||||
}
|
||||
SDL_SetRenderDrawColor(renderer, 0, 255, 0, 255);
|
||||
SDL_RenderClear(renderer);
|
||||
SDL_RenderPresent(renderer);
|
||||
}
|
||||
|
||||
SDL_Quit();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
#### 6.B. Adding code and assets ####
|
||||
|
||||
|
|
|
|||
|
|
@ -14,14 +14,14 @@ hardware via OpenGL and Direct3D. It is used by video playback software,
|
|||
emulators, and popular games including Valve's award winning catalog
|
||||
and many Humble Bundle games.
|
||||
|
||||
SDL officially supports Windows, Mac OS X, Linux, iOS, and Android.
|
||||
SDL officially supports Windows, macOS, Linux, iOS, and Android.
|
||||
Support for other platforms may be found in the source code.
|
||||
|
||||
SDL is written in C, works natively with C++, and there are bindings
|
||||
available for several other languages, including C# and Python.
|
||||
|
||||
This library is distributed under the zlib license, which can be found
|
||||
in the file "COPYING.txt".
|
||||
in the file "LICENSE.txt".
|
||||
|
||||
The best way to learn how to use SDL is to check out the header files in
|
||||
the "include" subdirectory and the programs in the "test" subdirectory.
|
||||
|
|
@ -35,10 +35,11 @@ More documentation and FAQs are available online at [the wiki](http://wiki.libsd
|
|||
- [DynAPI](README-dynapi.md)
|
||||
- [Emscripten](README-emscripten.md)
|
||||
- [Gesture](README-gesture.md)
|
||||
- [Mercurial](README-hg.md)
|
||||
- [Git](README-git.md)
|
||||
- [iOS](README-ios.md)
|
||||
- [Linux](README-linux.md)
|
||||
- [OS X](README-macosx.md)
|
||||
- [macOS](README-macos.md)
|
||||
- [OS/2](README-os2.md)
|
||||
- [Native Client](README-nacl.md)
|
||||
- [Pandora](README-pandora.md)
|
||||
- [Supported Platforms](README-platforms.md)
|
||||
|
|
@ -49,15 +50,16 @@ More documentation and FAQs are available online at [the wiki](http://wiki.libsd
|
|||
- [WinCE](README-wince.md)
|
||||
- [Windows](README-windows.md)
|
||||
- [WinRT](README-winrt.md)
|
||||
- [PSVita](README-vita.md)
|
||||
|
||||
If you need help with the library, or just want to discuss SDL related
|
||||
issues, you can join the [developers mailing list](http://www.libsdl.org/mailing-list.php)
|
||||
issues, you can join the [SDL Discourse](https://discourse.libsdl.org/),
|
||||
which can be used as a web forum or a mailing list, at your preference.
|
||||
|
||||
If you want to report bugs or contribute patches, please submit them to
|
||||
[bugzilla](https://bugzilla.libsdl.org/)
|
||||
[our bug tracker](https://github.com/libsdl-org/SDL/issues)
|
||||
|
||||
Enjoy!
|
||||
|
||||
|
||||
Sam Lantinga <mailto:slouken@libsdl.org>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue