search

libretro / nxengine-libretro

Port of NxEngine to the libretro API. NXEngine is a Cave Story game engine clone
85 stars 89 forks source link

Close map system on fire, jump, or map button #82

Closed crocket closed 2 years ago

crocket commented 2 years ago

This is based on d3a48db5da79ae10e0bae1470f53e4fd38d1cafd from nxengine-evo which also closes map system on those buttons.

With this, I probably picked up all low hanging fruits.

button press leaks out of map system if a button is still pressed after map system closes, but I don't know how nxengine-evo manages to lock inputs when it closes map system or options. Fortunately, it takes a while for map system to close.

For deeper changes, it would be easier to port nxengine-evo to libretro from scratch.

Forget about rebasing nxengine-libretro on nxengine-evo. nxengine-libretro diverged too much from nxengine-evo.

inactive123 commented 2 years ago

Thanks for the PR, much appreciated.

Let me explain though why these divergences were necessary. There are issues with whole program optimization in both NXEngine and NXEngine Evo (this results in all AI breaking down on static consoles unless whole program optimization is disabled), file I/O was not abstracted (which we definitely need to do now because of Android and UWP), and libretro needs to run on many more platforms than these projects tend to care about. This all requires diverging from a hypothetical 'upstream'.

For instance, other changes that were necessary for nxengine libretro involved cutting down all file I/O related bottlenecks by pre-caching all the small files at the start, making sure that we stripped out SDL as much as possible and left it only at a baked-in and customized SDL Surface, as well as other necessary changes that increased portability.

crocket commented 2 years ago

I think there should be an easy guideline for developers so that they can design their emulators and game engines for libretro. It's best for the upstream projects to support libretro directly.

I created a gentoo linux package for ppsspp libretro core from upstream ppsspp. PPSSPP supports libretro.

inactive123 commented 2 years ago

It's best for the upstream projects to support libretro directly.

I kinda disagree with this too honestly, it depends very much on a project-by-project basis. In this case (NXEngine), I'd highly disagree except if they were to go to specific lengths to address all these issues. Even putting to the side whether or not the developers are reasonable and can be talked to and can be worked with (which is often times not something one can take for granted and most of the time trying to collaborate with them ends up being more high maintenance and struggle vs. just working in peace on it ourselves), most of the time we can do a better job making hard forks that play to libretro/RetroArch's strengths vs. just a shallow upstream core that runs bad, or doesn't run as well as it could be if it were specifically optimized. Plus often times all these changes these projects make are not completely relevant or useful.

If developers want to support it upstream, fine. But if it's just treated as an afterthought, if the core runs bad, if it doesn't run as well as it could be, and if more importantly the upstream doesn't care about the port, then it's better in our hands, and if we have to work on it and we have to be frustrated by all these questionable APIs and design decisions, we'd rather just hard fork it so it fits our design goals.

crocket commented 2 years ago

At least, nxengine-evo maintainer, isage, is willing to make it easy for libretro developers to port nxengine-evo to libretro while he doesn't yet want to spend his time on libretro port.

nxengine-evo looks like a cleaner codebase than nxengine-libretro.

inactive123 commented 2 years ago

Well, not trying to tell you what to do, as I said, your previous PRs were appreciated. If you want a nxengine-evo libretro core, go for it. You could collaborate with that author and try to make it happen. It'd probably be important if you do that though to go down the list of things we had to specifically adress with this current core, so that the core can at least compete with the current one. We don't want file I/O hiccups to occur that are going to ruin runtime performance, for instance.

nxengine-evo looks like a cleaner codebase than nxengine-libretro

I kinda disagree with that too. At least with nxengine-libretro, we can remove anything not relevant to libretro, and we end up with a much smaller codebase that is easier to understand. We don't need all these homegrown attempts at cross-platform code, libretro/RetroArch already takes care of all that. Often times it just turns a codebase unnecessarily more complicated than it has to be.

crocket commented 2 years ago

I appreciate attention to details which help me play old games without hassles.