Still Alive
Closed this issue · 21 comments
@westonCoder
@hackgrid
@Jgoodwin64
@rxhfcy
@VanGorkum
@chatrat12
@optixx
I am tagging you all here since you are contributors to Portal 64. Now that James has officially decided to stop working on the game (https://www.youtube.com/watch?v=AdBzok8GjA0), I have decided to continue development in this fork with 2 goals:
- Remove proprietary code requirement (see N64 Libraries)
- Finish development of the game (see Development Progress)
Importantly, I will not distributing any form of ROM (patches or otherwise) while the requirement on Nintendo code exists. This way, development on libdragon support as well as game content can continue in tandem - incrementally and at a steady pace.
I'm reaching out in case any of you would like to contribute. Having a centralized place to focus community efforts will help avoid fragmentation of contributions. The more community members involved, the greater this project will be.
I have a Discord server if you want to contact me. It's on my website https://home.venith.net I'm not a game developer but I might know some people who can help.
I planned to do this as well, after James released his statement.
But I want to do this under another name, and without any Valve IP in the repo, so Valve can not have any say in this matter.
Of course it still uses libultra then, but portal64 did not really include any libultra code in the repo, so Nintendo first would have to go after ModernSDK.
Also I think a libdragon port would be really hard, because libdragon still lacks the needed functionality and performance for this game. I think James could have extended libdragon for his needs, as he mentioned in the video, but I for sure can't, because I don't have any real experience coding for the N64 :-)
That's good I'm not the only one thinking this way. I think we will have the most success if we coordinate in one repo. This is my attempt at that.
As for Valve IP, the assets already must be provided at build time, and so we would not be redistributing them. Although I agree that we should search for anything else that may have been checked in and remove it. I'm not sure if a rename is necessary, since other similar projects don't go that far (they just don't distribute official assets).
Usage of libultra to build isn't relevant to whether this repo can stay up - just to the distribution of ROMs or patches. See the N64 Libraries document I created and linked above. I think that we should support both to make the transition easier and give flexibility.
Libdragon has matured significantly in the past few years. It's possible that it may lack necessary features, but those can be added, and we can always fall back to libultra until then (again, making sure to not distribute ROMs or patches). Imo, the lowest risk way to go here is refactoring to make the game code library-independent rather than a hard switch. Then we won't be stuck in the worst case.
And all of this can happen while adding more content to the game itself. One doesn't need to be done before the other. Completing the game is equally as important to me.
I will probably opt-out of this one. James was the one who wrote the majority (70k+ lines of code) and he knew all the code intimately and could add new functionality and levels relatively easily because of his deep understanding of the code base.
Although I did contribute quite a bit, all of my contributions were mostly either bug fixes of existing functionality or making new functionality by mirroring existing code. I also had very little experience with the blender piece so the making of new levels would be a lot to take on.
Thanks for putting this together anyways, I think it's awesome the community wants to make sure the project stays "still alive" 😀
With Valve IP in the repo I meant anything with "portal" on it or purely mentioning it.
The libdragon guys themselves said it is not ready yet for a game like this.
It is a shame though, that James did not document the creating of levels yet.
But since that project figured that out, it should be quite doable :-)
No problem @westonCoder, and thanks anyway!
There will definitely be a lot of learning to do (science to be done?), but I'm looking forward to it. I'll document what I find for others.
@hackgrid I don't anticipate merely mentioning "Portal" to be an issue, and I have put a disclaimer in the readme that this isn't affiliated with Valve. Worst case, it can be renamed.
As for libdragon, I did some looking into it and no red flags jumped out to me (full OpenGL port). But I could very well be wrong. It might not work out, but I want to try it and find out if and where things break. This project could help libdragon to improve, and even contribute back.
If, at the end of the day, it's just not going to happen with libdragon, focus will shift 100% to just finishing the game. But I'm doubtful it will come to that.
Thanks for the repo link! That's very cool. The other day I took a cursory look at James' level files and don't think it will be too bad. The triple laser project is certainly motivating and will be a good resource.
"Portal" is a trademark and "Portal64" could be confused with an official Valve product - that is at least the legal understanding in my world, ymmd of course :-)
I don't have much time atm, but I will follow your progress closely! :-)
To try to avoid such confusion, I removed the logo from the readme and added a disclaimer, but will go further to distance the project from an official one if necessary.
Looking forward to what we all can do!
@westonCoder @hackgrid @Jgoodwin64 @rxhfcy @VanGorkum @chatrat12 @optixx
I am tagging you all here since you are contributors to Portal 64. Now that James has officially decided to stop working on the game (https://www.youtube.com/watch?v=AdBzok8GjA0), I have decided to continue development in this fork with 2 goals:
- Remove proprietary code requirement (see N64 Libraries)
- Finish development of the game (see Development Progress)
Importantly, I will not distributing any form of ROM (patches or otherwise) while the requirement on Nintendo code exists. This way, development on libdragon support as well as game content can continue in tandem - incrementally and at a steady pace.
I'm reaching out in case any of you would like to contribute. Having a centralized place to focus community efforts will help avoid fragmentation of contributions. The more community members involved, the greater this project will be.
@carsongoodwin32
Looks like we wouldn't be alone.
@westonCoder @hackgrid @Jgoodwin64 @rxhfcy @VanGorkum @chatrat12 @optixx
I am tagging you all here since you are contributors to Portal 64. Now that James has officially decided to stop working on the game (https://www.youtube.com/watch?v=AdBzok8GjA0), I have decided to continue development in this fork with 2 goals:
- Remove proprietary code requirement (see N64 Libraries)
- Finish development of the game (see Development Progress)
Importantly, I will not distributing any form of ROM (patches or otherwise) while the requirement on Nintendo code exists. This way, development on libdragon support as well as game content can continue in tandem - incrementally and at a steady pace.
I'm reaching out in case any of you would like to contribute. Having a centralized place to focus community efforts will help avoid fragmentation of contributions. The more community members involved, the greater this project will be.
I think we should work on adding comments to the code, we could also make some developer docs too.
I think we could add p64 to fast64's level exporter too.
Also like hackgrid said it is sad he didn't get around to documenting the process of lv making. Maybe one of us could get in contact with him so we could write up some docs. We could also ask @Krzyhau for help documenting the process.
@Jgoodwin64 documentation is definitely something we should do. It will help more people contribute. I already reached out to James about the level creation process a few days ago. He said he wasn't sure if he wanted to put the time into creating that documentation given the amount of work it would be. But he said he'd consider it, so we should respect that and not bother him.
Even if we don't get documentation from James, I'm sure we can figure it out. You're right that @Krzyhau might have information to share. I can also look deeper tomorrow or Monday.
Also note that fast64 outputs Fast3D display lists, which are specific to Nintendo's microcode. I'm not sure if libdragon supports that. It's probably best to stick with the custom tools in this repo to have more control.
Update: I have started reversing how levels work and documenting it under ./documentation/levels.
just a heads up, you'll need to purge any potentially infringing logos/trademarks from the repo (i.e. rewrite/rebase the repo), committing a delete is not sufficient
@daevangelion good call. I'll do a more thorough look when I have some more time so I only need to rewrite the history once.
I think this code is now broke because I now get a 404.
echo "deb [trusted=yes] https://lambertjamesd.github.io/apt/ ./" | sudo tee /etc/apt/sources.list.d/lambertjamesd.list
That sucks! :-(
This repo contained:
Package: sfz2n64
Version: 1.0
Architecture: amd64
Maintainer: James Lambert lambertjamesd@gmail.com
Filename: ./sfz2n64-1.0.deb
Size: 1406092
MD5sum: a0362b54a6395a1a43754c338119bc23
SHA1: 4d59a59d2632f1250c45e4b24c2e5b3eb29cb04f
SHA256: 6fe14b60a91b63aac57cddd2179372b2cc0d0842ab1ec82c0721b6430461e973
Description: sfz2n64
Converts SFZ files to a format the N64 can use as part of instrument banksPackage: skeletool64
Version: 0.3
Architecture: amd64
Maintainer: James Lambert lambertjamesd@gmail.com
Depends: libassimp5
Filename: ./skeletool.deb
Size: 4247032
MD5sum: 989b203b7de452e685ac0e14a6d3ddeb
SHA1: 92a38a46722b81639c9829ad679188c63bb54ebe
SHA256: ad380f5de5212b5f7952236112d73b4999acbf2f3f98aa686480faa6cb9db8af
Description: skeletool64
Converts various 3d formats to a N64 display listPackage: vtf2png
Version: 1.0
Architecture: amd64
Maintainer: Harry Jeffery harry@exec64.co.uk
Filename: ./vtf2png.deb
Size: 16496
MD5sum: 1815b48055356e26a986b19b77b8af87
SHA1: 484ba819032dcd59b4d07d61850dc2cfd7b8cee2
SHA256: 50e3d667c12370a94226c514d7263f9123c91d09340f858888dc8e6c51475f49
Description: vtf2png
vtf2png is a command line tool to extract images from the VTF format used by Valve's Source Engine. It supports a variety of pixel data formats, including most of the RGBA variations and DXT compression formats.
The skelatool package is not needed, since portal64 brings its own.
I hope the "sfz2n64" was just vanilla from there:
https://github.com/lambertjamesd/sfz2n64
Also I hope the vtf2png was from there
https://github.com/eXeC64/vtf2png
But that repo is quite old...
I can confirm that the linked versions of sfz2n64 and vtf2png work with this project. I used those to build on my Windows machine.
But James' apt repo is still up and working fine. You get a 404 in a browser since there is no index.html or similar. For example, the package metadata is here https://lambertjamesd.github.io/apt/Packages.gz.
I'm going to close this issue to avoid noise for others. Its main purpose was awareness, and I think that's been achieved.
Let's track individual items in their own issues and PRs.
@daevangelion an update on what you mentioned:
I have decided not to rewrite the history. Doing so would create problems for anybody who has forked, and also result in this repository no longer accurately preserving James' work. Not to mention build failures in previous commits, difficult bisects, etc.
My understanding is that the main trademark issue we need to mitigate is confusion over whether this is an official project made by or endorsed by Valve/Nintendo. I believe removal of the logo from the readme and the addition of the disclaimer are sufficient here.
Similarly, the images I have removed are few in number (9), low resolution and modified (cropped/warped; i.e., not a replacement for the original), and are not enough to build the game.
I will take necessary steps (i.e., rewriting history) if all of this is proven to not be enough, but until then I don't want to throw a wrench into things if we don't have to.