www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Dgame RC #1

reply "Namespace" <rswhite4 gmail.com> writes:
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.
Apr 01 2015
next sibling parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
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
Apr 01 2015
prev sibling next sibling parent "stewarth" <growlercab gmail.com> writes:
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
Apr 01 2015
prev sibling next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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/u il/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
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.
Apr 01 2015
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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/u il/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
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
Apr 01 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
 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.
Apr 02 2015
parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
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.
Apr 02 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
The master branch should now make an automatic downgrade.
Apr 02 2015
next sibling parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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
Apr 02 2015
prev sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
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
Apr 03 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
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. :)
Apr 04 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
Instead of opening a new post I announce here the release of the 

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.
Apr 05 2015
parent reply "Suliman" <evermind live.ru> writes:
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
Apr 05 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Sunday, 5 April 2015 at 16:39:34 UTC, Suliman wrote:
 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
No. But because I also have no iOS device, I could not test well in this respect. My next step (version 0.5.1) would be to add touch events. Maybe (full) support for Android / iOS comes with 0.5.2
Apr 05 2015
parent "Namespace" <rswhite4 gmail.com> writes:
Because of some changes, I will publish a further release 
candidate:
The changes are:
-Touch support
-Touch events
-Keyboard.Code renamed to Keyboard.Key (with deprecation of the 
old one)
-event.keyboard.code renamed to event.keyboard.key (with 
depreciation of the old one)
- Abandonment of the dependency m3. Dgame now used an internal 
module.

The final release date is still sunday evening.
Apr 09 2015
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Apr 02 2015
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 4/2/2015 4:56 PM, Mike Parker wrote:

 Derelict will load either SDL 2.0.2 or 2.0.3...
...by default.
Apr 02 2015
parent "Namespace" <rswhite4 gmail.com> writes:
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?
Apr 02 2015
prev sibling parent reply "Namespace" <rswhite4 gmail.com> writes:
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.
Apr 02 2015
parent reply "Mike Parker" <aldacron gmail.com> writes:
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.
Apr 02 2015
next sibling parent "Mike Parker" <aldacron gmail.com> writes:
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
Apr 02 2015
prev sibling parent "Namespace" <rswhite4 gmail.com> writes:
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. :)
Apr 03 2015
prev sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
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.
I am getting dub error after adding dgame dependency (copy pasted from dub page): Failed to retrieve metadata for package dgame: Could not find package candidate for dgame ==~>0.5.0-rc.3 Could not resolve dependencies The dependency graph could not be filled, there are unresolved dependencies.
Apr 10 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Friday, 10 April 2015 at 08:19:14 UTC, Szymon Gatner 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.
I am getting dub error after adding dgame dependency (copy pasted from dub page): Failed to retrieve metadata for package dgame: Could not find package candidate for dgame ==~>0.5.0-rc.3 Could not resolve dependencies The dependency graph could not be filled, there are unresolved dependencies.
Yes, I'm too. I've removed the dependency m3 but that cannot be the reason. Sadly the error message is totally unhelpfull. I will investigate that.
Apr 10 2015
parent reply "stewarth" <growlercab gmail.com> writes:
On Friday, 10 April 2015 at 08:39:40 UTC, Namespace wrote:
 On Friday, 10 April 2015 at 08:19:14 UTC, Szymon Gatner 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.
I am getting dub error after adding dgame dependency (copy pasted from dub page): Failed to retrieve metadata for package dgame: Could not find package candidate for dgame ==~>0.5.0-rc.3 Could not resolve dependencies The dependency graph could not be filled, there are unresolved dependencies.
Yes, I'm too. I've removed the dependency m3 but that cannot be the reason. Sadly the error message is totally unhelpfull. I will investigate that.
For what it's worth I don't see this error. I just did an upgrade on my projects and they pulled in RC3 and build OK. I'm on Arch x86_64 using DUB version 0.9.23, built on Apr 8 2015. Thanks, Stew
Apr 10 2015
parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 10 April 2015 at 10:29:32 UTC, stewarth wrote:
 On Friday, 10 April 2015 at 08:39:40 UTC, Namespace wrote:
 On Friday, 10 April 2015 at 08:19:14 UTC, Szymon Gatner 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.
I am getting dub error after adding dgame dependency (copy pasted from dub page): Failed to retrieve metadata for package dgame: Could not find package candidate for dgame ==~>0.5.0-rc.3 Could not resolve dependencies The dependency graph could not be filled, there are unresolved dependencies.
Yes, I'm too. I've removed the dependency m3 but that cannot be the reason. Sadly the error message is totally unhelpfull. I will investigate that.
For what it's worth I don't see this error. I just did an upgrade on my projects and they pulled in RC3 and build OK. I'm on Arch x86_64 using DUB version 0.9.23, built on Apr 8 2015. Thanks, Stew
Yup, upgrading to dub 0.9.23 fixed the issue for me too. I actually thought I had latest dub version installed, seems I didn't.
Apr 10 2015
parent "Namespace" <rswhite4 gmail.com> writes:
Yes, I can confirm that also. That relieves me. :)
Apr 10 2015