aaoth <[email protected]> writes: > I added HOME/.local/share/SRB2 originally to allow user to have their assets > locally, but this is not needed anymore.
yep, I forgot to remove it when bundling the assets and dropping the readme. > And I tried the game and it segfaults for me too, which is weird, bcs > on 7.0-stable it ran fine (as I said in first letter). Maybe there are > issues with recent libraries or something. I'll try to debug this, > thanks! try the attached tarball. I've implement I_GetFreeMem for OpenBSD and with this I'm able to play the first few levels (my free time ended before I could get another segfault ;-) I don't know if this fixes or simply hides the problem (the default implementation returns an arbitrary value of 48mb.) Now, why a game should know how much free memory I have and react differently about that is something I can't explain, but it's the only place where there's some FreeBSD-specific code it's a fair guess. > Regards, > Leo. > > On 6 December 2021 14:44:13 UTC, Omar Polo <[email protected]> wrote: >>Omar Polo <[email protected]> writes: >> >>> la-ninpre <[email protected]> writes: >>> >>>> Hi, >>>> I ported the game Sonic Robo Blast 2 to OpenBSD and also Game >>>> Music >>>> Emu library that is required for music in this game to work. >>>> >>>> It would be nice if someone can test it. I've already run it >>>> successfully on 7.0-current and also another person tried it on >>>> i386 architecture. >>>> >>>> I was unsure about distribution of game assets, so i followed >>>> approach >>>> similar to other game ports: only game binary is distributed and >>>> user >>>> is supposed to download and install game assets by themselves. >>>> >>>> Anyway, all input is welcome! >>>> >>>> Regards, >>>> Leo. >>> >>> Hello, >>> >>> regarding libgme: >>> >>> the ports looks fine. I'd only tweak the order of the variables as per >>> Makefile.template (i.e. DISTNAME at the top, the SHLIBS, CATEGORIES, >>> HOMEPAGE...). SEPARATE_BUILD is already implied by the use of cmake; >>> CONFIGURE_ARGS is usually lay down a bit differently and I can't find >>> them grepping the sources (and cmake warns about unused defines); >>> CMAKE_INSTALL_PREFIX is not needed. The code is (seems) C++11, so let's >>> add a comment about that before the COMPILER line and drop base-gcc from >>> the list. I'd add a NO_TEST=Yes since there aren't any tests. >>> >>> Otherwise builds fine on amd64. >>> >>> I'd drop the "Use CMake to build" from pkg/DESCR, as I don't think the >>> build system used is an important info for DESCR. >>> >>> >>> regarding srb2: >>> >>> ports looks fine too, but most of the previous point applies here as >>> well. In addition, DISTNAME is not needed when using GH_TAGNAME (it's >>> only when you need to use GH_COMMIT otherwise the tarball ends up with a >>> weird name.) CMAKE_BUILD_TYPE is already taken care of by modcmake, as >>> well as CMAKE_INSTALL_PREFIX. I'd explicitly disable ccache for cmake, >>> that's already taken care by the port infrastructure. The port is a C >>> one and since COMPILER is the default I guess we can drop it. We can >>> always revisit this if it fails the builds on gcc arches. >>> >>> We usually don't hardcode /usr/local, so in patch-src_sdl_i_system_c I >>> went with ${PREFIX} + SUBST_CMD in pre-configure. We also need to tweak >>> PATCHORIG otherwise `make update-patches' picks up stuff that isn't ours. >>> >>> Regarding the assets: IANAL but I see that other distributions packages >>> those too (either in the srb2 package or in a -data subpackage.) There >>> is a file with the thirdy parties licenses[0] and it list all "OKish" >>> licenses. With the assets the package weight a bit more, it's around >>> 180M, maybe we could split it. (and dropped the README at this point) >>> >>> Attaching the updated tarballs as per previous notes. I've only opened >>> the menu (no time to play today :/) but it's OK op@ to import if someone >>> does some testing. I'll do some proper testing in the following days ;) >> >>I was probably a little too optimistic ;-) >> >>la-ninpre noted off-list that now that we're fetching the assets there's >>no need to list the hashes in assets/CMakeList.txt and that we can avoid >>rm(1)'ing files in post-extract by tweaking the EXTRACT_CASES: we're >>only interested in the .pk3 and .dta files, it should save a bit of >>space during builds I guess. >> >>I forgot to sort WANTLIB in previous submission and when tweaking >>patch-src_sdl_i_system_c I haven't noticed that it was adding >>HOME/.local/share/SRB2: upstream doesn't do that and I don't see any >>reason to add an extra search path. >> >>I tried to play the game but it always segfaults, either in the first >>level or in the tutorial, after a couple of seconds. It doesn't leave >>any core files around (it seems to trap SIGSEGV) and it quits with a >>'got signal 5' (which is SIGTRAP) when started from egdb. FWIW, I'm >>running on amdgpu. >> >>Probably not too hard to debug, but I don't have time for that atm. >>Attaching an updated tarball with the above point addressed and >>DEBUG_PACKAGES set, should aid the debugging. >>
srb2.tar.gz
Description: Binary data
