mirror of
https://github.com/love2d/megasource.git
synced 2026-08-17 11:11:35 +02:00
Update SDL2 to the latest commit (85bbf8e)
This commit is contained in:
Alex Szpakowski
@@ -206,6 +206,9 @@ You should not use the SDL renderer API while the app going in background:
|
||||
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).
|
||||
|
||||
@@ -73,7 +73,7 @@ To use, set the following CMake variables when running CMake's configuration sta
|
||||
|
||||
- for iOS-Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
|
||||
|
||||
`cmake ~/sdl -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64`
|
||||
`cmake ~/sdl -DSDL_TESTS=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64`
|
||||
|
||||
- for tvOS-Simulator, using the latest, installed SDK:
|
||||
|
||||
|
||||
@@ -15,29 +15,34 @@ What you need:
|
||||
* Kernel-Framebuffer support: required: vesafb, radeonfb ....
|
||||
* Mesa 7.0.x - optional for OpenGL
|
||||
|
||||
/etc/directfbrc
|
||||
|
||||
This file should contain the following lines to make
|
||||
The `/etc/directfbrc` file should contain the following lines to make
|
||||
your joystick work and avoid crashes:
|
||||
------------------------
|
||||
|
||||
```
|
||||
disable-module=joystick
|
||||
disable-module=cle266
|
||||
disable-module=cyber5k
|
||||
no-linux-input-grab
|
||||
------------------------
|
||||
```
|
||||
|
||||
To disable to use x11 backend when DISPLAY variable is found use
|
||||
|
||||
```
|
||||
export SDL_DIRECTFB_X11_CHECK=0
|
||||
```
|
||||
|
||||
To disable the use of linux input devices, i.e. multimice/multikeyboard support,
|
||||
use
|
||||
|
||||
```
|
||||
export SDL_DIRECTFB_LINUX_INPUT=0
|
||||
```
|
||||
|
||||
To use hardware accelerated YUV-overlays for YUV-textures, use:
|
||||
|
||||
```
|
||||
export SDL_DIRECTFB_YUV_DIRECT=1
|
||||
```
|
||||
|
||||
This is disabled by default. It will only support one
|
||||
YUV texture, namely the first. Every other YUV texture will be
|
||||
@@ -45,7 +50,9 @@ rendered in software.
|
||||
|
||||
In addition, you may use (directfb-1.2.x)
|
||||
|
||||
```
|
||||
export SDL_DIRECTFB_YUV_UNDERLAY=1
|
||||
```
|
||||
|
||||
to make the YUV texture an underlay. This will make the cursor to
|
||||
be shown.
|
||||
@@ -54,14 +61,18 @@ Simple Window Manager
|
||||
=====================
|
||||
|
||||
The driver has support for a very, very basic window manager you may
|
||||
want to use when running with "wm=default". Use
|
||||
want to use when running with `wm=default`. Use
|
||||
|
||||
```
|
||||
export SDL_DIRECTFB_WM=1
|
||||
```
|
||||
|
||||
to enable basic window borders. In order to have the window title rendered,
|
||||
you need to have the following font installed:
|
||||
|
||||
```
|
||||
/usr/share/fonts/truetype/freefont/FreeSans.ttf
|
||||
```
|
||||
|
||||
OpenGL Support
|
||||
==============
|
||||
@@ -71,21 +82,25 @@ works at least on all directfb supported platforms.
|
||||
|
||||
As of this writing 20100802 you need to pull Mesa from git and do the following:
|
||||
|
||||
------------------------
|
||||
```
|
||||
git clone git://anongit.freedesktop.org/git/mesa/mesa
|
||||
cd mesa
|
||||
git checkout 2c9fdaf7292423c157fc79b5ce43f0f199dd753a
|
||||
------------------------
|
||||
```
|
||||
|
||||
Edit configs/linux-directfb so that the Directories-section looks like
|
||||
------------------------
|
||||
Edit `configs/linux-directfb` so that the Directories-section looks like this:
|
||||
|
||||
```
|
||||
# Directories
|
||||
SRC_DIRS = mesa glu
|
||||
GLU_DIRS = sgi
|
||||
DRIVER_DIRS = directfb
|
||||
PROGRAM_DIRS =
|
||||
------------------------
|
||||
```
|
||||
|
||||
Then do the following:
|
||||
|
||||
```
|
||||
make linux-directfb
|
||||
make
|
||||
|
||||
@@ -95,13 +110,14 @@ sudo make install INSTALL_DIR=/usr/local/dfb_GL
|
||||
cd src/mesa/drivers/directfb
|
||||
make
|
||||
sudo make install INSTALL_DIR=/usr/local/dfb_GL
|
||||
------------------------
|
||||
```
|
||||
|
||||
To run the SDL - testprograms:
|
||||
|
||||
```
|
||||
export SDL_VIDEODRIVER=directfb
|
||||
export LD_LIBRARY_PATH=/usr/local/dfb_GL/lib
|
||||
export LD_PRELOAD=/usr/local/dfb_GL/libGL.so.7
|
||||
|
||||
./testgl
|
||||
|
||||
```
|
||||
|
||||
@@ -0,0 +1,155 @@
|
||||
GDK
|
||||
=====
|
||||
|
||||
This port allows SDL applications to run via Microsoft's Game Development Kit (GDK).
|
||||
|
||||
Windows (GDK) and Xbox One/Xbox Series (GDKX) are supported. Although most of the Xbox code is included in the public SDL source code, NDA access is required for a small number of source files. If you have access to GDKX, these required Xbox files are posted on the GDK forums [here](https://forums.xboxlive.com/questions/130003/).
|
||||
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
* Microsoft Visual Studio 2022 (in theory, it should also work in 2017 or 2019, but this has not been tested)
|
||||
* Microsoft GDK June 2022 or newer (public release [here](https://github.com/microsoft/GDK/releases/tag/June_2022))
|
||||
* To publish a package or successfully authenticate a user, you will need to create an app id/configure services in Partner Center. However, for local testing purposes (without authenticating on Xbox Live), the identifiers used by the GDK test programs in the included solution will work.
|
||||
|
||||
|
||||
Windows GDK Status
|
||||
------
|
||||
|
||||
The Windows GDK port supports the full set of Win32 APIs, renderers, controllers, input devices, etc., as the normal Windows x64 build of SDL.
|
||||
|
||||
* Additionally, the GDK port adds the following:
|
||||
* Compile-time platform detection for SDL programs. The `__GDK__` is `#define`d on every GDK platform, and the `__WINGDK__` is `#define`d on Windows GDK, specifically. (This distinction exists because other GDK platforms support a smaller subset of functionality. This allows you to mark code for "any" GDK separate from Windows GDK.)
|
||||
* GDK-specific setup:
|
||||
* Initializing/uninitializing the game runtime, and initializing Xbox Live services
|
||||
* Creating a global task queue and setting it as the default for the process. When running any async operations, passing in `NULL` as the task queue will make the task get added to the global task queue.
|
||||
|
||||
* An implementation on `WinMain` that performs the above GDK setup (you should link against SDL2main.lib, as in Windows x64). If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
|
||||
* Global task queue callbacks are dispatched during `SDL_PumpEvents` (which is also called internally if using `SDL_PollEvent`).
|
||||
* You can get the handle of the global task queue through `SDL_GDKGetTaskQueue`, if needed. When done with the queue, be sure to use `XTaskQueueCloseHandle` to decrement the reference count (otherwise it will cause a resource leak).
|
||||
|
||||
* What doesn't work:
|
||||
* Compilation with anything other than through the included Visual C++ solution file
|
||||
|
||||
## VisualC-GDK Solution
|
||||
|
||||
The included `VisualC-GDK/SDL.sln` solution includes the following targets for the Gaming.Desktop.x64 configuration:
|
||||
|
||||
* SDL2 (DLL) - This is the typical SDL2.dll, but for Gaming.Desktop.x64.
|
||||
* SDL2main (lib) - This contains a drop-in implementation of `WinMain` that is used as the entry point for GDK programs.
|
||||
* tests/testgamecontroller - Standard SDL test program demonstrating controller functionality.
|
||||
* tests/testgdk - GDK-specific test program that demonstrates using the global task queue to login a user into Xbox Live.
|
||||
*NOTE*: As of the June 2022 GDK, you cannot test user logins without a valid Title ID and MSAAppId. You will need to manually change the identifiers in the `MicrosoftGame.config` to your valid IDs from Partner Center if you wish to test this.
|
||||
* tests/testsprite2 - Standard SDL test program demonstrating sprite drawing functionality.
|
||||
|
||||
If you set one of the test programs as a startup project, you can run it directly from Visual Studio.
|
||||
|
||||
Windows GDK Setup, Detailed Steps
|
||||
---------------------
|
||||
|
||||
These steps assume you already have a game using SDL that runs on Windows x64 along with a corresponding Visual Studio solution file for the x64 version. If you don't have this, it's easiest to use one of the test program vcxproj files in the `VisualC-GDK` directory as a starting point, though you will still need to do most of the steps below.
|
||||
|
||||
### 1. Add a Gaming.Desktop.x64 Configuration ###
|
||||
|
||||
In your game's existing Visual Studio Solution, go to Build > Configuration Manager. From the "Active solution platform" drop-down select "New...". From the drop-down list, select Gaming.Desktop.x64 and copy the settings from the x64 configuration.
|
||||
|
||||
### 2. Build SDL2 and SDL2main for GDK ###
|
||||
|
||||
Open `VisualC-GDK/SDL.sln` in Visual Studio, you need to build the SDL2 and SDL2main targets for the Gaming.Desktop.x64 platform (Release is recommended). You will need to copy/keep track of the `SDL2.dll`, `XCurl.dll` (which is output by Gaming.Desktop.x64), `SDL2.lib`, and `SDL2main.lib` output files for your game project.
|
||||
|
||||
*Alternatively*, you could setup your solution file to instead reference the SDL2/SDL2main project file targets from the SDL source, and add those projects as a dependency. This would mean that SDL2 and SDL2main would both be built when your game is built.
|
||||
|
||||
### 3. Configuring Project Settings ###
|
||||
|
||||
While the Gaming.Desktop.x64 configuration sets most of the required settings, there are some additional items to configure for your game project under the Gaming.Desktop.x64 Configuration:
|
||||
|
||||
* Under C/C++ > General > Additional Include Directories, make sure the `SDL/include` path is referenced
|
||||
* Under Linker > General > Additional Library Directories, make sure to reference the path where the newly-built SDL2.lib and SDL2main.lib are
|
||||
* Under Linker > Input > Additional Dependencies, you need the following:
|
||||
* `SDL2.lib`
|
||||
* `SDL2main.lib` (unless not using)
|
||||
* `xgameruntime.lib`
|
||||
* `../Microsoft.Xbox.Services.141.GDK.C.Thunks.lib`
|
||||
* Note that in general, the GDK libraries depend on the MSVC C/C++ runtime, so there is no way to remove this dependency from a GDK program that links against GDK.
|
||||
|
||||
### 4. Setting up SDL_main ###
|
||||
|
||||
Rather than using your own implementation of `WinMain`, it's recommended that you instead `#include "SDL_main.h"` and declare a standard main function. If you are unable to do this, you can instead manually call `SDL_GDKRunApp` from your entry point, passing in your `SDL_main` function and `NULL` as the parameters.
|
||||
|
||||
### 5. Required DLLs ###
|
||||
|
||||
The game will not launch in the debugger unless required DLLs are included in the directory that contains the game's .exe file. You need to make sure that the following files are copied into the directory:
|
||||
|
||||
* Your SDL2.dll
|
||||
* "$(Console_GRDKExtLibRoot)Xbox.Services.API.C\DesignTime\CommonConfiguration\Neutral\Lib\Release\Microsoft.Xbox.Services.141.GDK.C.Thunks.dll"
|
||||
* XCurl.dll
|
||||
|
||||
You can either copy these in a post-build step, or you can add the dlls into the project and set its Configuration Properties > General > Item type to "Copy file," which will also copy them into the output directory.
|
||||
|
||||
### 6. Setting up MicrosoftGame.config ###
|
||||
|
||||
You can copy `VisualC-GDK/tests/testgdk/MicrosoftGame.config` and use that as a starting point in your project. Minimally, you will want to change the Executable Name attribute, the DefaultDisplayName, and the Description.
|
||||
|
||||
This file must be copied into the same directory as the game's .exe file. As with the DLLs, you can either use a post-build step or the "Copy file" item type.
|
||||
|
||||
For basic testing, you do not need to change anything else in `MicrosoftGame.config`. However, if you want to test any Xbox Live services (such as logging in users) _or_ publish a package, you will need to setup a Game app on Partner Center.
|
||||
|
||||
Then, you need to set the following values to the values from Partner Center:
|
||||
|
||||
* Identity tag - Name and Publisher attributes
|
||||
* TitleId
|
||||
* MSAAppId
|
||||
|
||||
### 7. Adding Required Logos
|
||||
|
||||
Several logo PNG files are required to be able to launch the game, even from the debugger. You can use the sample logos provided in `VisualC-GDK/logos`. As with the other files, they must be copied into the same directory as the game's .exe file.
|
||||
|
||||
|
||||
### 8. Copying any Data Files ###
|
||||
|
||||
When debugging GDK games, there is no way to specify a working directory. Therefore, any required game data must also be copied into the output directory, likely in a post-build step.
|
||||
|
||||
|
||||
### 9. Build and Run from Visual Studio ###
|
||||
|
||||
At this point, you should be able to build and run your game from the Visual Studio Debugger. If you get any linker errors, make sure you double-check that you referenced all the required libs.
|
||||
|
||||
If you are testing Xbox Live functionality, it's likely you will need to change to the Sandbox for your title. To do this:
|
||||
|
||||
1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
|
||||
2. Switch the sandbox name with:
|
||||
`XblPCSandbox SANDBOX.#`
|
||||
3. (To switch back to the retail sandbox):
|
||||
`XblPCSandbox RETAIL`
|
||||
|
||||
### 10. Packaging and Installing Locally
|
||||
|
||||
You can use one of the test program's `PackageLayout.xml` as a starting point. Minimally, you will need to change the exe to the correct name and also reference any required game data. As with the other data files, it's easiest if you have this copy to the output directory, although it's not a requirement as you can specify relative paths to files.
|
||||
|
||||
To create the package:
|
||||
|
||||
1. Run "Desktop VS 2022 Gaming Command Prompt" from the Start Menu
|
||||
2. `cd` to the directory containing the `PackageLayout.xml` with the correct paths (if you use the local path as in the sample package layout, this would be from your .exe output directory)
|
||||
3. `mkdir Package` to create an output directory
|
||||
4. To package the file into the `Package` directory, use:
|
||||
`makepkg pack /f PackageLayout.xml /lt /d . /nogameos /pc /pd Package`
|
||||
5. To install the package, use:
|
||||
`wdapp install PACKAGENAME.msixvc`
|
||||
6. Once the package is installed, you can run it from the start menu.
|
||||
7. As with when running from Visual Studio, if you need to test any Xbox Live functionality you must switch to the correct sandbox.
|
||||
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
#### Xbox Live Login does not work
|
||||
|
||||
As of June 2022 GDK, you must have a valid Title Id and MSAAppId in order to test Xbox Live functionality such as user login. Make sure these are set correctly in the `MicrosoftGame.config`. This means that even testgdk will not let you login without setting these properties to valid values.
|
||||
|
||||
Furthermore, confirm that your PC is set to the correct sandbox.
|
||||
|
||||
|
||||
#### "The current user has already installed an unpackaged version of this app. A packaged version cannot replace this." error when installing
|
||||
|
||||
Prior to June 2022 GDK, running from the Visual Studio debugger would still locally register the app (and it would appear on the start menu). To fix this, you have to uninstall it (it's simplest to right click on it from the start menu to uninstall it).
|
||||
@@ -3,8 +3,8 @@ Linux
|
||||
|
||||
By default SDL will only link against glibc, the rest of the features will be
|
||||
enabled dynamically at runtime depending on the available features on the target
|
||||
system. So, for example if you built SDL with Xinerama support and the target
|
||||
system does not have the Xinerama libraries installed, it will be disabled
|
||||
system. So, for example if you built SDL with XRandR support and the target
|
||||
system does not have the XRandR libraries installed, it will be disabled
|
||||
at runtime, and you won't get a missing library error, at least with the
|
||||
default configuration parameters.
|
||||
|
||||
@@ -17,7 +17,7 @@ Ubuntu 20.04, all available features enabled:
|
||||
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 \
|
||||
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
|
||||
@@ -27,12 +27,11 @@ 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
|
||||
libXi-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 libdecor-devel \
|
||||
libsamplerate-devel pipewire-jack-audio-connection-kit-devel \
|
||||
|
||||
NOTES:
|
||||
- This includes all the audio targets except arts and esd, because Ubuntu
|
||||
|
||||
@@ -43,15 +43,14 @@ make
|
||||
sudo make install
|
||||
```
|
||||
|
||||
This script builds SDL with 10.6 ABI compatibility on 64-bit Intel and 11.0
|
||||
This script builds SDL with 10.7 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.
|
||||
Please note that building SDL requires at least Xcode 4.6 and the 10.7 SDK.
|
||||
PowerPC support for macOS has been officially dropped as of SDL 2.0.2.
|
||||
32-bit Intel and macOS 10.6 runtime support has been officially dropped as
|
||||
of SDL 2.24.0.
|
||||
|
||||
To use the library once it's built, you essential have two possibilities:
|
||||
use the traditional autoconf/automake/make method, or use Xcode.
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
Nokia N-Gage
|
||||
============
|
||||
|
||||
SDL2 port for Symbian S60v1 and v2 with a main focus on the Nokia N-Gage
|
||||
(Classic and QD) by [Michael Fitzmayer](https://github.com/mupfdev).
|
||||
|
||||
Compiling
|
||||
---------
|
||||
|
||||
SDL is part of the [N-Gage SDK.](https://github.com/ngagesdk) project.
|
||||
The library is included in the
|
||||
[toolchain](https://github.com/ngagesdk/ngage-toolchain) as a
|
||||
sub-module.
|
||||
|
||||
A complete example project based on SDL2 can be found in the GitHub
|
||||
account of the SDK: [Wordle](https://github.com/ngagesdk/wordle).
|
||||
|
||||
Current level of implementation
|
||||
-------------------------------
|
||||
|
||||
The video driver currently provides full screen video support with
|
||||
keyboard input.
|
||||
|
||||
At the moment only the software renderer works.
|
||||
|
||||
Audio is not yet implemented.
|
||||
|
||||
Acknowledgements
|
||||
----------------
|
||||
|
||||
Thanks to Hannu Viitala, Kimmo Kinnunen and Markus Mertama for the
|
||||
valuable insight into Symbian programming. Without the SDL 1.2 port
|
||||
which was specially developed for CDoom (Doom for the Nokia 9210), this
|
||||
adaptation would not have been possible.
|
||||
|
||||
I would like to thank my friends
|
||||
[Razvan](https://twitter.com/bewarerazvan) and [Dan
|
||||
Whelan](https://danwhelan.ie/), for their continuous support. Without
|
||||
you and the [N-Gage community](https://discord.gg/dbUzqJ26vs), I would
|
||||
have lost my patience long ago.
|
||||
|
||||
Last but not least, I would like to thank the development team of
|
||||
[EKA2L1](https://12z1.com/) (an experimental Symbian OS emulator). Your
|
||||
patience and support in troubleshooting helped me a lot.
|
||||
@@ -0,0 +1,34 @@
|
||||
PS2
|
||||
======
|
||||
SDL2 port for the Sony Playstation 2 contributed by:
|
||||
- Francisco Javier Trujillo Mata
|
||||
|
||||
|
||||
Credit to
|
||||
- The guys that ported SDL to PSP & Vita because I'm taking them as reference.
|
||||
- David G. F. for helping me with several issues and tests.
|
||||
|
||||
## Building
|
||||
To build SDL2 library for the PS2, make sure you have the latest PS2Dev status and run:
|
||||
```bash
|
||||
cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=$PS2DEV/ps2sdk/ps2dev.cmake
|
||||
cmake --build build
|
||||
cmake --install build
|
||||
```
|
||||
|
||||
|
||||
## Getting PS2 Dev
|
||||
[Installing PS2 Dev](https://github.com/ps2dev/ps2dev)
|
||||
|
||||
## Running on PCSX2 Emulator
|
||||
[PCSX2](https://github.com/PCSX2/pcsx2)
|
||||
|
||||
[More PCSX2 information](https://pcsx2.net/)
|
||||
|
||||
## To Do
|
||||
- PS2 Screen Keyboard
|
||||
- Dialogs
|
||||
- Audio
|
||||
- Video
|
||||
- Controllers
|
||||
- Others
|
||||
@@ -1,31 +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 SDL2 library 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 toolchain
|
||||
---------------------
|
||||
https://github.com/pspdev/psptoolchain
|
||||
## Getting PSP Dev
|
||||
[Installing PSP Dev](https://github.com/pspdev/pspdev)
|
||||
|
||||
Running on PPSSPP Emulator
|
||||
--------------------------
|
||||
https://github.com/hrydgard/ppsspp
|
||||
( https://github.com/hrydgard/ppsspp/wiki/Build-instructions )
|
||||
## Running on PPSSPP Emulator
|
||||
[PPSSPP](https://github.com/hrydgard/ppsspp)
|
||||
|
||||
Compiling an HelloWorld
|
||||
-----------------------
|
||||
https://psp-dev.org/doku.php?id=tutorial:hello_world
|
||||
[Build Instructions](https://github.com/hrydgard/ppsspp/wiki/Build-instructions)
|
||||
|
||||
To Do
|
||||
------
|
||||
PSP Screen Keyboard
|
||||
|
||||
## Compiling a HelloWorld
|
||||
[PSP Hello World](https://psp-dev.org/doku.php?id=tutorial:hello_world)
|
||||
|
||||
## To Do
|
||||
- PSP Screen Keyboard
|
||||
- Dialogs
|
||||
@@ -63,7 +63,7 @@ Now, before chrooting into the ARM sysroot, you'll need to apply a workaround,
|
||||
edit $SYSROOT/etc/ld.so.preload and comment out all lines in it.
|
||||
|
||||
sudo chroot $SYSROOT
|
||||
apt-get install libudev-dev libasound2-dev libdbus-1-dev libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxi-dev libxinerama-dev libxxf86vm-dev libxss-dev
|
||||
apt-get install libudev-dev libasound2-dev libdbus-1-dev libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libx11-dev libxext-dev libxrandr-dev libxcursor-dev libxi-dev libxss-dev
|
||||
exit
|
||||
sudo umount $SYSROOT/dev
|
||||
sudo umount $SYSROOT/proc
|
||||
|
||||
@@ -0,0 +1,60 @@
|
||||
# Versioning
|
||||
|
||||
## Since 2.23.0
|
||||
|
||||
SDL follows an "odd/even" versioning policy, similar to GLib, GTK, Flatpak
|
||||
and older versions of the Linux kernel:
|
||||
|
||||
* The major version (first part) increases when backwards compatibility
|
||||
is broken, which will happen infrequently.
|
||||
|
||||
* If the minor version (second part) is divisible by 2
|
||||
(for example 2.24.x, 2.26.x), this indicates a version of SDL that
|
||||
is believed to be stable and suitable for production use.
|
||||
|
||||
* In stable releases, the patchlevel or micro version (third part)
|
||||
indicates bugfix releases. Bugfix releases should not add or
|
||||
remove ABI, so the ".0" release (for example 2.24.0) should be
|
||||
forwards-compatible with all the bugfix releases from the
|
||||
same cycle (for example 2.24.1).
|
||||
|
||||
* The minor version increases when new API or ABI is added, or when
|
||||
other significant changes are made. Newer minor versions are
|
||||
backwards-compatible, but not fully forwards-compatible.
|
||||
For example, programs built against SDL 2.24.x should work fine
|
||||
with SDL 2.26.x, but programs built against SDL 2.26.x will not
|
||||
necessarily work with 2.24.x.
|
||||
|
||||
* If the minor version (second part) is not divisible by 2
|
||||
(for example 2.23.x, 2.25.x), this indicates a development prerelease
|
||||
of SDL that is not suitable for stable software distributions.
|
||||
Use with caution.
|
||||
|
||||
* The patchlevel or micro version (third part) increases with
|
||||
each prerelease.
|
||||
|
||||
* Each prerelease might add new API and/or ABI.
|
||||
|
||||
* Prereleases are backwards-compatible with older stable branches.
|
||||
For example, 2.25.x will be backwards-compatible with 2.24.x.
|
||||
|
||||
* Prereleases are not guaranteed to be backwards-compatible with
|
||||
each other. For example, new API or ABI added in 2.25.1
|
||||
might be removed or changed in 2.25.2.
|
||||
If this would be a problem for you, please do not use prereleases.
|
||||
|
||||
* Only upgrade to a prerelease if you can guarantee that you will
|
||||
promptly upgrade to the stable release that follows it.
|
||||
For example, do not upgrade to 2.23.x unless you will be able to
|
||||
upgrade to 2.24.0 when it becomes available.
|
||||
|
||||
* Software distributions that have a freeze policy (in particular Linux
|
||||
distributions with a release cycle, such as Debian and Fedora)
|
||||
should usually only package stable releases, and not prereleases.
|
||||
|
||||
## Before 2.23.0
|
||||
|
||||
Older versions of SDL followed a similar policy, but instead of the
|
||||
odd/even rule applying to the minor version, it applied to the patchlevel
|
||||
(micro version, third part). For example, 2.0.22 was a stable release
|
||||
and 2.0.21 was a prerelease.
|
||||
@@ -1,7 +1,7 @@
|
||||
Using SDL with Microsoft Visual C++
|
||||
===================================
|
||||
|
||||
### by [Lion Kimbro](mailto:snowlion@sprynet.com) with additions by [James Turk](mailto:james@conceptofzero.net)
|
||||
### by Lion Kimbro with additions by James Turk
|
||||
|
||||
You can either use the precompiled libraries from the [SDL](https://www.libsdl.org/download.php) web site, or you can build SDL
|
||||
yourself.
|
||||
|
||||
@@ -3,7 +3,7 @@ PS Vita
|
||||
SDL port for the Sony Playstation Vita and Sony Playstation TV
|
||||
|
||||
Credit to
|
||||
* xerpi and rsn8887 for initial (vita2d) port
|
||||
* xerpi, cpasjuste and rsn8887 for initial (vita2d) port
|
||||
* vitasdk/dolcesdk devs
|
||||
* CBPS discord (Namely Graphene and SonicMastr)
|
||||
|
||||
@@ -22,6 +22,9 @@ 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);`
|
||||
* Desktop GL 1.X and 2.X support and renderers are also disabled by default and also can be enabled with `-DVIDEO_VITA_PVR=ON` as long as gl4es4vita is present in your SDK.
|
||||
They support the same resolutions as the gles1/gles2 backends and require specifying `SDL_setenv("VITA_PVR_OGL", "1", 1);`
|
||||
anytime before video subsystem initialization.
|
||||
* 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.
|
||||
|
||||
@@ -1,45 +1,58 @@
|
||||
Windows
|
||||
================================================================================
|
||||
# Windows
|
||||
|
||||
================================================================================
|
||||
OpenGL ES 2.x support
|
||||
================================================================================
|
||||
## LLVM and Intel C++ compiler support
|
||||
|
||||
SDL has support for OpenGL ES 2.x under Windows via two alternative
|
||||
implementations.
|
||||
The most straightforward method consists in running your app in a system with
|
||||
a graphic card paired with a relatively recent (as of November of 2013) driver
|
||||
which supports the WGL_EXT_create_context_es2_profile extension. Vendors known
|
||||
SDL will build with the Visual Studio project files with LLVM-based compilers, such as the Intel oneAPI C++
|
||||
compiler, but you'll have to manually add the "-msse3" command line option
|
||||
to at least the SDL_audiocvt.c source file, and possibly others. This may
|
||||
not be necessary if you build SDL with CMake instead of the included Visual
|
||||
Studio solution.
|
||||
|
||||
Details are here: https://github.com/libsdl-org/SDL/issues/5186
|
||||
|
||||
|
||||
## OpenGL ES 2.x support
|
||||
|
||||
SDL has support for OpenGL ES 2.x under Windows via two alternative
|
||||
implementations.
|
||||
|
||||
The most straightforward method consists in running your app in a system with
|
||||
a graphic card paired with a relatively recent (as of November of 2013) driver
|
||||
which supports the WGL_EXT_create_context_es2_profile extension. Vendors known
|
||||
to ship said extension on Windows currently include nVidia and Intel.
|
||||
|
||||
The other method involves using the ANGLE library (https://code.google.com/p/angleproject/)
|
||||
If an OpenGL ES 2.x context is requested and no WGL_EXT_create_context_es2_profile
|
||||
extension is found, SDL will try to load the libEGL.dll library provided by
|
||||
ANGLE.
|
||||
The other method involves using the
|
||||
[ANGLE library](https://code.google.com/p/angleproject/). If an OpenGL ES 2.x
|
||||
context is requested and no WGL_EXT_create_context_es2_profile extension is
|
||||
found, SDL will try to load the libEGL.dll library provided by ANGLE.
|
||||
|
||||
To obtain the ANGLE binaries, you can either compile from source from
|
||||
https://chromium.googlesource.com/angle/angle or copy the relevant binaries from
|
||||
a recent Chrome/Chromium install for Windows. The files you need are:
|
||||
|
||||
* libEGL.dll
|
||||
* libGLESv2.dll
|
||||
* d3dcompiler_46.dll (supports Windows Vista or later, better shader compiler)
|
||||
or...
|
||||
* d3dcompiler_43.dll (supports Windows XP or later)
|
||||
https://chromium.googlesource.com/angle/angle or copy the relevant binaries
|
||||
from a recent Chrome/Chromium install for Windows. The files you need are:
|
||||
|
||||
- libEGL.dll
|
||||
- libGLESv2.dll
|
||||
- d3dcompiler_46.dll (supports Windows Vista or later, better shader
|
||||
compiler) *or* d3dcompiler_43.dll (supports Windows XP or later)
|
||||
|
||||
If you compile ANGLE from source, you can configure it so it does not need the
|
||||
d3dcompiler_* DLL at all (for details on this, see their documentation).
|
||||
d3dcompiler_* DLL at all (for details on this, see their documentation).
|
||||
However, by default SDL will try to preload the d3dcompiler_46.dll to
|
||||
comply with ANGLE's requirements. If you wish SDL to preload d3dcompiler_43.dll (to
|
||||
support Windows XP) or to skip this step at all, you can use the
|
||||
SDL_HINT_VIDEO_WIN_D3DCOMPILER hint (see SDL_hints.h for more details).
|
||||
comply with ANGLE's requirements. If you wish SDL to preload
|
||||
d3dcompiler_43.dll (to support Windows XP) or to skip this step at all, you
|
||||
can use the SDL_HINT_VIDEO_WIN_D3DCOMPILER hint (see SDL_hints.h for more
|
||||
details).
|
||||
|
||||
Known Bugs:
|
||||
|
||||
* SDL_GL_SetSwapInterval is currently a no op when using ANGLE. It appears
|
||||
that there's a bug in the library which prevents the window contents from
|
||||
refreshing if this is set to anything other than the default value.
|
||||
|
||||
Vulkan Surface Support
|
||||
==============
|
||||
|
||||
Support for creating Vulkan surfaces is configured on by default. To disable it change the value of `SDL_VIDEO_VULKAN` to 0 in `SDL_config_windows.h`. You must install the [Vulkan SDK](https://www.lunarg.com/vulkan-sdk/) in order to use Vulkan graphics in your application.
|
||||
- SDL_GL_SetSwapInterval is currently a no op when using ANGLE. It appears
|
||||
that there's a bug in the library which prevents the window contents from
|
||||
refreshing if this is set to anything other than the default value.
|
||||
|
||||
## Vulkan Surface Support
|
||||
|
||||
Support for creating Vulkan surfaces is configured on by default. To disable
|
||||
it change the value of `SDL_VIDEO_VULKAN` to 0 in `SDL_config_windows.h`. You
|
||||
must install the [Vulkan SDK](https://www.lunarg.com/vulkan-sdk/) in order to
|
||||
use Vulkan graphics in your application.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ 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
|
||||
@@ -34,23 +34,27 @@ More documentation and FAQs are available online at [the wiki](http://wiki.libsd
|
||||
- [DirectFB](README-directfb.md)
|
||||
- [DynAPI](README-dynapi.md)
|
||||
- [Emscripten](README-emscripten.md)
|
||||
- [GDK](README-gdk.md)
|
||||
- [Gesture](README-gesture.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)
|
||||
- [Porting information](README-porting.md)
|
||||
- [PSP](README-psp.md)
|
||||
- [PS2](README-ps2.md)
|
||||
- [Raspberry Pi](README-raspberrypi.md)
|
||||
- [Touch](README-touch.md)
|
||||
- [Versions](README-versions.md)
|
||||
- [WinCE](README-wince.md)
|
||||
- [Windows](README-windows.md)
|
||||
- [WinRT](README-winrt.md)
|
||||
- [PSVita](README-vita.md)
|
||||
- [Nokia N-Gage](README-ngage.md)
|
||||
|
||||
If you need help with the library, or just want to discuss SDL related
|
||||
issues, you can join the [SDL Discourse](https://discourse.libsdl.org/),
|
||||
|
||||
@@ -640,6 +640,7 @@ EXCLUDE = ../include/SDL_opengles2_gl2ext.h \
|
||||
../include/SDL_opengles.h \
|
||||
../include/SDL_opengl.h \
|
||||
../include/SDL_egl.h \
|
||||
./release_checklist.md \
|
||||
|
||||
|
||||
# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
# Release checklist
|
||||
|
||||
## New feature release
|
||||
|
||||
* Update `WhatsNew.txt`
|
||||
|
||||
* Bump version number to 2.EVEN.0 in all these locations:
|
||||
|
||||
* `configure.ac`, `CMakeLists.txt`: `SDL_*_VERSION`
|
||||
* `Xcode/SDL/Info-Framework.plist`: `CFBundleShortVersionString`,
|
||||
`CFBundleVersion`
|
||||
* `Makefile.os2`: `VERSION`
|
||||
* `Makefile.w32`: `*_VERSION`
|
||||
* `build-scripts/winrtbuild.ps1`: `$SDLVersion`
|
||||
* `include/SDL_version.h`: `SDL_*_VERSION`, `SDL_PATCHLEVEL`
|
||||
* `src/main/windows/version.rc`: `FILEVERSION`, `PRODUCTVERSION`,
|
||||
`FileVersion`, `ProductVersion`
|
||||
|
||||
* Bump ABI version information
|
||||
|
||||
* `CMakeLists.txt`, `Xcode/SDL/SDL.xcodeproj/project.pbxproj`:
|
||||
`DYLIB_CURRENT_VERSION`, `DYLIB_COMPATIBILITY_VERSION`
|
||||
* set first number in `DYLIB_CURRENT_VERSION` to
|
||||
(100 * *minor*) + 1
|
||||
* set second number in `DYLIB_CURRENT_VERSION` to 0
|
||||
* if backwards compatibility has been broken,
|
||||
increase `DYLIB_COMPATIBILITY_VERSION` (?)
|
||||
|
||||
* Run test/versioning.sh to verify that everything is consistent
|
||||
|
||||
* Regenerate `configure`
|
||||
|
||||
* Do the release
|
||||
|
||||
## New bugfix release
|
||||
|
||||
* Check that no new API/ABI was added
|
||||
|
||||
* If it was, do a new feature release (see above) instead
|
||||
|
||||
* Bump version number from 2.Y.Z to 2.Y.(Z+1) (Y is even)
|
||||
|
||||
* Same places as listed above
|
||||
|
||||
* Bump ABI version information
|
||||
|
||||
* `CMakeLists.txt`, `Xcode/SDL/SDL.xcodeproj/project.pbxproj`:
|
||||
`DYLIB_CURRENT_VERSION`, `DYLIB_COMPATIBILITY_VERSION`
|
||||
* set second number in `DYLIB_CURRENT_VERSION` to *patchlevel*
|
||||
|
||||
* Run test/versioning.sh to verify that everything is consistent
|
||||
|
||||
* Regenerate `configure`
|
||||
|
||||
* Do the release
|
||||
|
||||
## After a feature release
|
||||
|
||||
* Create a branch like `release-2.24.x`
|
||||
|
||||
* Bump version number to 2.ODD.0 for next development branch
|
||||
|
||||
* Same places as listed above
|
||||
|
||||
* Bump ABI version information
|
||||
|
||||
* Same places as listed above
|
||||
* Assume that the next feature release will contain new API/ABI
|
||||
|
||||
* Run test/versioning.sh to verify that everything is consistent
|
||||
|
||||
## New development prerelease
|
||||
|
||||
* Bump version number from 2.Y.Z to 2.Y.(Z+1) (Y is odd)
|
||||
|
||||
* Same places as listed above
|
||||
|
||||
* Bump ABI version information
|
||||
|
||||
* `CMakeLists.txt`, `Xcode/SDL/SDL.xcodeproj/project.pbxproj`:
|
||||
`DYLIB_CURRENT_VERSION`, `DYLIB_COMPATIBILITY_VERSION`
|
||||
* set first number in `DYLIB_CURRENT_VERSION` to
|
||||
(100 * *minor*) + *patchlevel* + 1
|
||||
* set second number in `DYLIB_CURRENT_VERSION` to 0
|
||||
* if backwards compatibility has been broken,
|
||||
increase `DYLIB_COMPATIBILITY_VERSION` (?)
|
||||
|
||||
* Run test/versioning.sh to verify that everything is consistent
|
||||
|
||||
* Regenerate `configure`
|
||||
|
||||
* Do the release
|
||||
Reference in New Issue
Block a user