aaoth <aaoth@aaoth.xyz> 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 <op@openbsd.org> wrote:
>>Omar Polo <op@openbsd.org> writes:
>>
>>> la-ninpre <aaoth@aaoth.xyz> 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.
>>
No comments:
Post a Comment