On Thursday, 2 April 2015 at 09:30:43 UTC, Namespace wrote:
>> Just a follow up comment.  Apparently the instructions for installing all libraries at once in the tutorial don't work for OpenSuse.  So I couldn't just install the SDL library but had to install the other libraries individually:
>>
>> So just in case there are any other OpenSuse users out there (note, I suppose I didn't need the devel version of libSDL2 ...):
>>
>> sudo zypper in libSDL2-devel
>> sudo zypper in libSDL2_image-2_0-0
>> sudo zypper in libSDL2_mixer-2_0-0
>> sudo zypper in libSDL2_ttf-2_0-0
>
> I will add this to the installation tutorial. Unfortunately I did not tested Dgame with OpenSUSE, sorry for your trouble.

No worries, you can't test everything, and OpenSUSE isn't as popular as some other distros.  Also, I guess OpenSUSE isn't going to work with default libs anyway because of the versions.

I am going to build SDL from scratch and install.  I've downloaded 2.0.3, so I should be good to go.

Thanks Namespace and Mike for your help.

The master branch should now make an automatic downgrade.

On Thursday, 2 April 2015 at 18:49:15 UTC, Namespace wrote:
> The master branch should now make an automatic downgrade.

I am still using rc1 but managed to get everything working.  I built SDL(and the other libraries) from source and now everything works great.

Thanks for your help.

Craig

On Thursday, 2 April 2015 at 09:38:05 UTC, Namespace wrote:

>
> Dgame is based on SDL 2.0.3 (as described in the installation tutorial), but tries to "wrap" any function call which is introduced after SDL 2.0.0:
> ----
> static if (SDL_VERSION_ATLEAST(2, 0, 2))
> ----
> so that Dgame should be usable with any SDL2.x version.
>
> I will investigate which function is calling SDL_HasAVX.

None of that matters. This has nothing to do with what Dgame is calling, but what Derelict is actually trying to load. SDL_HasAVX was added to the API in 2.0.2 so does not exist in previous versions of SDL, therefore an exception will be thrown when Derelict tries to load older versions and that function is missing.

> Dgame will load DerelictSDL2 as usual and then it will check if the supported version is below 2.0.2. If so, DerelictSDL2 will be reloaded with SharedLibVersion(MAX_SUPPORTED_VERSION)).

> That should that work, right?

No, it won't. By default, Derelict attempts to load functions from the 2.0.2 API (which includes 2.0.3, since the API did not change). That means anything below 2.0.2 will *always* fail to load because they are missing the functions added to the API in 2.0.2.

The right way to do this is to use the selective loading mechanism to disable exceptions for certain functions. With the 1.9.x versions of DerelictSDL2, you no longer have to implement that manually. As I wrote above, you can do this:

DerelictSDL2.load(SharedLibVersion(2,0,0));

With that, you can load any version of SDL2 available on the system, from 2.0.0 on up. It uses selective loading internally. For example, 2.0.0 will load even though it is missing SDL_HasAVX and several other functions added in 2.0.1 and 2.0.2. But you should only do this if you are absolutely sure that you are not calling any functions that were not present in 2.0.0. For example, the SDL_GetPrefPath/SDL_GetBasePath functions were added in 2.0.1. If you require those and need nothing from 2.0.2, then you should do this:

DerelictSDL2.load(SharedLibVersion(2,0,1));

