View source for SDL 2 + OpenGL port


== Blurb copied from [[NotSoEasyCoding]] ==

Wesnoth currently depends on the unmaintained SDL 1.2.x code base and the 1.2.x-based versions of its companion libraries (SDL_image, SDL_mixer, SDL_net, SDL_ttf). This means Wesnoth can't benefit from features added in newer versions of SDL such as built-in support for Android and iOS, improved cross-platform Unicode support, built-in clipboard support, and any bug fixes made since SDL 1.2.15.

The problem with porting Wesnoth to SDL 2.0 as explained by lipkab (who attempted the task as part of GSoC 2014) is that SDL 2.0's software rendering API lacks some things Wesnoth needs such as a specific alpha blending mode (TODO: link to conversations here).

Furthermore, while software rendering is all good and nice, Wesnoth's approach does not scale well as display resolutions increase and the need for supporting high DPI configurations is factored in. One can easily see that our zoom functionality is clunky and inefficient. Having support for OpenGL and shaders would also enable us to implement fancier graphical gimmicks such as particle effects and atmospheric lighting. The downside of adding OpenGL to the mix is that we'd need people with a specific skillset to help us maintain the graphics engine in the long term, as hardware and driver-specific quirks are inevitable. Some users are also concerned about changing Wesnoth's hardware requirements so that they would be unable to play using old or unsupported hardware/OS configurations.

For hardware rendering to be effective, in particular, Wesnoth would necessitate a complete rewrite of the graphics rendering code (the display and game_display classes), the image cache manager (used to abstract the process of loading images from disk and applying image path functions), and potentially GUI2's canvas code. All three would have to limit the amount of textures they allocate to the absolute minimum, using larger textures instead. For example, the image cache could be reimplemented to load images from an internal spritesheet generated during the game loading process. (WML/Lua support for spritesheets would be nice would defining an API for it would only distract from the actual task at hand.)

The greatest difficulty in handling this task probably lies in writing a new optimized rendering engine and updating all code that relies on the old display/game_display API and semantics accordingly. The GUI2 framework code is presently unmaintained and it would take some time for somebody to study and change the current implementation. Finally, as we don't have a graphics engine maintainer at this time, this task involves an implicit long-term commitment to the project that extends beyond Wesnoth 1.14.x (or whichever series will see this project completed).


== Steps ==

It may be possible to avoid rewriting the entire graphics engine while moving to SDL2.

=== Minimum SDL2 steps ===
* <strike>Make SDL2 compile</strike>
* <strike>Fix graphics issues with current graphics engine (seen in second tutorial mission when scrolling).</strike>
* <strike>Implement clipboard support (currently lacking)</strike>
* <strike>Fix alpha blending issues</strike>
* <strike>Fix crash bugs during resize</strike>
* Fix bugs

<strike>At this stage it may be feasible to switch to SDL2 as the primary library as opposed to using 1.2 in order to get a larger test uptake.</strike> We have now switched to SDL2 as the primary library. Backwards compatability will be maintained for at least one release before SDL1.2 support is removed.


* Investigate OpenGL support and software fallback options to support older hardware
* Move current graphics engine to OpenGL with as few changes as possible. (This may be a lot harder than it sounds)
* Convert to spritesheets, optimise performance.

== Documentation Required ==

A part of this should be to review and document the existing code that deals with asset management/loading, event handling and rendering. A document should be produced in the end that reflects:

* The in game asset management
* The event handling (including within GUI2)
* The rendering pipeline
* Classes touching SDL2

This should ideally be refined into an architecture document that is reviewed and agreed upon.