Is the developer of this still here?

[Nathidraws]

No activity after 2018..

[RICCIARDI-Adrien]

It would be great to continue this awesome project !

[vvs-]

That's not the real problem, anyone can fork it. But to be actually useful, any project should have a maintainer who will set real goals and responsibly dedicate efforts to achieve all these goals in foreseeable future. Among others such goals apparently should include actual documentation and regular builds for all supported platforms. There is no sense in yet another dead project.

[RICCIARDI-Adrien]

Sure, there are already plenty of forks. What's cool with OpenTomb is that it is the original project !
Maybe all people wishing to participate could think of a roadmap and do some tasks until TeslaRus returns ?
For instance, @vvs- suggestion about regular builds may be achieved with GitHub Actions.

[vvs-]

If indeed there were any people who wanted to work on this project they'd do something already. But unfortunately there is virtually no documentation, no standard Windows (or Mac OS) build environment and plenty of fundamental incompatibilities and bugs, e.g #91 or #417. There already were few attempts to set up nightly builds with Travis but nothing sustainable so far.

Of course, anyone is welcome to resolve all this.

[Gh0stBlade]

The last commit was made September 2019. Have some patience.

[RICCIARDI-Adrien]

As TeslaRus was building OpenTomb with Cygwin on Windows, it may be possible to create an automated Windows build using a GitHub Actions Ubuntu image with mingw. I already did that for another project, so I can give a try if the community is OK.

Another suggestion of something I should be able to do : rename repo autoexec.lua and config.lua to autoexec_dev.lua and config_dev.lua, so they are not loaded by default, and provide clean scripts for users so they do not get lost when starting the engine. This would imply setting the same keymap as original PC tomb raiders by default, as people may be more familiar with this mapping.
What do you think about these proposals ?

[vvs-]

The development process of this project is not community driven - it follows benevolent dictator pattern. There was a short period of time when there was attempt to make decisions collectively, but that attempt failed miserably and the project lost all of its other developers. After return of TeslaRus only he led the project and made design decisions. Nobody else, except him and Lwmte could change global repository settings.

I can only suggest to make all changes in your own fork and hope that your PRs will be merged back into this repository eventually. But honestly, the future of this project is uncertain at this point. There were no significant work in this repository by its principal author since November 2018.

[RICCIARDI-Adrien]