Now, 2.0.0 will fail to load, but 2.0.1 and higher will succeed. You can look at the functions allowSDL_2_0_0 and allowSDL_2_0_1 in sdl.d [1] to see exactly which functions were added in 2.0.1 and 2.0.2 so that you can determine if you require any of them. I also encourage you to go and do a diff of the SDL headers for each release to see things other than functions, like new constants, that were added in each release (and to protect against the possibility that I've made a mistake somewhere). That won't affect whether or not Derleict loads, but a new constant added in SDL 2.0.2 won't work with a function that existed in 2.0.0, for example.

On Friday, 3 April 2015 at 04:55:42 UTC, Mike Parker wrote:

> succeed. You can look at the functions allowSDL_2_0_0 and allowSDL_2_0_1 in sdl.d [1] to see exactly which functions were added in 2.0.1 and 2.0.2 so that you can determine if you

Gah! I always forget to add the referenced links.

[1] https://github.com/DerelictOrg/DerelictSDL2/blob/SDL-2.0.x/source/derelict/sdl2/sdl.d#L534

On Friday, 3 April 2015 at 04:55:42 UTC, Mike Parker wrote:
> On Thursday, 2 April 2015 at 09:38:05 UTC, Namespace wrote:
>
>>
>> Dgame is based on SDL 2.0.3 (as described in the installation tutorial), but tries to "wrap" any function call which is introduced after SDL 2.0.0:
>> ----
>> static if (SDL_VERSION_ATLEAST(2, 0, 2))
>> ----
>> so that Dgame should be usable with any SDL2.x version.
>>
>> I will investigate which function is calling SDL_HasAVX.
>
> None of that matters. This has nothing to do with what Dgame is calling, but what Derelict is actually trying to load. SDL_HasAVX was added to the API in 2.0.2 so does not exist in previous versions of SDL, therefore an exception will be thrown when Derelict tries to load older versions and that function is missing.
>
>> Dgame will load DerelictSDL2 as usual and then it will check if the supported version is below 2.0.2. If so, DerelictSDL2 will be reloaded with SharedLibVersion(MAX_SUPPORTED_VERSION)).
>
>> That should that work, right?
>
> No, it won't. By default, Derelict attempts to load functions from the 2.0.2 API (which includes 2.0.3, since the API did not change). That means anything below 2.0.2 will *always* fail to load because they are missing the functions added to the API in 2.0.2.
>
> The right way to do this is to use the selective loading mechanism to disable exceptions for certain functions. With the 1.9.x versions of DerelictSDL2, you no longer have to implement that manually. As I wrote above, you can do this:
>
> DerelictSDL2.load(SharedLibVersion(2,0,0));
>
> With that, you can load any version of SDL2 available on the system, from 2.0.0 on up. It uses selective loading internally. For example, 2.0.0 will load even though it is missing SDL_HasAVX and several other functions added in 2.0.1 and 2.0.2. But you should only do this if you are absolutely sure that you are not calling any functions that were not present in 2.0.0. For example, the SDL_GetPrefPath/SDL_GetBasePath functions were added in 2.0.1. If you require those and need nothing from 2.0.2, then you should do this:
>
> DerelictSDL2.load(SharedLibVersion(2,0,1));
>
> Now, 2.0.0 will fail to load, but 2.0.1 and higher will succeed. You can look at the functions allowSDL_2_0_0 and allowSDL_2_0_1 in sdl.d [1] to see exactly which functions were added in 2.0.1 and 2.0.2 so that you can determine if you require any of them. I also encourage you to go and do a diff of the SDL headers for each release to see things other than functions, like new constants, that were added in each release (and to protect against the possibility that I've made a mistake somewhere). That won't affect whether or not Derleict loads, but a new constant added in SDL 2.0.2 won't work with a function that existed in 2.0.0, for example.

Yes, you're right. I'll undo my changes and I'll set SDL 2.0.2 as a basis for Dgame. Thank you for the explanation. :)

One small note about the tutorials. In the tutorial on
Game Loop and Event handling:

http://rswhite.de/dgame5/?page=tutorial&tut=handle_events

In the first example, I believe you are missing an import for Dgame.Window.Event. It shows up int the second example, so no big deal, but I figured I should let you know.

Are the tutorials on GitHub too?

Craig

On Saturday, 4 April 2015 at 02:34:59 UTC, Craig Dillabaugh wrote:
> One small note about the tutorials. In the tutorial on
> Game Loop and Event handling:
>
> http://rswhite.de/dgame5/?page=tutorial&tut=handle_events
>
> In the first example, I believe you are missing an import for Dgame.Window.Event. It shows up int the second example, so no big deal, but I figured I should let you know.
>
> Are the tutorials on GitHub too?
>
> Craig

Hey thanks for the note, but Dgame.Window is a package import: https://github.com/Dgame/Dgame/blob/master/source/Dgame/Window/package.d
As you can see, the Event is public imported.

And yes, the tutorials (the source codes) are on Github: https://github.com/Dgame/Dgame-Tutorial

With an click on "Show Raw" on the tutorial page you can get the snippet also. :)

Instead of opening a new post I announce here the release of the RC #2. Besides some minor bug fixes and some API changes (mostly to improve the Event handling) I've added also support for Joysticks and GameControllers. That should be the last big changes. If no more bugs appear (and the Derelict issue [https://github.com/DerelictOrg/DerelictSDL2/issues/44] is fixed) I will release the 0.5.0 version next sunday.

Is it's possible to use Dgame for iOS game developing?
AFAIK iOS LDC now support building iOS Apps. https://github.com/smolt/ldc-iphone-dev