Closed Lantern47 closed 5 days ago
Hi, your sdl2 version is too old. Please install at least 2.26.1
or higher
Hi, your sdl2 version is too old. Please install at least 2.26.1 or higher
Thanks, I'll try upgrading my SDL, though in re-reading that error log, I don't think it mentioned my SDL version. I'm curious how you could tell it was too old ?
My installed version is currently: 2.0.20
From past experience seeing this error message about SDL_CONTROLLER_TYPE_
.
Our ImGui dependency has support for switch controllers and so it is expecting those enums to exist, which came in a later SDL2 version (I can't find right now "which" version introduced them, but I can confirm that our linux CI scripts manually install SDL2 2.26.1
because the version in apt-get is too old)
Thanks. I appreciate the explanation, and in such little time. I'm upgrading my packages as I write this and I'll try again. Though while you're here, does moving the .z64 ROM into the OTRExporter need to be done at any specific point in the chain of commands necessary / does it require any specific naming conventions for the ROM, to be recognised before compilation ?
If you mean regarding using the ExtractAssets
cmake target, it strictly only works with the US N64 rom in big endian format (can be named anything).
My recommendation however would be to not use the ExtractAssets
step, and instead just do GenerateSohOtr
. Then you can launch the program as-is and you'll be prompted to supply a rom which supports both N64 and GC US in any format. This utilizes OTR generation that is built into the main executable.
The building docs are a bit unclear of this path, and I'll probably update them soon to switch to this recommendation.
Thanks. Though I'm curious, could you expand a little more on what the disadvantages are of using the ExtractAssets step ? Or link me to where I could read more about the two options ? The docs seem to recommend that one run cmake --build build-cmake --target Generate2ShipOtr
before running
cmake --build build-cmake --config Release
but that seems to be about it. The mention of ExtractAssets
and GenerateSoh0tr
are new to me.
Sorry, I was looking at the wrong repo. I meant Generate2ShipOtr
. But looks like the linux part of the building instructions is correct, it's just windows/macOS that are still referencing old things.
Anyways, you are not required to move any rom files into OTRExporter
. Simply run the 2ship and you'll be prompted to generate the otr if it is missing.
The reason there is two ways to generate otrs is mainly historical/legacy (coming from SoH). The cmake target was first, then later in the project life we made a built-in extractor. The both use the same tools under the hood (ZAPDTR and OTRExporter) meaning the resulting otr/o2r file is identical, the difference is that the cmake step uses python scripts to generate the otr via cli, vs the built-in one happening in c++ via the game executable.
The python scripts have simple rom validation that only accounts for big-endian and only works correctly with US N64. The built-in process has slightly more robust rom validation supporting both US N64 and US GC correctly
I was unable to find the Generate2ShipOtr
program like you suggested. For some reason, running the find
command within the source and build directories came up with nothing.
I tried running the extract_assets.py
script but it kept throwing the following errors:
Traceback (most recent call last): File "/home/user/2ship2harkinian/OTRExporter/./extract_assets.py", line 85, in
main() File "/home/user/2ship2harkinian/OTRExporter/./extract_assets.py", line 81, in main BuildOTR(os.path.join(args.xml_root, rom.version.xml_ver), rom.file_path, zapd_exe=args.zapd_exe, genHeaders=args.gen_headers, File "/usr/lib/python3.9/posixpath.py", line 76, in join a = os.fspath(a) TypeError: expected str, bytes or os.PathLike object, not NoneType
I'm not sure why that didn't work, given that the hash matches the sha1 hash for approved ROMS. It's the USA version, Big Endian.
I tried copying the ROM into the directory of build_cmake/mm/ and running 2s2h.elf
like you suggested, and it began the extraction process there, seemingly recognising it as a compatible ROM, but then it ran in to some problems.
2s2h.elf
[2024-10-03 00:04:59.612] [/home/user/2ship2harkinian/libultraship/src/resource/archive/ArchiveManager.cpp:152] [info] Reading archive: /home/user/2ship2harkinian/build-cmake/mm/./mm.o2r [2024-10-03 00:05:00.114] [/home/user/2ship2harkinian/libultraship/src/resource/archive/ArchiveManager.cpp:182] [info] Adding Archive /home/user/2ship2harkinian/build-cmake/mm/./mm.o2r to Archive Manager [2024-10-03 00:05:00.183] [/home/user/2ship2harkinian/libultraship/src/resource/archive/ArchiveManager.cpp:152] [info] Reading archive: /home/user/2ship2harkinian/build-cmake/mm/2ship.o2r [2024-10-03 00:05:00.185] [/home/user/2ship2harkinian/libultraship/src/resource/archive/ArchiveManager.cpp:182] [info] Adding Archive /home/user/2ship2harkinian/build-cmake/mm/2ship.o2r to Archive Manager [00:05:00.700] [os.cpp:27] [error] Failed add SDL game controller mappings from "./gamecontrollerdb.txt" (Invalid RWops) [00:05:04.110] [CrashHandler.cpp:72] [critical] Signal: 11 INVALID ACCESS TO STORAGE Registers: EDI: 0x0AD73F70 ESI: 0x0AD73F8C EBP: 0xBFC5F448 ESP: 0xBFC5F390 EBX: 0x0BE47F4C EDX: 0xBFC5F388 ECX: 0x0BE477CC EAX: 0x00000000 EIP: 0x089FA178 EFL: 0x00210202 Traceback: 1 kernel_rt_sigreturn (+0x0) 2 ImGui_ImplOpenGL3_NewFrame() (+0x18) 3 Ship::Gui::DrawMenu() (+0x15) 4 gfx_run(Gfx, std::unordered_map<MtxS, MtxF, std::hash<MtxS>, std::equal_to<MtxS>, std::allocator<std::pair<MtxS* const, MtxF> > > const&) (+0x4A) 5 Graph_ProcessGfxCommands (+0x31F) 6 ./2s2h.elf() [0x83bd5d1] 7 Graph_Update (+0x43) 8 RunFrame (+0x1D5) 9 Graph_ThreadEntry (+0xD) 10 main (+0xEA) 11 libc_start_main (+0xF9) 12 _start (+0x21) t� ��
Failed to initialize OpenGL loader!
Users in the Discord server have notified me that the crash is due to my CPU only supporting up to OpenGL 1.4.
2ship2harkinian requires at least OpenGL 3.0 as a dependency as it is a modern port for modern machines, and as rightly pointed out, an Intel T2400 is around 20 years old. As consequence, there are only 3 solutions unfortunately, as recommended to myself by a user:
As such, I will now mark this issue as closed. Many thanks to xelivous and Malkierian for help with this issue.
Console output:
commands ran:
I've checked and the ROM's hash is compatible with 2ship. Did I enter a command wrong ? I should have all of the relevant dependencies. I'm just trying to compile it for my laptop. Why is it trying to encode Joycon controller compatability by default and failing ?
System Information: