Aquaria was open sourced just after the game was added to Portage. I have created a new ebuild for the game and a separate ebuild for the BBGE engine it uses. I was going to wait until Ryan Gordon had committed my TinyXML patch upstream but I'm getting restless and I know people are keen to try this out. I'm just going to upload live ebuilds for now until the patch is committed. I think it's always useful to have a live ebuild archived in Bugzilla anyway. Note that I've only tested this on amd64, not x86, so testing would be appreciated. The game has only just been fixed for 64-bit so be on the lookout for any glitches there too.
Created attachment 234893 [details] bbge-9999.ebuild Live ebuild for games-engines/bbge. Requires following patch.
Created attachment 234895 [details, diff] gentoo-data-path.patch Patch against BBGE that allows us to put the data files in /usr/share/games/<appName> without having to change to that directory.
Created attachment 234897 [details] aquaria-9999.ebuild Live ebuild for games-arcade/aquaria. Requires the following patch.
Created attachment 234899 [details, diff] tinyxml-2.6.patch Patch that let's Aquaria build against the latest TinyXML.
Nice work, it's running fine for me on amd64 as well. Just to note, KEYWORDS should generally be empty for live ebuilds.
Created attachment 235427 [details] aquaria-9999.ebuild My patch was applied so here's a new live ebuild. I'd put a versioned one up but there are no official tarballs available and I'm currently locked out of my gentooexperimental.org account, which is where I'd like to host it. I'll try to gain access again.
Created attachment 235443 [details, diff] gentoo-data-path.patch The patch needed updating.
Hi, I was looking to make an ebuild myself for Aquaria, and then I noticed your message to the aquaria ML, and found this bug. Although these are live ebuilds, and thus probably not good candidates for inclusion into the portage tree, if you would like a place to maintain and host these ebuilds in an overlay, I would like to invite you to consider doing so in gamerlay (available globally in layman). You can come talk with us in #gentoo-gamerlay on chat.freenode.net
That's okay, Locke. I don't think there will be any tarball releases but I have access to my gentooexperimental.org account again so I can host my own. The data path patch hasn't been applied upstream (there's a backlog) but Ryan told me that it will be eventually. I could therefore put up a tarball now but there is talk on the mailing list of dramatically reducing the amount of RAM usage in the game, which I think is worth waiting for. It currently uses far more than you'd expect.
(In reply to comment #9) Alright then, if you don't mind, I'd like to toy around with the ebuild, and commit it to gamerlay as -9999 versions. I'll keep subscribed to the bug, and any new developments with the ebuild. Is that alright with you?
Yep, that's cool, thanks.
It seems that development has stalled in the git repository. Correct me if I am wrong, but presumably, there are some advantages of using the git repository instead of the precompiled binary? Perhaps the current git version could be snapshotted and added to the tree?
We should always build from source where possible and certainly in this case because it means native 64-bit support. Despite his best intentions, Ryan seems to have fallen way behind with the patches. I've already poked him once and don't want to do so again because I know he's a busy guy. He may actually be waiting for Andrew Church to finish his own improvements. His repository at http://achurch.org/cgi-bin/hg/aquaria is still seeing active development (15 minutes ago!). His focus is on a PSP port but he also seems to maintain a separate "generic" branch. Like Ryan, I've been waiting for this to settle down before taking a look at it. I did intend to just apply my patch to the latest from Ryan's branch for the time being but the DNS for gentooexperimental.org has been out of action all this time so I didn't bother.
Thanks for the pointer to the other repository, I did not know about it before. I am really exited about all the changes to the game :)
Can you please update the ebuild in gamerlay to fetch from http://achurch.org/cgi-bin/hg/aquaria/ instead of the icculus repository, which seems no longer under development?
I'm not sure whether the game is reliably kept in a working state there. Andrew Church has clearly been making a huge number of changes. I'm amazed that he has been working so hard on it all this time. I was thinking about posting the list to ask for a progress report.
We could also get an updated snapshot in the tree so people not running directly from the -9999 version could get an update.
I am totally in favour of a new version of aquaria in the tree :) Now with the new humble indie bundle, it is quite interesting what has come out of the open-sourcing of the games from the last bundle.
I can't access it right now but I did see that Andrew Church was STILL working on it very recently so it's not like nothing is happening. I haven't contacted him because I've been busy with other things myself but I certainly haven't forgotten about it.
It seems like the code changed so that the patch can't be applied anymore. As a result the BBGE ebuild in the gamerlay overlay can't build anymore. :( P.S. Sorry for my bad english. :)
(In reply to comment #20) > It seems like the code changed so that the patch can't be applied anymore. As a > result the BBGE ebuild in the gamerlay overlay can't build anymore. :( That's because a version of the patch has been merged upstream along with a lot of other changes. Also, I think I'll get a new snapshot in the main tree so we can all enjoy the new changes within a week or so; however, I'm not planning to split bbge and aquaria unless someone has a good reason to. It just seems like extra work since currently no other games (at least in the tree) use the engine to my knowledge.
> That's because a version of the patch has been merged upstream along with a lot of other changes. Would it work if I copy the ebuild to my local overlay and delete the patch? > Also, I think I'll get a new snapshot in the main tree so we can all enjoy the new changes within a week or so You mean the ebuild in the normal portage tree? That would be great! But don't forget to remove this: /usr/portage/profiles/features/64bit-native/package.mask: # AMD64 Team <amd64@gentoo.org> # Mask packages that rely on amd64 multilib - games-arcade/aquaria-1.1.3::gentoo (masked by: package.mask, ~amd64 keyword) Sorry if I understood something completely wrong but my english is really bad. :)
(In reply to comment #22) > Would it work if I copy the ebuild to my local overlay and delete the patch? Yes, you should remove the patch lines from src_prepare and add a line like the following to src_configure: append-cppflags -DBBGE_DATA_PREFIX=/usr/share/games > You mean the ebuild in the normal portage tree? That would be great! Yep, that's what main tree means. :)
Thanks for all the hints, but: > append-cppflags -DBBGE_DATA_PREFIX=/usr/share/games I removed the patch line, modified the "Remove bundled stuff to ensure it's not used." line and added this one (also tried combinations like: -DBBGE_DATA_PREFIX='/usr/share/games') but it won't work: [ 55%] Building CXX object CMakeFiles/BBGE.dir/BBGE/Particles.cpp.o /var/tmp/portage/games-engines/bbge-9999/work/aquaria/BBGE/Core.cpp: In Elementfunktion »void Core::initPlatform(const std::string&)«: /var/tmp/portage/games-engines/bbge-9999/work/aquaria/BBGE/Core.cpp:1014:12: Fehler: expected primary-expression before »/« token /var/tmp/portage/games-engines/bbge-9999/work/aquaria/BBGE/Core.cpp:1014:12: Fehler: »usr« wurde in diesem Gültigkeitsbereich nicht definiert /var/tmp/portage/games-engines/bbge-9999/work/aquaria/BBGE/Core.cpp:1014:12: Fehler: »share« wurde in diesem Gültigkeitsbereich nicht definiert /var/tmp/portage/games-engines/bbge-9999/work/aquaria/BBGE/Core.cpp:1014:12: Fehler: »games« wurde in diesem Gültigkeitsbereich nicht definiert make[2]: *** [CMakeFiles/BBGE.dir/BBGE/Core.cpp.o] Fehler 1 make[2]: *** Warte auf noch nicht beendete Prozesse... make[1]: *** [CMakeFiles/BBGE.dir/all] Fehler 2 make: *** [all] Fehler 2 emake failed So I think BBGE_DATA_PREFIX doesn't work as it should or I don't realize how to use it (correctly). Maybe I should just wait untill you update the ebuild in the main tree.
I tried a bit more and this line does the trick: append-cppflags -DBBGE_DATA_PREFIX=\\\\\\\"/usr/share/games\\\\\\\" but I still think there's something wrong with DBBGE_DATA_PREFIX ;) And now it won't link: Linking CXX shared library libBBGE.so CMakeFiles/BBGE.dir/BBGE/SkeletalSprite.cpp.o: In function `SkeletalSprite::saveSkeletal(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': SkeletalSprite.cpp:(.text+0x252c): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' SkeletalSprite.cpp:(.text+0x25e3): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' SkeletalSprite.cpp:(.text+0x282f): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' SkeletalSprite.cpp:(.text+0x2a40): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' SkeletalSprite.cpp:(.text+0x2ab9): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/BBGE.dir/BBGE/SkeletalSprite.cpp.o:SkeletalSprite.cpp:(.text+0x2d3b): more undefined references to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' follow collect2: ld gab 1 als Ende-Status zurück make[2]: *** [libBBGE.so] Fehler 1 make[1]: *** [CMakeFiles/BBGE.dir/all] Fehler 2 make: *** [all] Fehler 2 emake failed So I think I will wait, that's going to be to much work for me. ;)
(In reply to comment #25) > So I think I will wait, that's going to be to much work for me. ;) Or you could just remove the append-ldflags line to make it link properly.
Okay, I could install BBGE without (visible) errors now. :) But not aquaria won't link. It shows similar errors to the one BBGE had before: Linking CXX executable aquaria CMakeFiles/aquaria.dir/Aquaria/Continuity.cpp.o: In function `Continuity::saveFile(int, Vector, unsigned char*, int, int)': Continuity.cpp:(.text+0x77fb): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' Continuity.cpp:(.text+0x7900): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' Continuity.cpp:(.text+0x7b51): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' Continuity.cpp:(.text+0x7cfe): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' Continuity.cpp:(.text+0x7de9): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' CMakeFiles/aquaria.dir/Aquaria/Continuity.cpp.o:Continuity.cpp:(.text+0x7fd6): more undefined references to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' follow CMakeFiles/aquaria.dir/Aquaria/UserSettings.cpp.o: In function `readInt(TiXmlElement*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int*)': UserSettings.cpp:(.text+0x25): undefined reference to `TiXmlElement::Attribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const' CMakeFiles/aquaria.dir/Aquaria/UserSettings.cpp.o: In function `readIntAtt(TiXmlElement*, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int*)': UserSettings.cpp:(.text+0x56): undefined reference to `TiXmlElement::Attribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const' CMakeFiles/aquaria.dir/Aquaria/UserSettings.cpp.o: In function `UserSettings::save()': UserSettings.cpp:(.text+0x2b53): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' UserSettings.cpp:(.text+0x2ed7): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' UserSettings.cpp:(.text+0x33f6): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' UserSettings.cpp:(.text+0x344d): undefined reference to `TiXmlElement::SetAttribute(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' collect2: ld gab 1 als Ende-Status zurück make[2]: *** [aquaria] Fehler 1 make[1]: *** [CMakeFiles/aquaria.dir/all] Fehler 2 make: *** [all] Fehler 2 emake failed I can't find a append-ldflags line in this ebuild. :(
(In reply to comment #27) > But not aquaria won't link. It shows similar errors to the one BBGE had before: > I can't find a append-ldflags line in this ebuild. :( You'll have to recompile dev-libs/tinyxml with the stl USE flag enabled to fix this linking error.
Thank you Tim, you are my hero of the day! :) If anybody needs the modified ebuilds: Simply ask. I won't attach them now because I don't think they are needed.
This can't be true. Now the game starts but I can't do anything (New game, continue and exit aren't clickable). But I think this is not a gentoo related issue. It's just... frustrating... :(
Created attachment 271309 [details] bbge-9999.ebuild Slow down, guys! I already know about the upstream changes and I've made the necessary changes but I was waiting for things to settle down again as patches are still coming in. I'd like to keep the ebuilds separate. It's not often that a commercial game engine that is so well-separated from its game gets open sourced. I don't want to take that for granted! Who knows, maybe someone will do something with it. :) I'm about to apply to become a Gentoo developer and games is one of the areas I'm particularly interested in. I'll be applying to the Java herd initially but I'd be happy to be to maintain this if you like. I've also applied the tinyxml stl USE flag change.
Created attachment 271311 [details] aquaria-9999.ebuild Oh and this ebuild fixes the non-clickable issue you're seeing. It's to do with the Lua scripts. Also, if you experience any graphical corruption using the open Radeon drivers, try using the gallium driver.
(In reply to comment #31) > I'd like to keep the ebuilds separate. It's not often that a commercial game > engine that is so well-separated from its game gets open sourced. I don't want > to take that for granted! Who knows, maybe someone will do something with it. I suppose that's as good of a reason as any. > I'm about to apply to become a Gentoo developer and games is one of the > areas I'm particularly interested in. I'll be applying to the Java herd > initially but I'd be happy to be to maintain this if you like. Just to note, going through the dev process usually takes a lot of time (months) mainly because the process is backed up and there are few recruiters. Therefore, I'll probably get to updating this stuff in the tree before you become a dev, but you can help maintain stuff afterwards of course. :) You can also help proxy-maintain it now which would be great too.
(In reply to comment #32) > Oh and this ebuild fixes the non-clickable issue you're seeing. No, it don't. :( Do you have a link for a upstream bug or something other pointing me into thr right direction? (In reply to comment #32) > Oh and this ebuild fixes the non-clickable issue you're seeing. (In reply to comment #31) > I'm about to apply to become a Gentoo developer and games is one of the > areas I'm particularly interested in. I have read some things from you in the past (in this bugzilla and in forums) and I think it would be great to have such a engaged man working as a gentoo dev. Good luck! :)
(In reply to comment #33) > Just to note, going through the dev process usually takes a lot of time > (months) mainly because the process is backed up and there are few recruiters. > Therefore, I'll probably get to updating this stuff in the tree before you > become a dev, but you can help maintain stuff afterwards of course. :) I realise it can take at least a month. I'm hoping that the fact I've made fairly regular contributions for years through commit access to java-overlay will speed things up a bit. > You can also help proxy-maintain it now which would be great too. That's fine by me. (In reply to comment #34) > Do you have a link for a upstream bug or something other pointing me into the > right direction? Are you absolutely sure you used the new ebuild? It certainly fixed the issue for me and a guy on the mailing list said using the new scripts worked for him too. Here's the thread. http://icculus.org/pipermail/aquaria/2011-April/000354.html > I have read some things from you in the past (in this bugzilla and in forums) > and I think it would be great to have such a engaged man working as a gentoo > dev. Good luck! :) Thanks!
(In reply to comment #35) > Are you absolutely sure you used the new ebuild? Shame on me, I had forgotten to save. Sorry about that, everything is working fine now.
Created attachment 271335 [details] bbge-9999.ebuild :) Just replacing the static USE flag with static-libs, which is more appropriate.
bbge should depend on tinyxml[stl] the same as aquaria, else it will fail to build :)
Created attachment 271963 [details] bbge-9999.ebuild Should have spotted that. Thanks.
And just for the record, folks, fixed ebuilds are now in gamerlay again
Any news on this?
A little. Ryan published a port to SDL2 back in July and an interesting discussion about the overall state of play followed. http://icculus.org/pipermail/aquaria/2013-July/thread.html It was seemingly agreed that this should be considered the most authoritative repository going forward since it sees most of the action. The last commit was just 2 months ago. https://github.com/fgenesis/Aquaria A revised ebuild would be great but I'm a little tied up in other parts of Gentoo land just now.
Just a heads up in case someone else decides to take a look at this. I'm currently working heavily on it and a lot has changed. I have created an ebuild for ttvfs, which is now recommended, plus some modifications have been made to the bundled libraries so I'm going try and get these pushed upstream.
