Since the weekend Dgame went into the release phase:
https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1
http://dgame-dev.de/?page=download

The Website (http://dgame-dev.de/) is fully updated  and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website).
I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;)
I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame.

On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote:
> Since the weekend Dgame went into the release phase:
> https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1
> http://dgame-dev.de/?page=download
>
> The Website (http://dgame-dev.de/) is fully updated  and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website).
> I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;)
> I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame.

Looks nice. I've never done any real game programming, but I told my kids that we should try to design some simple games together (since I want to get them interested in coding).  I am going to give Dgame a try.

Thanks for making this available.

Craig

On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote:
> Since the weekend Dgame went into the release phase:
> https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1
> http://dgame-dev.de/?page=download
>
> The Website (http://dgame-dev.de/) is fully updated  and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website).
> I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;)
> I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame.

Great work! I'm really enjoying using Dgame at the moment and it makes a really nice change from all the embedded C++ I have to do at work.

I'll make sure to go and vote too :)

Cheers,
stew

On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote:
> Since the weekend Dgame went into the release phase:
> https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1
> http://dgame-dev.de/?page=download
>
> The Website (http://dgame-dev.de/) is fully updated  and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website).
> I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;)
> I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame.

Hi. I tried to build the first tutorial example from the Dgame website.  It builds fine, but I get the following error when attempting to run.

> ./game1
derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35): Failed to load symbol SDL_HasAVX from shared library libSDL2.so

>  ldd game1
        linux-vdso.so.1 (0x00007fff25d89000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f8517616000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f85173f8000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f85170f5000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f8516eed000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f8516b3f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f851781a000)

libSDL2.so is in /usr/lib64 but I copied it to the game1 directory for good measure, but it still couldn't run.

System is 64-bit OpenSuse 13.3
> uname -a
Linux linux-qlhb.site 3.11.10-25-desktop #1 SMP PREEMPT Wed Dec 17 17:57:03 UTC 2014 (8210f77) x86_64 x86_64 x86_64 GNU/Linux

My dub.json file (dub version 0.9.22)
{
	"name": "game1",
	"description": "My first dgame attempt.",
	"copyright": "Copyright © 2015, Craig Dillabaugh",
	"authors": ["Craig Dillabaugh"],
	"dependencies": {
	    "dgame": ">=0.5.0-rc.1"
	}
}

Any tips on how to correct this would be appreciated.

On Thursday, 2 April 2015 at 02:36:52 UTC, Craig Dillabaugh wrote:
> On Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote:
>> Since the weekend Dgame went into the release phase:
>> https://github.com/Dgame/Dgame/releases/tag/v0.5.0-rc.1
>> http://dgame-dev.de/?page=download
>>
>> The Website (http://dgame-dev.de/) is fully updated  and should be useable on every device. Please let me know if you noticed unexpected behavior (at Dgame or on the website).
>> I also want to participate on "one game a month (http://www.onegameamonth.com/). I hope you will vote for me there. ;)
>> I'm sure that will bring some new light to the D community and it will be a good stress test for Dgame.
>
> Hi. I tried to build the first tutorial example from the Dgame website.  It builds fine, but I get the following error when attempting to run.
>
>> ./game1
> derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35): Failed to load symbol SDL_HasAVX from shared library libSDL2.so
>
>> ldd game1
>         linux-vdso.so.1 (0x00007fff25d89000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007f8517616000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f85173f8000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007f85170f5000)
>         librt.so.1 => /lib64/librt.so.1 (0x00007f8516eed000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007f8516b3f000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f851781a000)
>
> libSDL2.so is in /usr/lib64 but I copied it to the game1 directory for good measure, but it still couldn't run.
>
> System is 64-bit OpenSuse 13.3
>> uname -a
> Linux linux-qlhb.site 3.11.10-25-desktop #1 SMP PREEMPT Wed Dec 17 17:57:03 UTC 2014 (8210f77) x86_64 x86_64 x86_64 GNU/Linux
>
> My dub.json file (dub version 0.9.22)
> {
> 	"name": "game1",
> 	"description": "My first dgame attempt.",
> 	"copyright": "Copyright © 2015, Craig Dillabaugh",
> 	"authors": ["Craig Dillabaugh"],
> 	"dependencies": {
> 	    "dgame": ">=0.5.0-rc.1"
> 	}
> }
>
> Any tips on how to correct this would be appreciated.

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

Unfortunately libSDL2_mixer-2_0-0 install keeps failing because the OpenSuse repositories don't seem to have the file, weird!  I don't know if that is the source of my troubles but may have to build SDL form scratch.  Anyway, I have to get some sleep but I will try building SDL myself and see if that can fix things.

Craig

On 4/2/2015 11:36 AM, Craig Dillabaugh wrote:

> derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35):
> Failed to load symbol SDL_HasAVX from shared library libSDL2.so

This error message is telling you two things. First, SDL is installed on your system and the loader found it just fine. Second, the loader was unable to find the SDL_HasAVX function in libSDL2.so.

SDL_HasAVX was added to the API in SDL 2.0.2, so you have an older version installed on your system and DGame is attempting to load a more recent version. Derelict will load either SDL 2.0.2 or 2.0.3. The latter is the latest release, but there are no API differences between them.

From your end, the solution is to install the latest version of SDL2. Another solution is for DGame to take advantage of the SharedLibVersion feature of Derelict to set a minimum acceptable version of SDL. For example, if DGame doesn't use any API features added to SDL since 2.0.0, then this will allow any version of SDL2 to load:

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

Bye bye SymbolLoadException. Then again, loading the older versions makes it possible for DGame to be affected by SDL bugs that have since been fixed, so I make no judgement on whether or not it's worth it.

On 4/2/2015 4:56 PM, Mike Parker wrote:

> Derelict will load either SDL 2.0.2 or 2.0.3...

...by default.

> 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.

On Thursday, 2 April 2015 at 07:56:19 UTC, Mike Parker wrote:
> On 4/2/2015 11:36 AM, Craig Dillabaugh wrote:
>
>> derelict.util.exception.SymbolLoadException@../../../.dub/packages/derelict-util-1.9.1/source/derelict/util/exception.d(35):
>> Failed to load symbol SDL_HasAVX from shared library libSDL2.so
>
> This error message is telling you two things. First, SDL is installed on your system and the loader found it just fine. Second, the loader was unable to find the SDL_HasAVX function in libSDL2.so.
>
> SDL_HasAVX was added to the API in SDL 2.0.2, so you have an older version installed on your system and DGame is attempting to load a more recent version. Derelict will load either SDL 2.0.2 or 2.0.3. The latter is the latest release, but there are no API differences between them.
>
> From your end, the solution is to install the latest version of SDL2. Another solution is for DGame to take advantage of the SharedLibVersion feature of Derelict to set a minimum acceptable version of SDL. For example, if DGame doesn't use any API features added to SDL since 2.0.0, then this will allow any version of SDL2 to load:
>
> DerelictSDL2.load(SharedLibVersion(2,0,0));
>
> Bye bye SymbolLoadException. Then again, loading the older versions makes it possible for DGame to be affected by SDL bugs that have since been fixed, so I make no judgement on whether or not it's worth it.

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.

I'll fix this as follows:
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?