Going forward, CGE doesn’t depend on Vampyre packages LPK. We of course still (proudly!) use Vampyre Imaging Library for most of our image loading/saving needs, we just refer to these units a bit differently.
There’s nothing for you to do. You can uninstall
VampyreImagingPackageExt.lpk from Lazarus IDE if you had them only for the sake of CGE. Though you don’t need to do that (you will just ev. see a message from Lazarus that multiple packages define the same unit path, which you can ignore).
The base CGE package
packages/castle_base.lpk already refers to all Vampyre units.
The goal is making installation procedure as simple as possible in all situations. The developers now do not have to be even aware about CGE-Vampyre dependency, so things are simpler if you compile from sources. Remember: if you get CGE binary package, then just use “Preferences -> Register Lazarus Packages” button (see installation manual) now and in the future, and then you don’t need to pay strict attention to what packages we use / don’t use, we will register all relevant packages.
For more information about our Lazarus packages, see packages/README.md.
…made me unsintall Vampyre, as it could not co-exist with CGE in one IDE
Sure, “…which you can ignore”, but i really don’t like flipping the coin when doing “uses” and “find declaration”
This way, would you once copy Indy inside too? No big miss for me, i dislike Indy anyway, but still…
You can let both
castle_baseand Vampyre packages be installed in one Lazarus IDE.
If your actual project uses only one of these packages, then you’re not “flipping a coin”. Lazarus project will use only the packages on which it depends, the other packages are not added to uses clauses.
So you can have both
castle*and Vampyre packages installed in one Lazarus IDE safely. Just don’t use them both in one project.
That said, if you don’t use Vampyre directly, of course you can uninstall it and be safer
No. We don’t plan to become strongly dependent on Indy.
We have 2 examples and 1 unit in CGE showcasing our integration with Indy, they are here to stay. But rest of CGE is not dependent on Indy, and majority of CGE users probably should not care about installing Indy.
CGE will likely never be strongly dependent on any particular networking library. We’re fine to offer you a choice in libraries – Network, downloading and using URLs | Manual | Castle Game Engine .
And the one networking library that we will likely focus on in the future in integration with Nakama – see Roadmap | Manual | Castle Game Engine . It is open-source higher-level networking library, that can provide services typically useful for games, and seems to correspond to similar services in other game engines. I think this would be great if it becomes fully supported for CGE.
Still, even when we will focus on Nakama – it will not be your only choice for networking.
i don’t remember it perfectly, but using a ProjectGroup to recompile all CGE at once, i think i had to explicitly add LazIndy to dependencies, or it did not compile…
I don’t know what ProjectGroup are you using… There is no ProjectGroup in CGE project for Lazarus packages.
Our packages are documented in README on castle-engine/packages at master · castle-engine/castle-engine · GitHub . Only
castle_indyrequires Indy, and other packages (like
castle_window) do not depend on
And only 2 CGE examples (in
examples/network/tcp_connection) depend on
castle_indy. If you don’t need to compile these 2 examples, then you don’t need to compile
castle_indy, and then you don’t need Indy. I don’t have Indy installed on most of my development machines, and it’s not an issue.
Perhaps we should just move the 2 Indy examples + unit to a separate repo.
Guess we already exchanged on ease of installation from sources
You seem to be mostly emacs/vsc user, only resorting to Laz when having no other choice.
You also seem to need auto-cross-build for a sdozen platforms at once.
Using shell scripts seems the natural choice for that.
But for “mere user” of the lib build-install-them-all by 1-2 mouse clicks in Laz IDE is more comfortable and manageable way
Continue the discussion at Castle Game Engine Forum