digitalmars.D.announce - Dgame RC #1
- Namespace (11/11) Apr 01 2015 Since the weekend Dgame went into the release phase:
- CraigDillabaugh (7/18) Apr 01 2015 Looks nice. I've never done any real game programming, but I told
- stewarth (7/18) Apr 01 2015 Great work! I'm really enjoying using Dgame at the moment and it
- Craig Dillabaugh (30/44) Apr 01 2015 Hi. I tried to build the first tutorial example from the Dgame
- Craig Dillabaugh (17/62) Apr 01 2015 Just a follow up comment. Apparently the instructions for
- Namespace (2/13) Apr 02 2015 I will add this to the installation tutorial. Unfortunately I did
- CraigDillabaugh (7/22) Apr 02 2015 No worries, you can't test everything, and OpenSUSE isn't as
- Namespace (1/1) Apr 02 2015 The master branch should now make an automatic downgrade.
- Craig Dillabaugh (6/7) Apr 02 2015 I am still using rc1 but managed to get everything working. I
- Craig Dillabaugh (8/8) Apr 03 2015 One small note about the tutorials. In the tutorial on
- Mike Parker (17/19) Apr 02 2015 This error message is telling you two things. First, SDL is installed on...
- Mike Parker (2/3) Apr 02 2015 ...by default.
- Namespace (5/5) Apr 02 2015 I'll fix this as follows:
- Namespace (9/32) Apr 02 2015 Dgame is based on SDL 2.0.3 (as described in the installation
- Mike Parker (38/50) Apr 02 2015 None of that matters. This has nothing to do with what Dgame is
- Mike Parker (4/7) Apr 02 2015 Gah! I always forget to add the referenced links.
- Namespace (3/55) Apr 03 2015 Yes, you're right. I'll undo my changes and I'll set SDL 2.0.2 as
- Szymon Gatner (9/20) Apr 10 2015 I am getting dub error after adding dgame dependency (copy pasted
- Namespace (4/25) Apr 10 2015 Yes, I'm too. I've removed the dependency m3 but that cannot be
- stewarth (6/33) Apr 10 2015 For what it's worth I don't see this error. I just did an upgrade
- Szymon Gatner (4/39) Apr 10 2015 Yup, upgrading to dub 0.9.23 fixed the issue for me too. I
- Namespace (1/1) Apr 10 2015 Yes, I can confirm that also. That relieves me. :)
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
"CraigDillabaugh" <craig.dillabaugh gmail.com> 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
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
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../game1derelict.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.soldd game1linux-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.3uname -a17 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
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: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. CraigSince 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../game1derelict.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.soldd game1linux-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.3uname -a17 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
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-0I will add this to the installation tutorial. Unfortunately I did not tested Dgame with OpenSUSE, sorry for your trouble.
Apr 02 2015
On Thursday, 2 April 2015 at 09:30:43 UTC, Namespace wrote: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.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-0I will add this to the installation tutorial. Unfortunately I did not tested Dgame with OpenSUSE, sorry for your trouble.
Apr 02 2015
The master branch should now make an automatic downgrade.
Apr 02 2015
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
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
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? CraigHey 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
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
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
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-devNo. 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
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
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.soThis 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
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
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
On Thursday, 2 April 2015 at 07:56:19 UTC, Mike Parker wrote:On 4/2/2015 11:36 AM, Craig Dillabaugh 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.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.soThis 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
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
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 youGah! 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
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: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. :)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 03 2015
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
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: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.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
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: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, StewOn Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote: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.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
On Friday, 10 April 2015 at 10:29:32 UTC, stewarth wrote:On Friday, 10 April 2015 at 08:39:40 UTC, Namespace wrote: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.On Friday, 10 April 2015 at 08:19:14 UTC, Szymon Gatner wrote: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, StewOn Wednesday, 1 April 2015 at 18:30:01 UTC, Namespace wrote: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.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
Yes, I can confirm that also. That relieves me. :)
Apr 10 2015