Thank you @vvs- for information and advices.
Linux and Windows CI builds (see #601) are working on Ubuntu. If pull request is accepted, I can try automatic deployment for Windows build (and also fix Windows build warnings).

[RICCIARDI-Adrien]

Hi everyone,
What do you think about automatic Windows builds deployment to repo GitHub release ?
Every successful Windows CI build would zip all needed files and automatically release the resulting archive.
I can try adding this feature using https://github.com/marketplace/actions/upload-to-github-release, or maybe another GitHub Action if you know one that works fine.

[vvs-]

That would be a proper way to deploy packages.

But that means keeping Windows binaries in the public source repository would make even less sense, of course. And I personally wouldn't welcome yet Mac OS binaries, iOS binaries, Darwin binaries and whatnot. Users should not be expected to install from sources and programmers should build instrumented libraries from sources for debugging. Besides, this might complicate packaging for Linux distributions.

To reiterate, keeping binaries in VCS is bad practice: it uselessly bloats resources for development on other platforms (multiply repository size on total count of all your repositories), it negatively affects build reproducibilty and security, makes it impossible to identify exact sources used, creates maintenance problems and bitrot and is difficult to debug and update, etc.

Please, build and deploy platform specific libraries from a separate repository. Use package management or binary caches if necessary, e.g. Nix. Make it explicit instead of hiding it in source tree. Using bad engineering discipline might repel developers from a project and IIRC similar arguments already cost this project too much.

[RICCIARDI-Adrien]

Yes, I know about binaries in VCS. The only remaining binaries are SDL ones. Instead of keeping them in the repo, I can try to download them during make install phase, like I already did here.
The goal of embedding such bloat was to make life easier for Windows developers, as a lot of issues are about Windows build.

Next moves :

• Removing binaries from repo.
• Automatic Windows deployment.
• Maybe MacOS CI build and deployment.

[vvs-]

Removing binaries from repo

That won't work, you can't remove anything from git repository - it will remain there forever in the history.

The goal of embedding such bloat was to make life easier for Windows developers, as a lot of issues are about Windows build.

Believe me, if everyone will try to make only their own life easier you won't like it either. I couldn't even notice those binaries between those massive file copies. My browser would die every time I visited changed files tab.

There is one question remained. We had clang build alongside gcc in Travis. Now we seems to trade it for Windows build instead. Why? I'd expect that Windows build would be added to the existing ones, not replacing it.

IMHO, the only sane way to repair the harm would be to restore repository state to the last commit before the PR. Then we should try it again with lessons learnt:

• No mass updates in PRs, unless it's a trivial reformatting
• No binaries
• Only small, related, isolated, incremental changes, which are possible to review

[RICCIARDI-Adrien]

Hi,

That won't work, you can't remove anything from git repository - it will remain there forever in the history.

We can still rewrite repo history by force pushing as there are no new commits for now, but currently .git directory is only about ~60MB, which is not really massive.

Believe me, if everyone will try to make only their own life easier you won't like it either. I couldn't even notice those binaries between those massive file copies. My browser would die every time I visited changed files tab.

I don't use Windows, it was only a tentative to help !
I added stock external source code, as it is way more easy to maintain and update that manually reworked code for each extern lib. That's why there are so much files. However, I think there is no really alternative than a mass update for this case.

There is one question remained. We had clang build alongside gcc in Travis. Now we seems to trade it for Windows build instead. Why? I'd expect that Windows build would be added to the existing ones, not replacing it.

I totally missed clang build, thank you for pointing it. I will add it to GitHub Actions.

IMHO, the only sane way to repair the harm would be to restore repository state to the last commit before the PR. Then we should try it again with lessons learnt:

I'm not opposed to redoing this pull request and rewriting history. The question is : do we add required dependencies source code to extern directory in the new pull request or not ?

[RICCIARDI-Adrien]

As you suggested before @vvs-, we can create a separate repository with Windows and other OSes prebuilt dependencies (with headers), then let each developer retrieve this repository to allow building on his OS. This same repository could also be used for CI and CD. This way, OpenTomb extern directory can even be removed.

[vvs-]

We can still rewrite repo history by force pushing as there are no new commits for now, but currently .git directory is only about ~60MB, which is not really massive.

That's the plan. Or we could create another branch from the last good commit, remove master and rename that branch back to master. We've already done this in the past. The abandoned history is still there as the backup branch. That was the last community developed version.

The question is : do we add required dependencies source code to extern directory in the new pull request or not ?

we can create a separate repository with Windows and other OSes prebuilt dependencies (with headers)

That's the tough question. I wasn't kidding when I said that this project is not community driven. There is only one principal developer in this public repository - TeslaRus. There is no point for us to discuss what should be done without his approval first. The other alternative would be you getting all the required credentials from him and become leading developer with all responsibilities 😜

Personally, I'm in favor of your proposal to move all external dependencies out of this repository.

[Nathidraws]

Whatever happens I'm glad I brought you all back here Lol.

[vvs-]

BTW I've forked last good commit before the controversial PR into revert branch. So, you can still work and make new PRs with it as a base branch instead of master until this all settles.

[RICCIARDI-Adrien]

The other alternative would be you getting all the required credentials from him and become leading developer with all responsibilities 😜

I'm not skilled enough for that !

That's the tough question. I wasn't kidding when I said that this project is not community driven. There is only one principal developer in this public repository - TeslaRus. There is no point for us to discuss what should be done without his approval first.

Sure, we will wait for his feedback before doing anything.
@TeslaRus, what do you think about such an external repository gathering OS-specific deployment assets and all needed stuff to generate these assets ?
This work would also allow to remove Linux build dependency on OpenTomb-provided Lua and use distro-provided one (and maybe use some work from pull request #541).

BTW I've forked last good commit before the controversial PR into revert branch. So, you can still work and make new PRs with it as a base branch instead of master until this all settles.

Thank you.

[TeslaRus]

We can still rewrite repo history by force pushing as there are no new commits for now, but currently .git directory is only about ~60MB, which is not really massive.

Delete unnecessary binaries is a good idea )

This work would also allow to remove Linux build dependency on OpenTomb-provided Lua and use distro-provided one (and maybe use some work from pull request #541)....

ok, good, less external dependencies

[TeslaRus]

other questions - need time...
First gameplay tasks:

• update mobs AI (OL is good code example, how to do it)
• fast triggers fixes (I.E. move stand condition from trigger to kill trigger function)

[TeslaRus]

P.S. Thanks for interest to the project ;-)

[RICCIARDI-Adrien]

It's a great project, I would love playing all classic Tomb Raiders on Linux without Wine or DOSBox.

Maybe you can create the dependencies repository, so I can start adding dependencies to it.
This way, I can use these dependencies in OpenTomb revert branch, and when it's ready we can replace master.

What do you think about linking this dependencies repository to OpenTomb one by a git submodule, so it is easy to retrieve ?

[vvs-]

I don't think that submodule makes retrieving dependencies much easier. It's kinda dumb in that regard. It actually should solve a different problem - managing versions of dependencies inside the main repository. But do we really need that? I'm unable to recall if versions of supporting libraries were ever tied to OpenTomb. Looks like overengineering to me.

I think that by "easy" you are actually referring to its purported ability to manage dependencies in a platform agnostic way. But what it basically does is just downloading and unpacking some archive. The only advantage I can see is its simplistic UI for that task. What is the expected scenario on the developer's workspace? Keep in mind that most developers use some IDE which might have a better integration with some sort of package manager. I'm not sure.

[vvs-]

As we all agreed previously, master branch was replaced by revert, so that we could attempt to implement GH actions workflow without the binaries waste.

Please, note, that you might need to reset you workspace to correspond to the new master branch, otherwise you might be unable to update from the repository.

[RICCIARDI-Adrien]

Great, I will start as soon as possible.
Future work might address following issues (listed here to not forget) :

• Handling of external libraries #115
• Hosting nightly builds #169
• Building from sources #430
• Get rid of MINGW hack #540

[RICCIARDI-Adrien]

Hi @TeslaRus and @vvs-,
How do we call the dependencies directory ? Something like OpenTombDependencies ?
Do we ask developers to download this directory into OpenTomb directory or close to it ? Maybe having this directory into OpenTomb one would shorten paths in OpenTomb CMakeLists.txt.

[TeslaRus]

old "extern" directory should be and contain "al", "bullet", "freetype2", "lua";
all other external libs should be in "thirdparty" directory (where "thirdparty" should be - I forget how it place in other projects... near "src" folder...)

[RICCIARDI-Adrien]

So the final architecture of the dependencies repository, once downloaded to OpenTomb one, would be something like that ?

OpenTomb
|
+--src
|
+--...
|
+--thirdparty
   |
   +--lua
   |  |
   |  +--bin
   |  |  |
   |  |  +--windows_x86
   |  |  |
   |  |  +--windows_x64
   |  |  |
   |  |  +--...
   |  |
   |  +--src
   |
   +--sdl2
   |  |
   |  +--bin
   |  |  |
   |  |  +--windows_x86
   |  |  |
   |  |  +--windows_x64
   |  |  |
   |  |  +--...
   |  |
   |  +--src
   |
   +--...

[vvs-]

I don't think that this directory tree is correct, e.g. Lua is in thirdparty but should be in extern. At least that's what TeslaRus said above.

[RICCIARDI-Adrien]

So we have some dependencies in extern and the other ones in thirdparty ? What is the purpose of this organization ?

[vvs-]

Probably that's a misunderstanding and everyone interprets some words differently. Or there are locally modified and pristine sources separated. I don't know. What exactly you have in mind here, @TeslaRus?

[TeslaRus]

"extern" directory = build in third-party, that compile with OT sources
"thirdparty" directory = other external libraries that must be compiled separately or developer uses his preinstalled libraries
no binaries in the thirdparty, repo (except the minimal resources); link to the separated source with binaries may be.

[RICCIARDI-Adrien]

I think the result would be the same than my previous pull request, only some binaries would be removed.

[vvs-]

Why? It shouldn't, because there shouldn't be any significant changes to already existing extern and everything else should go into separate, platform specific run-time dependency thirdparty. Though, I don't know how difficult will be implementing cmake support for it, but we actually already had a working prototype for native Mac OS and MinGW at some point. The main difficulty was unification of the build environment for different developers.

[RICCIARDI-Adrien]

Ok. Let me resume to be sure.

I can start by adding TeslaRus-modified OpenAL to extern with my CMakeLists.txt to build it.
In thirdparty, which is a dedicated git repository homed at github.com/opentomb, I can add the source code for the other dependencies than openal, lua, bullet and freetype2, but I don't add any binary. I will add the thirdparty source codes as I did in my pull request, i.e. the stock one, because it is easier to maintain than hand-crafted one even if there are more files.
I plan to add these source codes in thirdparty :

• zlib
• libpng
• sdl2
• I will probably need to add some more sdl2 dependencies.

CI and non-Linux developers will download thirdparty repository, place it in OpenTomb directory, and build all thirdparty stuff when building OpenTomb.

Is everything correct ?

[vvs-]

I was sure that we already had OpenAL in extern and turned out that I was right all along. After searching history I found that it was removed back in 29c0b06.

[RICCIARDI-Adrien]

OK.
Any though on my previous comment ?

@TeslaRus, are you OK for creating the thirdparty repository (replace the name by a better one if you wish) ? Or if you prefer we can think more about this architecture ?

[TeslaRus]

thirdparty: first time it may be folder near "extern" with text files with links to the required libraries with compatible versions

[TeslaRus]

added al to extern
please, update cmake to use internal al

[RICCIARDI-Adrien]

please, update cmake to use internal al

Ok, I'll create a pull request as soon as this work is ready.

thirdparty: first time it may be folder near "extern" with text files with links to the required libraries with compatible versions

Doing this way would be useless and would not help CI at all.

We can totally avoid thirdparty directory or repository if you prefer. We can instead download and build (if required) all needed dependencies using only CMakeLists.txt. Of course, dependencies are downloaded and built only once and they are stored in build directory, so next build won't download nor build dependencies again. With this method, CI would be possible, Windows build would be greatly improved, and your mingw-based build won't be affected. Moreover, future macOS CI and normal dev build would also be possible.

[vvs-]

We can instead download and build (if required) all needed dependencies using only CMakeLists.txt.

This is the job of a decent package manager, e.g. Nix, NuGet, npm, Stack, OPAM, Maven, CPAN, Cargo etc. What can be worse than reinventing the wheel all the time? Such approach creates endless headache for all involved developers. I don't think that anyone else in the future will be eager to learn, use and maintain any custom package management system instead of working on OpenTomb itself. That's why halfhearted approaches never lead to finished projects.

[RICCIARDI-Adrien]

Sure, and I would like to use one, but I don't know one that works on both Windows and Linux and that can provide the binaries we want. @vvs-, do you know one that could fit our needs ?
We currently need zlib, sdl2 and libpng.

[TeslaRus]

zlib / libpng are built-in compatible (may be passed to the extern folder), do not know about SDL2.
SDL2 is core wrapper library and it must be built properly under target system.

[vvs-]

Nix has all the libraries. It also supports MacOS but I never used it there, though. You might consider WSL or MSYS2 for builds on Windows. I don't think that you can have a cross-platform package manager at this time, but using CMake won't make it any better either. And you are not restricted to use official repositories, because you can have you own packages. A nice property is that it's all source code based, so if there is no binaries in cache it will rebuild it from sources fetching all the dependencies.

[Calinou]

What about using vcpkg?

[vvs-]

Do you mean on Windows only or on all platforms? If the latter then it'd be good to know what are the advantages? How well it's supported on other platforms and architectures? Does it support dynamic linking and how then it should be deployed on different platforms? How it might treat programming languages other than C/C++ if required by the build system?

I've never heard of it before and I suspect this is also true for many others as well. FWIW it doesn't looks mature to me: short list of available packages, seems like only x64 is supported on Linux, doesn't seem to offer an official binary cache. Besides, OpenTomb doesn't even actually support VisualStudio, so I don't see any point in using vcpkg even on Windows. But if you have other considerations, please tell us.

The best way of course would be to see it in action.