Kronos
Kronos copied to clipboard
FCare
gl es shader compile fixes and libretro cmake build
hey my friends from kronos. on the weekend i came back to give koronos another rpi4 try. i started a bit more fresh from the current branch.
- i reintroduced the possibility to build libretro via cmake.
- i fixed shader compile errors
- i brought back some of the debug output options and logging on libretro -> see commit comments
- i moved libretro to the ports folder since its a port and it then fits to the current cmake logic for ports
i wanted to share that stuff with you (@FCare @BenjaminSiskoo). you may find it useful somehow and probably you will take some changes into the repo. pls see the commit messages for details and reasonings. feel free to comment on it as usual ;).
the results of it are:
the core boots and initializes.
the core also starts to run and sound output is hearable.
sadly still no vid output since it seems to run out of vid memory but i bet the root is somewhere else.
what i get is:
Failed to register allocate at 2 threads with any strategy. fragment shader failed to compile. Expect corruption.
But still i do know that it can be done.
If you absolutely want to add an alternate libretro build process using cmake, do it in a way that won't change anything for the current build process. In its current state, your PR breaks the build scripts for every external projects using this core.
If you absolutely want to add an alternate libretro build process using cmake, do it in a way that won't change anything for the current build process. In its current state, your PR breaks the build scripts for every external projects using this core.
sad that you don't ref changes. you don't ref what external project. you could have done comments on the changes you are referring to.
however its here for reference and suggesting changes. i guess you are talking about moving the libretro. it was reasoned why the files where moved. and following the existing projects logic for ports it is how it should be. all the other things are reasoned as well.
you don't ref what external project
As i said, EVERY retrogaming project using this, meaning retrogaming distros like retropie and consorts but also the libretro buildbots.
The project needs to stay buildable through make -C yabause/src/libretro/.
Hi @rob-ack,
Good to see you. We appreciate your work. But for now, the goal is to polish some parts (Qt for example), emulation improvements, fixing sound issues, add some particular features, etc...
We can't handle more ports. Linux and Windows are the only one for a long time.
Big changes is not for now, I guess Vulkan will be a big add later.
Thanks for your PR :)
The project needs to stay buildable through make -C yabause/src/libretro/.
its exactly the problem and what i suggest to improve. the libretro core needs to be maintained separately because there is a make file which is not part of the kronos main build system. the make file is an legacy. it mimics the cmake main build system. every time something important changes are made regarding cmake the make file is likely to be changed as well.
improving this situation it is the whole purpose of adding the cmake file for lib retro port. and if you would add it for real. you would also even remove the make file (which i not even did here). already only for maintaining reasons the makefile should go away. yes EVERY other project would need to adopt here. but make is not really cross platform anyways. cmake is truly cross platform. is keeping makefile forever really what you want? and keep going through this maintenance?
however the file move is not needed in general. to keep compatibility we could do different things. like route make file or. keep the makefile in the libretto location. what about this suggestion? as i sayd its here for ref.
is keeping makefile forever really what you want?
Yes, i prefer modifying the makefile once or twice a year than breaking every build scripts around. Furthermore including that libretro cmake support doesn't require you break the current method.
Furthermore including that libretro cmake support doesn't require you break the current method.
Yes true so i added 3ebb956f558fdb88f46e0618ae4066305b280f54. It should definitely not break external things by keeping the makefiles in the same location but changing the directories a bit around. Do you have automated processes in place which can verify it works like intended?
You'll need to replace every occurence of --version-script=link.T by --version-script=$(CORE_DIR)/link.T in the makefile if you intend to have link.T in a separate folder.
Also note that calls to LogStart and LogStop should probably be made optional in libretro.c, as logging is probably gonna affect performance in some way.
Yes @barbudreadmon thank you for pointing this out. So i made that adoptions in the latest commit a3e12eef70bdb1b18fdb883cb991950541711a24 I think link.T should stay near the source files so i did change as you suggested.
Currently debug.c isn't built when using the makefile, so you can't call those functions at all or you'll need to add debug.c to makefile.common.
h yes that was the case in cmake too and i added them here. ill add them in a moment