I modified SDL_gpu's CMake files to nicely integrate into Wesnoth's build system, so that solution would require extra work besides setting up a mirror. I don't think it's worth the effort considering that SDL_gpu's presence in the repo is hoped to be temporary.
---- On Mon, 30 Jun 2014 18:24:31 +0200 Timotei Dolean <timotei_c...@yahoo.co.uk> wrote ---- Hi Lipka, Wouldn't it be better to just use a submodule for the SDL_gpu library instead of merging it in our source code (history)? I see SDL_gpu uses svn on google code, but we could setup a github mirror. I see some had success asking the Github team to setup themselves an automatic mirroring system [0] altough that was based on git, not svn. [0] http://stackoverflow.com/questions/11370239/creating-an-official-github-mirror Timotei On 30-Jun-14 10:40, Lipka Boldizsár wrote: 828150517.-3749668537088809...@zoho.com" type="cite"> It was a pleasure ;) Anyone else, if you want to raise any concerns, please do it fast. Otherwise I'll merge the SDL_gpu branch in a couple of days. ---- On Sat, 28 Jun 2014 23:34:30 +0200 Nils Kneuper <crazy-ivano...@gmx.net> wrote ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 28.06.2014 15:49, schrieb Lipka Boldizsár: > There were two alternatives considered for SDL2: > > SDL_gpu is a non-official extension library for SDL2 and SDL1.2. It's > basically an OpenGL wrapper library, compatible with OpenGL 1, 2, 3 and > OpenGL ES 1, 2 and 3. After testing, we concluded that it's a good > replacement for SDL2's rendering API. The problem with it is that it's a > fairly new, one-man project. We can't be sure if it will be continued to be > developed. Major Linux vendors don't have it in their repositories, so > packaging might be problematic. If we are to use this library, the best > solution would be to temporarily import its source in Wesnoth's repo. This > adds OpenGL as a dependency. > > The other possible solution is using plain OpenGL. Using OpenGL directly > would save us from the packaging problem with SDL_gpu and in theory would > not deprive us from any benefits SDL_gpu has. However, I'm not really > familiar with OpenGL, so if I had to rewrite the rendering engine with > OpenGL, that would likely result in less robust and portable code than what > we can get from SDL_gpu. (Also less work done during the summer). > > I'm strongly in favor of SDL_gpu, so if there are no major concerns against > it, I'll go with that option. SDL_gpu sounds like a good option for me. Thanks for your work on this so far. Cheers, Nils Kneuper aka Ivanovic -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlOvNOYACgkQfFda9thizwUsNgCcCn4gfxaWJU5vIyjsZq9AAGoA JUIAnj7DEjvu2mZ1ovu6TMDhnxrJ44oM =5JH4 -----END PGP SIGNATURE----- _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
