www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Any 3D Game or Engine with examples/demos which just work

reply Prokop Hapala <prokophapala gmail.com> writes:
Already >1 year I consider to move from C++ to Dlang or to Rust 
in my hobby game development (mostly based on physical 
simulations 
https://github.com/ProkopHapala/SimpleSimulationEngine). I 
probably prefer Dlang because it compiles much faster, and I can 
copy&paste C/C++ code to it without much changes.

But I cannot figure out how to jumpstart. The barrier is to 
configure environment/libraries.

Up to now I was able to compile just "First Triangle example" 
(Not sure from where I copyied it)
https://www.dropbox.com/sh/myem3g69qjyo58v/AABZuvwuRDpnskhEC4AAK5AVa?dl=0

but when I tried to clone from github some more sophisticated 
tutorials or demos it never works. Either it is Windows-only 
(Visual Studio .snl, no dub; 
https://github.com/Ingrater/Spacecraft), or there are some 
dependencies on old versions of libraries, which I don't know how 
to upgrade. Or it has some other dependecies which documentation 
does not explain how to configure on linux.

============================================================
These are some cases I tried (and problems I had):
============================================================


(https://github.com/d-gamedev-team/opengl-tutorials)

opengl-tutorials/ports/opengl-tutorial.org/$ dub
Failed to find any versions for package glad-drey, referenced by 
opengl-tutorial.org ~master

opengl-tutorials/ports/opengl-tutorial.org/tutorials/02_triangle$ 
dub
Failed to find any versions for package glamour-drey, referenced 
by gltut-utility >=0.0.0 
 /home/prokop/git_SW/_Dlang/opengl-tutorials/utility



(https://github.com/kiith-sa/d-gl-tutorial)

(dmd-2.088.0)prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_
lang/d-gl-tutorial$ ./compile.sh
./DerelictUtil-master/source/derelict/util/sharedlib.d(40): 
Error: module linux is in file 'std/c/linux/linux.d' which cannot 
be read
import path[0] = ./DerelictGL3-master/source/
import path[1] = ./DerelictSDL2-master/source/
import path[2] = ./DerelictUtil-master/source/
import path[3] = .
import path[4] = 
/home/prokop/dlang/dmd-2.088.0/linux/bin64/../../src/phobos
import path[5] = 
/home/prokop/dlang/dmd-2.088.0/linux/bin64/../../src/druntime/import
Failed: ["/home/prokop/dlang/dmd-2.088.0/linux/bin64/dmd", 
"-I./DerelictGL3-master/source/", 
"-I./DerelictSDL2-master/source/", 
"-I./DerelictUtil-master/source/", "-v", "-o-", "triangle.d", 
"-I."]


https://github.com/gecko0307/dagon)

... it compiles and produce 'libdagon.a', but what to do with it? 
there are not demos/examples

https://github.com/gecko0307/dagon-demo)

Linking...
Copying files for dagon...
Invalid source/import path: 
/home/prokop/git_SW/_Dlang/dagon-demo/shaders
Running ./dagondemo
Error: Nuklear library is not found. Please, install Nuklear.
Program exited with code 1
... Almost there, but still I don't know how to make it run

https://github.com/gecko0307/dmech)

Target is a library. Skipping execution.

https://github.com/gecko0307/dmech)

dlib 0.12.2: building configuration "library"...
../../../../.dub/packages/dlib-0.12.2/dlib/dlib/core/stream.d(228,16): Error:
module string is in file 'std/c/string.d' which cannot be read
import path[0] = ../../../../.dub/packages/dlib-0.12.2/dlib
import path[1] = 
/home/prokop/dlang/dmd-2.088.0/linux/bin64/../../src/phobos
import path[2] = 
/home/prokop/dlang/dmd-2.088.0/linux/bin64/../../src/druntime/import
/home/prokop/dlang/dmd-2.088.0/linux/bin64/dmd failed with exit 
code 1.

https://github.com/Circular-Studios/Dash)

Running pre-build commands...
cp: cannot create regular file '/usr/lib/libsoloud_x86.so': 
Permission denied
source/dash/utility/data/yaml.d(4,15): Deprecation: module yaml 
is deprecated - Import dyaml instead
../../../.dub/packages/vibe-d-0.7.33/vibe-d/source/vibe/core/log.d(554,21):
Error: Built-in hex string literals are obsolete, use
std.conv.hexString!"EFBBBF" instead.
source/dash/utility/input/input.d(7,8): Deprecation: module yaml 
is deprecated - Import dyaml instead
source/dash/core/gameobject.d(7,8): Deprecation: module yaml is 
deprecated - Import dyaml instead
source/dash/components/assets.d(10,8): Deprecation: module yaml 
is deprecated - Import dyaml instead
source/dash/components/material.d(7,8): Deprecation: module yaml 
is deprecated - Import dyaml instead
source/dash/components/mesh.d(8,19): Error: module stream is in 
file 'std/stream.d' which cannot be read


(https://github.com/Circular-Studios/Sample-Dash-Game)

logger 0.3.3: building configuration "library"...
Error: module std.experimental.logger.core from file 
../../../.dub/packages/logger-0.3.3/logger/std/experimental/logger/core.d is
specified twice on the command line
Error: module std.experimental.logger.filelogger from file 
../../../.dub/packages/logger-0.3.3/logger/std/experimental/logger/filelogger.d
is specified twice on the command line
Error: module std.experimental.logger.multilogger from file 
../../../.dub/packages/logger-0.3.3/logger/std/experimental/
ogger/multilogger.d is specified twice on the command line
Error: module std.experimental.logger.nulllogger from file 
../../../.dub/packages/logger-0.3.3/logger/std/experimental/logger/nulllogger.d
is specified twice on the command line
../../../.dub/packages/logger-0.3.3/logger/std/experimental/lo
ger/package.d(1,1): Error: module std.experimental.logger from file
../../../.dub/packages/logger-0.3.3/logger/std/experimental/logger/package.d
conflicts with package name logger
/home/prokop/dlang/dmd-2.088.0/linux/bin64/dmd failed with exit 
code 1.
Oct 17 2019
next sibling parent reply Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Friday, 18 October 2019 at 05:52:19 UTC, Prokop Hapala wrote:
 Already >1 year I consider to move from C++ to Dlang or to Rust 
 in my hobby game development (mostly based on physical 
 simulations 
 https://github.com/ProkopHapala/SimpleSimulationEngine). I 
 probably prefer Dlang because it compiles much faster, and I 
 can copy&paste C/C++ code to it without much changes.

 [...]
I cannot make any comment for others. But Dagon should work. I wrote a very little demo game some time ago https://github.com/aferust/dagon-shooter. I didn't try to compile and run it on Linux.I think you need to have a nuklear.so in your path, since Bindbc loaders try to load dynamic libraries by default.
Oct 17 2019
next sibling parent reply Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Friday, 18 October 2019 at 06:11:37 UTC, Ferhat Kurtulmuş 
wrote:
 On Friday, 18 October 2019 at 05:52:19 UTC, Prokop Hapala wrote:
 Already >1 year I consider to move from C++ to Dlang or to 
 Rust in my hobby game development (mostly based on physical 
 simulations 
 https://github.com/ProkopHapala/SimpleSimulationEngine). I 
 probably prefer Dlang because it compiles much faster, and I 
 can copy&paste C/C++ code to it without much changes.

 [...]
I cannot make any comment for others. But Dagon should work. I wrote a very little demo game some time ago https://github.com/aferust/dagon-shooter. I didn't try to compile and run it on Linux.I think you need to have a nuklear.so in your path, since Bindbc loaders try to load dynamic libraries by default.
https://github.com/Timu5/bindbc-nuklear/blob/master/README.md "This library contains prebuild windows dll for Nuklear, on different platforms you can easily build C source code from cmake configuration in c directory."
Oct 17 2019
parent reply Prokop Hapala <prokophapala gmail.com> writes:
On Friday, 18 October 2019 at 06:24:38 UTC, Ferhat Kurtulmuş 
wrote:
 On Friday, 18 October 2019 at 06:11:37 UTC, Ferhat Kurtulmuş 
 wrote:
 On Friday, 18 October 2019 at 05:52:19 UTC, Prokop Hapala 
 wrote:
 Already >1 year I consider to move from C++ to Dlang or to 
 Rust in my hobby game development (mostly based on physical 
 simulations 
 https://github.com/ProkopHapala/SimpleSimulationEngine). I 
 probably prefer Dlang because it compiles much faster, and I 
 can copy&paste C/C++ code to it without much changes.

 [...]
I cannot make any comment for others. But Dagon should work. I wrote a very little demo game some time ago https://github.com/aferust/dagon-shooter. I didn't try to compile and run it on Linux.I think you need to have a nuklear.so in your path, since Bindbc loaders try to load dynamic libraries by default.
https://github.com/Timu5/bindbc-nuklear/blob/master/README.md "This library contains prebuild windows dll for Nuklear, on different platforms you can easily build C source code from cmake configuration in c directory."
I did what you say (I guess), but Nuclear still cannot be found: prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ echo $LD_LIBRARY_PATH /home/prokop/git_SW/bindbc-nuklear/build:/home/prokop/torch/install/lib: prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ ls COPYING data dub.selections.json icon.ico input.conf rcedit-x64.exe README.md src dagondemo dub.json gamecontrollerdb.txt icon.txt libnuklear.so rcedit-x86.exe settings.conf prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ ./dagondemo Error: Nuklear library is not found. Please, install Nuklear.
Oct 18 2019
parent reply Aldo <aldocd4 outlook.com> writes:
On Friday, 18 October 2019 at 19:20:04 UTC, Prokop Hapala wrote:
 On Friday, 18 October 2019 at 06:24:38 UTC, Ferhat Kurtulmuş 
 wrote:
 On Friday, 18 October 2019 at 06:11:37 UTC, Ferhat Kurtulmuş 
 wrote:
 On Friday, 18 October 2019 at 05:52:19 UTC, Prokop Hapala 
 wrote:
 Already >1 year I consider to move from C++ to Dlang or to 
 Rust in my hobby game development (mostly based on physical 
 simulations 
 https://github.com/ProkopHapala/SimpleSimulationEngine). I 
 probably prefer Dlang because it compiles much faster, and I 
 can copy&paste C/C++ code to it without much changes.

 [...]
I cannot make any comment for others. But Dagon should work. I wrote a very little demo game some time ago https://github.com/aferust/dagon-shooter. I didn't try to compile and run it on Linux.I think you need to have a nuklear.so in your path, since Bindbc loaders try to load dynamic libraries by default.
https://github.com/Timu5/bindbc-nuklear/blob/master/README.md "This library contains prebuild windows dll for Nuklear, on different platforms you can easily build C source code from cmake configuration in c directory."
I did what you say (I guess), but Nuclear still cannot be found: prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ echo $LD_LIBRARY_PATH /home/prokop/git_SW/bindbc-nuklear/build:/home/prokop/torch/install/lib: prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ ls COPYING data dub.selections.json icon.ico input.conf rcedit-x64.exe README.md src dagondemo dub.json gamecontrollerdb.txt icon.txt libnuklear.so rcedit-x86.exe settings.conf prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ ./dagondemo Error: Nuklear library is not found. Please, install Nuklear.
Try to move that libnuklear.so or rename it to nuklear.so. I checked bindbc code and saw : version(Windows) { const(char)[][1] libNames = ["nuklear.dll"]; } else version(OSX) { const(char)[][1] libNames = ["nuklear.dylib"]; } else version(Posix) { const(char)[][2] libNames = [ "nuklear.so", "/usr/local/lib/nuklear.so", ]; }
Oct 18 2019
parent reply Prokop Hapala <prokophapala gmail.com> writes:
On Friday, 18 October 2019 at 20:09:47 UTC, Aldo wrote:
 Try to move that libnuklear.so or rename it to nuklear.so. I 
 checked bindbc code and saw :

     version(Windows) {
         const(char)[][1] libNames = ["nuklear.dll"];
     }
     else version(OSX) {
         const(char)[][1] libNames = ["nuklear.dylib"];
     }
     else version(Posix) {
         const(char)[][2] libNames = [
             "nuklear.so",
             "/usr/local/lib/nuklear.so",
         ];
     }
Great! progress! ... It shown loading splash screen and moving loading bar, when it reach the end, it segfault prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ ./dagondemo Loading scene "TestScene" Segmentation fault (core dumped) possibly it it connected with the error I saw during compilation: Copying files for dagon... Invalid source/import path: /home/prokop/git_SW/_Dlang/dagon-demo/shaders
Oct 18 2019
parent reply Prokop Hapala <prokophapala gmail.com> writes:
The whole thing is like this:

prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ source
~/dlang/dmd-2.088.0/activate
(dmd-2.088.0)prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_S
/_Dlang/dagon-demo$ dub
WARNING: A deprecated branch based version specification is used 
for the dependency dagon. Please use numbered versions instead. 
Also note that you can still use the dub.selections.json file to 
override a certain dependency to use a branch instead.
Invalid source/import path: 
/home/prokop/git_SW/_Dlang/dagon-demo/shaders
Performing "debug" build using 
/home/prokop/dlang/dmd-2.088.0/linux/bin64/dmd for x86_64.
bindbc-loader 0.1.1: target for configuration "noBC" is up to 
date.
bindbc-ft 0.1.0: target for configuration "library" is up to date.
bindbc-nuklear 0.1.0: target for configuration "dynamic" is up to 
date.
bindbc-opengl 0.4.0: target for configuration "dynamic" is up to 
date.
bindbc-sdl 0.4.1: target for configuration "dynamic" is up to 
date.
dlib 0.16.0: target for configuration "library" is up to date.
dagon ~dev_0.10: target for configuration "library" is up to date.
dagondemo 0.10.0+commit.6.gdf2dd63: target for configuration 
"application" is up to date.
To force a rebuild of up-to-date targets, run again with --force.
Copying files for dagon...
Invalid source/import path: 
/home/prokop/git_SW/_Dlang/dagon-demo/shaders
Running ./dagondemo
Oct 18 2019
parent reply Prokop Hapala <prokophapala gmail.com> writes:
The dmech/demos also seems to be almost running just it somehow 
cannot find or use my libsdl.so library which it just compiled 
(it is in 'dmech/demos/lib')


(dmd-2.088.0)(dmd-2.088.0)prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW
_Dlang/dmech/demos$ dub
Performing "debug" build using 
/home/prokop/dlang/dmd-2.088.0/linux/bin64/dmd for x86_64.
dlib 0.16.0: target for configuration "library" is up to date.
demo ~master: target for configuration "pyramid" is up to date.
To force a rebuild of up-to-date targets, run again with --force.
Running ./pyramid
derelict.util.exception.SharedLibLoadException derelict/util/exception.d(43):
Failed to load one or more shared libraries:
	./lib/libsdl.so - ./lib/libsdl.so: wrong ELF class: ELFCLASS32
----------------
derelict/util/exception.d:75 void 
derelict.util.exception.SharedLibLoadException.throwNew(const(char[][]),
const(char[][])) [0x55ecce3ed712]
derelict/util/sharedlib.d:221 void 
derelict.util.sharedlib.SharedLib.load(immutable(char)[][]) 
[0x55ecce3edef3]
derelict/util/loader.d:91 void 
derelict.util.loader.SharedLibLoader.load(immutable(char)[][]) 
[0x55ecce3edb54]
derelict/util/loader.d:86 void 
derelict.util.loader.SharedLibLoader.load(immutable(char)[]) 
[0x55ecce3edb25]
dgl/core/application.d:185 void 
dgl.core.application.loadLibraries() [0x55ecce3f1127]
pyramid.d:385 _Dmain [0x55ecce406a68]
Program exited with code 1
Oct 18 2019
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 19 October 2019 at 00:57:48 UTC, Prokop Hapala wrote:
 The dmech/demos also seems to be almost running just it somehow 
 cannot find or use my libsdl.so library which it just compiled 
 (it is in 'dmech/demos/lib')
 derelict.util.exception.SharedLibLoadException derelict/util/exception.d(43):
Failed to load one or more shared libraries:
 	./lib/libsdl.so - ./lib/libsdl.so: wrong ELF class: ELFCLASS32
The problem is there in the error message. You have a 32-bit version of SDL, but you're compiling a 64-bit app. You need the 64-bit SDL.
Oct 18 2019
parent Prokop Hapala <prokophapala gmail.com> writes:
On Saturday, 19 October 2019 at 01:53:11 UTC, Mike Parker wrote:
 On Saturday, 19 October 2019 at 00:57:48 UTC, Prokop Hapala 
 wrote:
 The dmech/demos also seems to be almost running just it 
 somehow cannot find or use my libsdl.so library which it just 
 compiled (it is in 'dmech/demos/lib')
 derelict.util.exception.SharedLibLoadException derelict/util/exception.d(43):
Failed to load one or more shared libraries:
 	./lib/libsdl.so - ./lib/libsdl.so: wrong ELF class: ELFCLASS32
The problem is there in the error message. You have a 32-bit version of SDL, but you're compiling a 64-bit app. You need the 64-bit SDL.
Aha, my bad. Great! It works now. I just replace binary libs in /dmech/demos/lib/ subdir by links to my system ones ( /usr/lib/x86_64-linux-gnu/libfreetype.so.6.15.0 and /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4 ) I just put there link to `` It works now. Great. Now I comparing dmech in comparison with Rust's https://github.com/rustsim/nphysics/ and I have to say I like dmech much more. - dmech is much faster to compile ( nphysics takes 3 minutes in debug and fucking 20 minutes in release ) - dmech code is much smaller and easier to understand. Actually dmech is perhaps the cleanest and easiest to understand physics engine I ever seen. (I was looking on Bullet and Newton before). Perhaps there is less functionality and optimalizations, but that is exactly what I search - something didactic an easy to get - Keep-it-simpple. Thanks a lot.
Oct 20 2019
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 18 October 2019 at 06:11:37 UTC, Ferhat Kurtulmuş 
wrote:
 On Friday, 18 October 2019 at 05:52:19 UTC, Prokop Hapala wrote:
 Already >1 year I consider to move from C++ to Dlang or to 
 Rust in my hobby game development (mostly based on physical 
 simulations 
 https://github.com/ProkopHapala/SimpleSimulationEngine). I 
 probably prefer Dlang because it compiles much faster, and I 
 can copy&paste C/C++ code to it without much changes.

 [...]
I cannot make any comment for others. But Dagon should work. I wrote a very little demo game some time ago https://github.com/aferust/dagon-shooter. I didn't try to compile and run it on Linux.I think you need to have a nuklear.so in your path, since Bindbc loaders try to load dynamic libraries by default.
This is what I get when I clone dagon-shooter and build it with "dub": WARNING: A deprecated branch based version specification is used for the dependency dagon. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. WARNING: A deprecated branch based version specification is used for the dependency bindbc-soloud. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Performing "debug" build using C:\tools\dmd.2.088.1.windows\dmd2\windows\bin\dmd.exe for x86_64. bindbc-loader 0.2.1: target for configuration "noBC" is up to date. bindbc-soloud ~master: target for configuration "library" is up to date. bindbc-opengl 0.8.0: target for configuration "dynamic" is up to date. bindbc-sdl 0.8.0: target for configuration "dynamic" is up to date. dlib 0.17.0-beta1: target for configuration "library" is up to date. dagon ~master: target for configuration "library" is up to date. dagon-shooter ~master: building configuration "application"... source\enemy.d(10,1): Error: undefined identifier EntityController source\enemy.d(16,19): Error: function enemyctrl.EnemyController.update does not override any function source\enemy.d(48,1): Error: undefined identifier EntityController source\enemy.d(77,19): Error: function enemyctrl.BoomController.update does not override any function source\mainscene.d(80,17): Error: undefined identifier LightSource source\mainscene.d(82,21): Error: undefined identifier FirstPersonView source\mainscene.d(93,16): Error: undefined identifier NuklearGUI source\mainscene.d(95,15): Error: undefined identifier FontAsset source\mainscene.d(102,5): Error: undefined identifier SceneManager source\mainscene.d(128,19): Error: function mainscene.MainScene.onAssetsRequest does not override any function source\mainscene.d(198,19): Error: function mainscene.MainScene.onAllocate does not override any function source\mainscene.d(469,19): Error: function void mainscene.MainScene.onUpdate(double dt) does not override any function, did you mean to override void dagon.resource.scene.Scene.onUpdate(Time t)? source\mainscene.d(541,1): Error: undefined identifier SceneApplication C:\tools\dmd.2.088.1.windows\dmd2\windows\bin\dmd.exe failed with exit code 1.
Oct 20 2019
parent reply Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Sunday, 20 October 2019 at 22:48:25 UTC, Jonathan Marler wrote:
 On Friday, 18 October 2019 at 06:11:37 UTC, Ferhat Kurtulmuş 
 wrote:
 On Friday, 18 October 2019 at 05:52:19 UTC, Prokop Hapala 
 wrote:
 Already >1 year I consider to move from C++ to Dlang or to 
 Rust in my hobby game development (mostly based on physical 
 simulations 
 https://github.com/ProkopHapala/SimpleSimulationEngine). I 
 probably prefer Dlang because it compiles much faster, and I 
 can copy&paste C/C++ code to it without much changes.

 [...]
I cannot make any comment for others. But Dagon should work. I wrote a very little demo game some time ago https://github.com/aferust/dagon-shooter. I didn't try to compile and run it on Linux.I think you need to have a nuklear.so in your path, since Bindbc loaders try to load
It looks like the maintainer of dagon changed the API a lot. I could run my demo game using version 0.10.0. dub.json: { "description": "My first project", "dependencies": { "dagon": "0.10.0", "bindbc-soloud": "*" }, "authors": [ "aferust" ], "copyright": "Copyright © 2019, aferust", "license": "Boost", "name": "dagon-shooter" } But texture rendering seems weird for some reason. Obviously, dagon-shooter needs some updates according to new dagon API
Oct 21 2019
parent reply Prokop Hapala <prokophapala gmail.com> writes:
After some sime I tried to return to this, using dependency on 
older version of dagon

I got errors in dlib
Not sure how to understadn this

```
Error: incompatible types for (box.pmax) - (box.center): both 
operands are of type Vector!(float, 3)
```

If both operands are the same time `Vector!(float, 3)` I would 
think the subtractioon is defined in dlib ... why not ?


```
prokop prokop-Lenovo-ideapad-Y700-15ISK:~/git_SW/_Dlang/dagon-demo$ dub
Performing "debug" build using /usr/bin/dmd for x86_64.
bindbc-loader 0.1.1: target for configuration "noBC" is up to 
date.
bindbc-soloud 0.1.0: target for configuration "library" is up to 
date.
bindbc-ft 0.1.0: target for configuration "library" is up to date.
bindbc-nuklear 0.1.0: target for configuration "dynamic" is up to 
date.
bindbc-opengl 0.4.0: target for configuration "dynamic" is up to 
date.
bindbc-sdl 0.4.1: target for configuration "dynamic" is up to 
date.
dlib 0.16.0: building configuration "library"...
../../../.dub/packages/dlib-0.16.0/dlib/dlib/coding/varint.d(42,22):
Deprecation: returning this.buffer[0..this.size] escapes a reference to
parameter this
../../../.dub/packages/dlib-0.16.0/dlib/dlib/coding/varint.d(42,22):       
perhaps annotate the parameter with return
../../../.dub/packages/dlib-0.16.0/dlib/dlib/filesystem/stdfs.d(432,13):
Deprecation: opIn_r is deprecated.  Use opBinaryRight(string op)(...) if (op ==
"in") instead.
../../../.dub/packages/dlib-0.16.0/dlib/dlib/filesystem/stdfs.d(550,36):
Deprecation: returning this.str[0..cast(ulong)this.length] escapes a reference
to parameter this
../../../.dub/packages/dlib-0.16.0/dlib/dlib/filesystem/stdfs.d(550,36):       
perhaps annotate the parameter with return
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/aabb.d(50,16): Error:
incompatible types for (this.center) - (this.size): both operands are of type
Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/aabb.d(51,16): Error:
incompatible types for (this.center) + (this.size): both operands are of type
Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/aabb.d(85,22): Error:
incompatible types for (b.center) - (this.center): both operands are of type
Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/aabb.d(103,26): Error:
incompatible types for (sphere.center) - (xClosest): both operands are of type
Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/aabb.d(111,27): Error:
incompatible types for (xDiff) / (fDist): Vector!(float, 3) and float
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/aabb.d(181,19): Error:
incompatible types for (box.pmax) + (box.pmin): both operands are of type
Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/aabb.d(182,16): Error:
incompatible types for (box.pmax) - (box.center): both operands are of type
Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(62,23):
Error: incompatible types for (sphere1.center) - (sphere2.center): both
operands are of type Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(63,21):
Error: incompatible types for (sphere2.center) +
(res.normal.opBinary(sphere2.radius)): both operands are of type Vector!(float,
3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(75,32):
Error: incompatible types for (sphere.center) - (plane.d): Vector!(float, 3)
and float
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(81,21):
Error: incompatible types for (sphere.center) -
(res.normal.opBinary(sphere.radius)): both operands are of type Vector!(float,
3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(95,21):
Error: incompatible types for (center) - (tri.v[cast(ulong)whichVert]): both
operands are of type Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(103,24):
Error: incompatible types for (center) - (result.normal.opBinary(radius)): both
operands are of type Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(126,13):
Deprecation: opMulAssign is deprecated.  Use opOpAssign(string op)(...) if (op
== "*") instead.
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(127,27):
Error: incompatible types for (center) - (tri.v[cast(ulong)whichVert0]): both
operands are of type Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(129,24):
Error: incompatible types for (tri.v[cast(ulong)whichVert0]) +
(dir.opBinary(dot)): both operands are of type Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(132,25):
Error: incompatible types for (center) - (project): both operands are of type
Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(140,28):
Error: incompatible types for (center) - (result.normal.opBinary(radius)): both
operands are of type Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(165,25):
Error: incompatible types for (sphere.center) -
(tri.normal.opBinary(distFromPlane)): both operands are of type Vector!(float,
3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(172,24):
Error: incompatible types for (sphere.center) -
(tri.normal.opBinary(factor).opBinary(sphere.radius)): both operands are of
type Vector!(float, 3)
../../../.dub/packages/dlib-0.16.0/dlib/dlib/geometry/intersection.d(213,31):
Error: incompatible types for (s.center) - (translation(b.transform)): both
operands are of type Vector!(float, 3)
/usr/bin/dmd failed with exit code 1.
```
Jun 01 2021
parent reply evilrat <evilrat666 gmail.com> writes:
On Tuesday, 1 June 2021 at 20:07:39 UTC, Prokop Hapala wrote:
 After some sime I tried to return to this, using dependency on 
 older version of dagon

 I got errors in dlib
 Not sure how to understadn this

 ```
 Error: incompatible types for (box.pmax) - (box.center): both 
 operands are of type Vector!(float, 3)
 ```

 If both operands are the same time `Vector!(float, 3)` I would 
 think the subtractioon is defined in dlib ... why not ?
Error messages sucks sometimes. It is likely related to const/ref combinations, for example vector operator- overloads accepting const refs and you have regular mutable vectors. D ref's is somewhat messy. Anyway I tried dagon in past and I don't see why bother with it, better stick with something that can handle industry standard formats such as FBX, another issue is shaders fused in right in the engine. As an alternative the only thing probably worth checking is godot-d which is native interface for scripting in Godot Engine. This engine has its quirks though (my most hated "feature" is that it requires you to create script config for each your native class).
Jun 01 2021
parent reply Prokop Hapala <ProkopHapala gmail.com> writes:
thanks, evilrat

 Anyway I tried dagon in past and I don't see why bother with 
 it, better stick with something that can handle industry 
 standard formats such as FBX, another issue is shaders fused in 
 right in the engine.
 As an alternative the only thing probably worth checking is 
 godot-d which is native interface for scripting in Godot 
 Engine. This engine has its quirks though (my most hated 
 "feature" is that it requires you to create script config for 
 each your native class).
Basically I'm desperate do find anything which encapsulates OpenGL calls into some nice D-lang classes to learn from it. I don't really want to use Dagon, nor Godot. What I want is to use it as learning resources fro learning graphics programming in Dlang. Rewriting my graphics engine from C++ to Dlang is huge barrier for me, sice I don't know Dlang enough. I want to see some nice Tricks and convenience of Dlang features applied to graphics programming. Ability to compile without much hessel is minimal requirement for me. The only thing which I was able to compile up to no was dmech, which is nice for physics but very old OpenGL
Jun 07 2021
next sibling parent drug <drug2004 bk.ru> writes:
07.06.2021 17:02, Prokop Hapala пишет:
 Basically I'm desperate do find anything which encapsulates OpenGL calls 
 into some nice D-lang classes
Did you try gfm? specifically its 7th version - [gfm7](https://github.com/drug007/gfm7)? It has nice [classes](https://github.com/drug007/gfm7/tree/master/opengl/gfm/opengl) to wrap OpenGL but the online documentation is currently unavailable. But the library itself is pretty nice documented. Ask me if you will help with it.
Jun 07 2021
prev sibling parent evilrat <evilrat666 gmail.com> writes:
On Monday, 7 June 2021 at 14:02:14 UTC, Prokop Hapala wrote:
 Basically I'm desperate do find anything which encapsulates 
 OpenGL calls into some nice D-lang classes to learn from it. I 
 don't really want to use Dagon, nor Godot. What I want is to 
 use it as learning resources fro learning graphics programming 
 in Dlang.

 Rewriting my graphics engine from C++ to Dlang is huge barrier 
 for me, sice I don't know Dlang enough. I want to see some nice 
 Tricks and convenience of Dlang features applied to graphics 
 programming.

 Ability to compile without much hessel is minimal requirement 
 for me.
 The only thing which I was able to compile up to no was dmech, 
 which is nice for physics but very old OpenGL
Ok then, no dagon won't help you that much IMHO. There is definitely a lot of projects on github with some basic engine-like functionality which encapsulates VBO, shaders, and stuff. Nothing specific that comes to mind but they do exist.(uh, maybe serpent engine?) They are however mostly quickly hacked up student's homework rather than designed solid projects, so I again suggest you to try godot for anything serious. It's all shaders after all, doing VBO and render pipeline setups is not that much fun. For learning graphics programming however D is ok, but you will definitely almost on your own, still github is your friend, look for existing projects on github (for example dash) on how it can be done. As for actual language features that might help - that will be reflection and meta-programming. With them you can generate everything from the code - VBO's, render passes, etc... Make declarative DSL from that to rule them all! It's fancy and all, but it is only slightly better than C++ (esp. since it has shitty OpenGL/vulkan loaders and clumsy build tools) and there's nothing new compared to it. And final option would be to make bindings for your existing C++ code, either manually or with tools (like my own generator) https://github.com/Superbelko/ohmygentool
Jun 07 2021
prev sibling parent reply Elronnd <elronnd elronnd.net> writes:
 Up to now I was able to compile just "First Triangle example" 
 https://www.dropbox.com/sh/myem3g69qjyo58v/AABZuvwuRDpnskhEC4AAK5AVa?dl=
Why not start with that, then, and expand it until it has everything you need? If it helps, the basic gl startup code for my engine is at http://ix.io/1Z2X/d and http://ix.io/1Z2Y/d (engine is closed-source, but feel free to steal that part for w/e you want). Obviously depends on a bunch of other infrastructure, but should be enough to get the idea. In the second link, you probably only want the constructor; everything else is irrelevant windowing stuff or boilerplate. I guess I'm mostly confused as to what your roadblock is: once you've imported derelict.opengl, you have all the same opengl functions as you would have in c++; once you've imported derelict.sdl, you have all the same sdl functions as in c++. The only thing I can think of aside from that is math or gui libs--but in your c++ engine, it looks like you implemented those from scratch. By the way, I recommend using bindbc (https://github.com/bindbc) wrappers over derelict ones, if available, because mike isn't really maintaining derelict anymore. He was pretty much the sole maintainer. I'm currently using a weird branch of derelictsdl for vulkan support, and a custom version of derelictassimp so it doesn't break.
Oct 17 2019
parent Prokop Hapala <prokophapala gmail.com> writes:
On Friday, 18 October 2019 at 06:36:49 UTC, Elronnd wrote:
 I guess I'm mostly confused as to what your roadblock is: once 
 you've imported derelict.opengl, you have all the same opengl 
 functions as you would have in c++; once you've imported 
 derelict.sdl, you have all the same sdl functions as in c++.  
 The only thing I can think of aside from that is math or gui 
 libs--but in your c++ engine, it looks like you implemented 
 those from scratch.
The point is, I would like first to try some existing Dlang-based game or engine, to evaluate if Dlang really gives me so much more advantage/convenience over C++ (or Rust). Depending on that I will decide if it is worth to invest the effort to migrate all my stuff to Dlang. Also while in C/C++ I hacked most of functionality (math,GUI,renderer,physics-engine) from scratch, I would prefer to rely on some solid reliable standard libraries from Dlang. My stuff is usually kinda "The best you can make in one week". One reason why I re-implemented so much things (like GUI, which I really hate to do) is because I find it quite painful to install&configure libraries in C/C++ (especially when versions changes). I hope that with Dlang's Dub or Rust's Cargo this will be much easier and I will use 3rd party libraries more.
Oct 18 2019