October 19, 2019
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.
October 20, 2019
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.
October 20, 2019
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.
October 21, 2019
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
June 01

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

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

June 07

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

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

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

Next ›   Last »
1 2