I meant dropping HAIKU_PATCH of course, why else I would suggest resetting revision to 1 in the first place? In any case this is fixed now, so all is good! 
PR is merged, build is still running at the moment, should be done shortly
Drag[en]gine 1.9 and DEMoCap 0.4 Release. Did not do the release post yet but basically worked on getting DEMoCap 0.4 out of the the door the game engine release has some new features and bug fixes.
Pull Request Send in.
If somebody wants to test this against the OpenGL driver you can use DEMoCap. It starts with VR mode disabled so you can mess around in the tool if you want to.
1 Like
Not had the chance to try this but very intrigued. Great work!
Has x512 tested yet ? With 3d Accel ?
Build failures (as did the previous version): dragengine-1.11 by LordOfDragons · Pull Request #6776 · haikuports/haikuports · GitHub
I did not notice your comment on the last pull request. No idea why. Should be fixed now although I had troubles to update the recipe with the fixed version.
Already replied to your new PR, conflicting files now …
Edit, it wasn’t my git day either yesterday 
A quick question. My game engine has now nightlies using GitHub instead of internal ones: Actions · LordOfDragons/dragengine · GitHub . Does Haiku have crosscompilers for linux or similar? If so I could add another task to handle Haiku builds 
2 Likes
Drag[en]gine 1.13 is now officially released together with DENetwork Library 1.0 and DEMoCap 0.7 (which you can now access using Unreal Live Link).
DENetwork Library allows to make any application communicate with Drag[en]gine games and applications using DNP (Drag[en]gine Network Protocol). I have not updated the recipe yet since I had to do with DEMoCap. I will do this this week-end. Furthermore I’ll make some modifications on DENetwork Libraries so it runs also on Haiku. That is if you use C++. The java version should work already. I will not make a recipe for DENetwors Library since this one is supposed to be statically linked by applications so placing it in the system is not sensible.
For the fun of it some DEMoCap videos
7 Likes
Have you considered adding support for GameNetworkingSockets?
It is battle-tested in production (as SteamNetworkingSockets) and can work with or without Steam.
As far as I can see it only supports message passing but no state linking. I also see no mentioning of java and python support without spending extra time trying to interface against a C library. DNP I’ve designed to keep things simple and I will extend in a backwards compatible way in the future as requirements/desires come in. Things like message lanes or encryption are potential candidates. That said state linking in DNP removes most needs for message lanes so I did not require them so far.
That said when somebody connects over DNP the first step is a message exchange to figure out what protocols each side supports and picking one to speak. Theoretically it would be possible the server accepts such a network protocol and a switch can be made. But this would fragment implementations causing potential problems down the line. Hence for the time being I have not planed to pull in other protocol unless strong requirements require it.
1 Like
Documentation for the Steam version of GameNetworkingSockets:
https://partner.steamgames.com/doc/api/ISteamNetworkingSockets
Perhaps that can help clarify what its capabilities are, although everything there related to Steam Datagram Relay isn’t applicable.
Seems similar stuff is written as on the project page. In some parts even more narrow (requirement to go through valve network for example). It’s always a thing with these network libraries for game use. Many things increase the feature list and are nice for regular connections but less useful so for game scenarios. That has been one of the reasons I made that protocol back then. Start simple and then only add what is really needed. Keep the beast slim. And fat dragons don’t fly that good any more
1 Like
How does the networking protocol look likr? I’ve looked at it and it seems to use ipv4 only but I can’t figure out if it uses udp or tcp or any kind of encryption.
For my love2d game I want to make a networking lib based on DTLS+SCTP6 (falling back to SCTP4, then UDP6 then UDP4 etc; plus one of those stupid websocket connections. The nice thing is that all of those are message oriented)
@nephele The network protocol is documented here: Drag[en]gine Network Protocol Specification. It is UDP based but you can (using DENetwork Library) add your own socket implementation if you want to use a different communication channel. Right now I use IPv4 since let’s be honest, you don’t need IPv6 features for game communication. If it is required once I’ll add it. Encryption is something I can add later on if required. In my opinion encryption is overrated in game protocols. I’ve looked at that topic in my bachelor thesis and I don’t think it’s worth the overhead and complexity it introduced. But that can be debated of course. I’m open for suggestions to improve and stuff like IPv6 and encryption I have on a look-at-later list so it’s not off the table just not high up on my TODO list.
@Begasus Pull request for 1.13 version is live now. github.com/haikuports/haikuports/pull/7058
2 Likes