OpenTomb
OpenTomb copied to clipboard
opentomb
Is the developer of this still here?
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.
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.
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.
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 ?
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.
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).
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.
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.
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.
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
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 ?
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.
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 :stuck_out_tongue_winking_eye:
Personally, I'm in favor of your proposal to move all external dependencies out of this repository.
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.
The other alternative would be you getting all the required credentials from him and become leading developer with all responsibilities :stuck_out_tongue_winking_eye:
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.
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
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)
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 ?
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.
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.
Great, I will start as soon as possible. Future work might address following issues (listed here to not forget) :
- #115
- #169
- #430
- #540
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.
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...)
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
|
+--...
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.
So we have some dependencies in extern and the other ones in thirdparty ? What is the purpose of this organization ?