Migrate to SDL 2.0

[matteobin]

As the title says, this a simple way to migrate to SDL 2.0.
Most of the rendering is still done in software using SDL_Surfaces at the game base resolution, 320x200. Then, when the frame is ready, we update the SDL_Texture of the main djVisual and we let the GPU scale the texture to the window size.
Scaling is now done by the GPU, even for the retro display modes. This approach allows us to have a resizeable window "for free", moreover full screen for different aspect ratios is always scaled correctly and to the monitor desktop resolution too.
Certainly the rendering code can be further improved, but it's nonetheless a good starting point.

Fixes #122.

Reference:
https://wiki.libsdl.org/MigrationGuide

[davidjoffe]

Looks great, thanks so much, this will be useful [Edit I meant to 'not yet' fully approve/merge the main commit, just the small one, see comments below]

[davidjoffe]

Edit have created an issue also for this for possible discussion area also: #140

Thanks for this! Just some first glance comments: Love it, this is awesome. SDL2 support would be great and I love this (have wanted SDL2 support for a long time ... being on SDL1.2 has caused some pains in the past) but I'm hesitant to just jump and merge entire thing right away as there are quite a few prior ports and build setups/configs already set up for SDL1.2 and I don't want to just break them (I'm a bit sometimes overly cautious 'not to break things') ... my feeling would be ideally (time permitting) to try maybe merge these in a 'phased' slightly cautious way like:

(1) Create say a #define so we can toggle in Makefile settings between SDL1.2 and SDL2
(2) Maybe start with 1.2 the default (so nothing existing breaks) while we do a bit more for testing and to get port maintainers getting SDL2 version working (I'd like to try add this though don't have time)

(3) Once all ports happily on 2.0 etc. and more testing has been done try start switching to 2.0 as default (though not sure then how to best handle the dependencies in files like https://github.com/davidjoffe/dave_gnukem/blob/master/debian/control)
Or perhaps the Makefile could even just try autodetect if SDL2 present. The issue is this Makefile is so ancient it goes back so far it predates things like 'configure' or cmake. But it might not be too difficult for me (or someone) to add a few lines to the Makefile to try autodetect whether SDL2 present, or SDL1.2. But then we start re-inventing things like configure. But, it's a simple game with few dependencies so maybe OK. But would be nice to more easily add new dependencies in future for forks etc.

It's debatable if that's overkill for a small retro game; I'm typically very cautious about changes that might break existing ports.
There are many advantages to SDL2 so have been wanting to do something like this but had previously thought I'd try do it in some sort of 'Dave Gnukem version 2' fork, but now that probably won't happen.
Will try get some new test VMs in place to help test all this as soon as I can

Some small merge conflicts we'd just have to resolve also but nothing too serious at this stage - but I worry the longer I wait those merge conflicts could grow harder to merge. But my schedule very busy right now so it's difficult to find a spare 'weekend' to look at all this right now.

Another possibility is to just start with SDL2 support in a separate feature branch, e.g. I could create a new feature branch on the main project for SDL2 support, and maybe start by trying to merge these changes into the new feature branch - that gives some for testing also without breaking main, once it's all looking good can start maybe jumping to SDL2 or something.

For ports like Debian or BSD I could use VMs no problem but there are I think a couple of hardware ports I don't have the hardware to test myself.
Will try find some spare time to look at these things soon, guess we'll have to deal with them at some stage. Will think about all this in the meantime.

I also don't know if there might be some platforms that are 'stuck' on 1.2 forever? Not sure. But really 1.2 is 'too old' ... it's caused some problems on some platforms (e.g. Mac)

[davidjoffe]

Ok, I've been looking closer at this commit and doing some more tests - a few small things to fix with but nothing major, overall looks good and promising ... I'll do a good think about the best path forward here, but am (tentatively) leaning toward merging this in sometime very soon to the main Dave Gnukem branch - not immediately but very soon hopefully in the next week or two

[davidjoffe]

Just merged! Now must fix a few things quickly.