Open humbertodias opened 8 months ago
Issue with r-tech1/dumb
How to reproduce
git clone https://github.com/kazzmir/paintown -b build-psp cd paintown ./easy-compile-docker-psp
Error https://github.com/kazzmir/paintown/actions/runs/7995178382/job/21834909397?pr=93#step:3:10387
[44/352] Compiling C object src/r-tech1/libs/dumb/libdumb.a.p/src_it_itorder.c.o FAILED: src/r-tech1/libs/dumb/libdumb.a.p/src_it_itorder.c.o psp-gcc -Isrc/r-tech1/libs/dumb/libdumb.a.p -Isrc/r-tech1/libs/dumb -I../src/r-tech1/libs/dumb -Isrc -I../src -I../src/r-tech1/libs/dumb/include -I/psp/include -I/pspdev/psp/include -I/pspdev/psp/sdk/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -g3 -Wextra -Wno-unused-variable -Wno-unused-function -Wno-unused-parameter -DPSP -w -MD -MQ src/r-tech1/libs/dumb/libdumb.a.p/src_it_itorder.c.o -MF src/r-tech1/libs/dumb/libdumb.a.p/src_it_itorder.c.o.d -o src/r-tech1/libs/dumb/libdumb.a.p/src_it_itorder.c.o -c ../src/r-tech1/libs/dumb/src/it/itorder.c In file included from ../src/r-tech1/libs/dumb/src/it/itorder.c:22: ../src/r-tech1/libs/dumb/include/dumb.h:139:1: error: static assertion failed: "dumb: off_t must be 64bit" 139 | _Static_assert(sizeof(dumb_off_t) >= 8, "dumb: off_t must be 64bit");
Fixed https://github.com/kazzmir/paintown/pull/93/commits/4fb3f4d942264d3f7c42c72f45fb7d7d4134db50
Just curious, couldn't you use https://hub.docker.com/r/pspdev/pspdev instead of using Ubuntu in the image? It should already have the pspdev environment for you setup.
Just curious, couldn't you use https://hub.docker.com/r/pspdev/pspdev instead of using Ubuntu in the image? It should already have the pspdev environment for you setup.
you're right. it's easier it. replaced https://github.com/kazzmir/paintown/pull/93/commits/78d6a64027ef489ed45e6bc12154d3e705581ea0 thanks
the psp build it's working now. however, it crashes during startup and I don't have any psp here to debug. could you test it?
./easy-compile-docker-psp && ./release/release-psp
a runnable file paintown-psp-$version.pbp will be generated
I have a psp, but I haven't turned it on in ages. My batteries all swelled up and nearly blew up inside it. I can probably run it with the charger. I'll pull it out and see if it still runs tomorrow.
I'm not sure how I can debug with hardware though, but I'm sure it'll be easier to test inside an emulator.
Edit:
./release/release-psp
Error, found no relocation sections
ERROR: Could not read in the file size. (data)
mmm. Here doesn't show up this message. Let me investigate
./release/release-psp
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Error, found no relocation sections
[0] 408 bytes | PARAM.SFO
[1] 95768 bytes | ICON0.PNG
[2] 8346 bytes | ICON1.PNG
[3] 221670 bytes | PIC0.PNG
[4] 221670 bytes | PIC1.PNG
[5] 494280 bytes | SND0.AT3
[6] 4677524 bytes | paintown-psp.elf
[7] 256 bytes | data
.
├── EBOOT.PBP
├── ICON0.PNG
├── ICON1.PNG
├── PARAM.SFO
├── PIC0.PNG
├── PIC1.PNG
├── SND0.AT3
├── data
│ ├── fonts
│ │ ├── LiberationMono-Bold.ttf
│ │ ├── LiberationMono-BoldItalic.ttf
│ │ ├── LiberationMono-Italic.ttf
│ │ ├── LiberationMono-Regular.ttf
│ │ ├── LiberationSans-Bold.ttf
│ │ ├── LiberationSans-BoldItalic.ttf
│ │ ├── LiberationSans-Italic.ttf
│ │ ├── LiberationSans-Regular.ttf
│ │ ├── LiberationSerif-Bold.ttf
│ │ ├── LiberationSerif-BoldItalic.ttf
│ │ ├── LiberationSerif-Italic.ttf
│ │ └── LiberationSerif-Regular.ttf
│ ├── menu
│ │ ├── arcade.txt
│ │ ├── bgs
│ │ │ └── stars
│ │ │ ├── bottom.png
│ │ │ ├── middle.png
│ │ │ └── top.png
│ │ ├── icon.bmp
│ │ ├── in-game.txt
│ │ ├── main.txt
│ │ ├── options.txt
│ │ ├── paintown.png
│ │ └── sounds
│ │ ├── chip-in.wav
│ │ ├── chip-out.wav
│ │ ├── menu-back.wav
│ │ ├── menu-ok.wav
│ │ ├── menu-select.wav
│ │ └── talk.wav
│ ├── mods
│ │ └── default
│ │ └── default.txt
│ ├── music
│ │ ├── Aurora.ogg
│ │ ├── SM_TechTown.it
│ │ ├── Techtopia.ogg
│ │ ├── aqua.s3m
│ │ ├── c_heaven.xm
│ │ ├── elw-sick.xm
│ │ ├── experience.xm
│ │ ├── exploration.s3m
│ │ ├── fall.xm
│ │ ├── kajahtaa.xm
│ │ └── kilimanz.mod
│ ├── shaders
│ │ ├── lit-sprite.fragment.glsl
│ │ ├── mugen-after-effect.fragment.glsl
│ │ ├── mugen-palette-effect.fragment.glsl
│ │ ├── remap.fragment.glsl
│ │ └── shadow.fragment.glsl
│ └── system.txt
└── paintown-psp.elf
11 directories, 53 files
i found something
55:57:970 Core/System.cpp:437 N[BOOT]: PPSSPP v1.17.1
55:57:971 Core/Compatibility.cpp:151 N[G3D]: UnitsPerMeter for HELL01497: 0.000000
55:58:013 root N[G3D]: GLES/ShaderManagerGLES.cpp:1158 Precompile: Compiled and linked 2 programs (2 vertex, 2 fragment) in 0.1 milliseconds
55:58:013 root N[G3D]: GLES/GPU_GLES.cpp:109 Precompiling the shader cache from '/home/lin/.var/app/org.ppsspp.PPSSPP/config/ppsspp/PSP/SYSTEM/CACHE/HELL01497.glshadercache'
55:58:013 root N[BOOT]: UI/EmuScreen.cpp:389 Booted /home/lin/Downloads/hello-world.pbp...
01:22:691 Core/System.cpp:437 N[BOOT]: PPSSPP v1.17.1
01:22:692 Core/Compatibility.cpp:151 N[G3D]: UnitsPerMeter for PAIN02242: 0.000000
01:22:797 ELF/ElfReader.cpp:433 E[LOADER]: Truncated ELF, 48234496 bytes with 41 sections and 2 segments
01:22:797 HLE/sceKernelModule.cpp:1297 E[SCEMODULE]: LoadInto failed with error 800200d9
01:22:798 HLE/sceKernelModule.cpp:1843 E[LOADER]: Failed to load module umd0:/paintown-psp-6c26b9d5.pbp
01:22:807 UI/EmuScreen.cpp:257 E[BOOT]: isIniting bootGame error: Failed to load executable:
allow remote debugger
Success on PPSSPP! Although there are still some minor glitches, the application no longer crashes.
Very cool. Most of the ports are likely going to have issues since we ripped out all the old file handling system SFL which allowed us to read/manipulate files. We replaced it with ghc::filesystem which is a backwards compatible std::filesystem c++11 handler but it so far seems to be unsupported on these other architectures. I ended up just doing Windows specific file operations in lieu of trying to fix it on mingw port.
We will likely need to do something similar otherwise I'm not sure what we should do in the case of these ports.
Very cool. Most of the ports are likely going to have issues since we ripped out all the old file handling system SFL which allowed us to read/manipulate files. We replaced it with ghc::filesystem which is a backwards compatible std::filesystem c++11 handler but it so far seems to be unsupported on these other architectures. I ended up just doing Windows specific file operations in lieu of trying to fix it on mingw port.
We will likely need to do something similar otherwise I'm not sure what we should do in the case of these ports.
Sound to be exactly that. Running PPSSPP on windows we have the emulator console and a bunch of file system exceptions appear
FS on psp
The recent change into master was to remove the necessity to add this line in varying files:
#if !defined(WINDOWS) && !defined(WII) && !defined(MINPSPW) && !defined(PS3) && !defined(NDS) && !defined(NACL) && !defined(XENON) && !defined(UCLIBC)
and replace with:
#ifndef CROSS_BUILD
Could you update your code to reflect that. If there is any specific functionality like file handling or other items that can be pushed into its own file please do so. Look at the examples of src/r-tech1/windows or src/r-tech1/ps3. Just make a new folder for psp and put relevant files in there.
Thanks.
The recent change into master was to remove the necessity to add this line in varying files:
#if !defined(WINDOWS) && !defined(WII) && !defined(MINPSPW) && !defined(PS3) && !defined(NDS) && !defined(NACL) && !defined(XENON) && !defined(UCLIBC)
and replace with:
#ifndef CROSS_BUILD
Could you update your code to reflect that. If there is any specific functionality like file handling or other items that can be pushed into its own file please do so. Look at the examples of src/r-tech1/windows or src/r-tech1/ps3. Just make a new folder for psp and put relevant files in there.
Thanks.
Alright. I have created a scaffold for file-system+system https://github.com/kazzmir/paintown/pull/93/commits/b74e8231d455a8c4aa995b5872ac914b8ca2fcec. Do you know where is the old psp implementation?
The recent change into master was to remove the necessity to add this line in varying files:
#if !defined(WINDOWS) && !defined(WII) && !defined(MINPSPW) && !defined(PS3) && !defined(NDS) && !defined(NACL) && !defined(XENON) && !defined(UCLIBC)
and replace with:
#ifndef CROSS_BUILD
Could you update your code to reflect that. If there is any specific functionality like file handling or other items that can be pushed into its own file please do so. Look at the examples of src/r-tech1/windows or src/r-tech1/ps3. Just make a new folder for psp and put relevant files in there. Thanks.
Alright. I have created a scaffold for file-system+system b74e823. Do you know where is the old psp implementation?
The old implementation was agnostic as it was using SFL. You can use it again if you want and pull those specific library files in. We bombed it in lieu of ghc::filesystem a few weeks back when we merged in the filesystem changes in #67, you should be able to pick up what changed. Preferably it would be nice to modernize if possible. Do what you what you think is best.
I have implemented the file-system layer. But something is still missing. Pointing to
'-DDATA_PATH="ms0:/PSP/GAME/paintown/data"'
and running on retroarch show up
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile(''): FAILED, 21 - access = 1 ''
[libretro ERROR] [CPU] BREAK!
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile(''): FAILED, 21 - access = 26 ''
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data'): FAILED, 2 - access = 1 ''
[libretro ERROR] [CPU] BREAK!
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/system.txt'): FAILED, 2 - access = 1 ''
[libretro ERROR] [CPU] BREAK!
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/system.txt'): FAILED, 2 - access = 1 ''
[libretro ERROR] [CPU] BREAK!
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/paintown/paintown.txt'): FAILED, 2 - access = 1 ''
[libretro ERROR] [CPU] BREAK!
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/paintown/paintown.txt'): FAILED, 2 - access = 1 ''
[libretro ERROR] [CPU] BREAK!
Did it work properly with devkitpro?
Cool, I can test on real hardware but not sure if it'll work. It is really tough to debug on these systems without console output in most cases. As for devkitpro, I got a few tests working. My file-system content is functioning on wii and switch since the fs-test worked. I also got the animation to work on switch emulator but it locked up on wii emulator. I haven't tested on physical wii because mine is in the closet right now. But on my physical switch I can only get the test-fs example to work only half the time. Most times all the apps just crash. I couldn't get the select menu test to work unfortunately, and so no the paintown bins just crash. Might be related to SDL or some memory issue, but I can't tell. I kind of gave up for now, I'll leave it to be fixed at a future time, knowing that at least the targets build.
I just tried to build the psp branch, but I get this:
./easy-compile-docker-psp
[+] Building 0.2s (6/6) FINISHED docker:default
=> [internal] load build definition from Dockerfile.psp 0.0s
=> => transferring dockerfile: 310B 0.0s
=> [internal] load metadata for docker.io/pspdev/pspdev:latest 0.1s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 97B 0.0s
=> [1/2] FROM docker.io/pspdev/pspdev:latest@sha256:3a8b290093f95ef3c50034d9be27a946828a83ac4c3e00a8b2999555942a69ff 0.0s
=> CACHED [2/2] RUN apk add meson 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:817a734d9abd7a9e7c7a1fd5908aea0894ee76cb70404a530f287c3720b40ca8 0.0s
=> => naming to docker.io/library/paintown-psp-build 0.0s
(cd build-psp; meson configure -Dbuild_tests=false)
meson compile --jobs=`nproc` -C build-psp
ninja: entering directory '/paintown-bin/build-psp'
[1/1] Regenerating build files.
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/mesonbuild/mesonmain.py", line 278, in run
return msetup.run(['--reconfigure'] + args[2:])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/mesonbuild/msetup.py", line 358, in run
app.generate()
File "/usr/lib/python3.11/site-packages/mesonbuild/msetup.py", line 174, in generate
env = environment.Environment(self.source_dir, self.build_dir, self.options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/mesonbuild/environment.py", line 582, in __init__
config = coredata.parse_machine_files(self.coredata.cross_files, self.source_dir)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/mesonbuild/coredata.py", line 1125, in parse_machine_files
parser = MachineFileParser(filenames, sourcedir)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/mesonbuild/coredata.py", line 1061, in __init__
with open(fname, encoding='utf-8') as f:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/paintown-bin/psp-cross.txt'
ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
ninja: job failed: /usr/bin/meson --internal regenerate /paintown-bin .
ninja: subcommand failed
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /paintown-bin/build-psp -j 16
make: *** [Makefile:56: psp] Error 1
Compilation ERROR
I see. Must be the cache. Because, the file psp-cross.txt was renamed to mips32-eabi-psp.txt Try to delete the image
docker rmi paintown-psp-build
and relaunch
Well, I bought an old psvita and now I can test it using adrenaline. It's still throwing 800200D9. I'm investigating
I see. Must be the cache. Because, the file psp-cross.txt was renamed to mips32-eabi-psp.txt Try to delete the image
docker rmi paintown-psp-build
and relaunch
I did that, and also did a docker image purge and I still have the issue. I think it's somehow cached somewhere.
I see. Must be the cache. Because, the file psp-cross.txt was renamed to mips32-eabi-psp.txt Try to delete the image
docker rmi paintown-psp-build
and relaunch
I did that, and also did a docker image purge and I still have the issue. I think it's somehow cached somewhere.
mmm.. try
make clean psp-docker
OK I see, yeah that kind of works, or at least it tries to clean. Only issue is that now that I'm seeing is that the mounted file system is not changed so the created build-psp retains root ownership, so I had to delete as root.
I finally got it to build, I'll test on my psp later today.
Going forward though it would be preferable to keep all that information and data in the container and not pollute the root directory with it, just copy out the bins that you need. Additionally, I would also create the Makefile in the container and remove the psp targets in the main Makefile because you won't be able to build them natively without the docker file etc. Take a look at my docker containers for devkitpro on how I create the makefiles and copy out bins, which you will need to change the owner on them. Good work.
I have implemented the file-system layer. But something is still missing. Pointing to
'-DDATA_PATH="ms0:/PSP/GAME/paintown/data"'
and running on retroarch show up
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile(''): FAILED, 21 - access = 1 '' [libretro ERROR] [CPU] BREAK! [libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile(''): FAILED, 21 - access = 26 '' [libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data'): FAILED, 2 - access = 1 '' [libretro ERROR] [CPU] BREAK! [libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/system.txt'): FAILED, 2 - access = 1 '' [libretro ERROR] [CPU] BREAK! [libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/system.txt'): FAILED, 2 - access = 1 '' [libretro ERROR] [CPU] BREAK! [libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/paintown/paintown.txt'): FAILED, 2 - access = 1 '' [libretro ERROR] [CPU] BREAK! [libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/GAME/paintown/data/paintown/paintown.txt'): FAILED, 2 - access = 1 '' [libretro ERROR] [CPU] BREAK!
Did it work properly with devkitpro?
it finally works! The error was:
[2:system.cpp:61 2024-03-01 10:15:27.978 PM] Error getting file stat: -2147418110
[0:paintown] There was a problem loading the main menu. Error was:
../src/r-tech1/menu/menu.cpp:1833 Menu parse error
../src/r-tech1/file-system.cpp:608 Could not find 'data/sprites/paintown.png'
[1:paintown] Waiting for music thread to die
[0:init.cpp:130 2024-03-01 10:15:29.39 PM] Shutting down SDL2
[0:main-menu.cpp:1043 2024-03-01 10:15:29.0 PM] Bye!
and I figure out only after enabling the psp_stream logger
Oh thats cool. I wish there was analog to that in devkitpro. Awesome work.
Issue with r-tech1/dumb
How to reproduce
Error https://github.com/kazzmir/paintown/actions/runs/7995178382/job/21834909397?pr=93#step:3:10387