Open RobLoach opened 6 years ago
Fullscreen for any resolution Gamepad with force-feedback support. Mimiga mask ending pictures (re-drawn by me) Modern main menu Support for "New" and "Remastered" tracks from CS+
WOW yes excellent, really cool if it can be had to the official release, there are really cool new feature :)
I can try to edit the make files and everything and see if it works on retropie
Put a $15 bounty on this. I'd love being able to play Cave Story within RetroArch in widescreen and with the remastered soundtrack. :D
To complete the bounty:
you can play it, sorta. its verrrrry laggy and the resolution is wack. you can play it by opening file manager and going to the executable and pressing enter. its time for a real port
Put a $15 bounty on this. I'd love being able to play Cave Story within RetroArch in widescreen and with the remastered soundtrack. :D
To complete the bounty:
- NXEngine-Evo ported to libretro
- Support for different resolutions, including widescreen
- Remastered and New soundtracks from Cave Story+ usable from the system folder
Controller force feedback support
- Easiest way to test is by taking damage in-game
Put this bounty on the main issue page, this will probably get their attention
Put a $15 bounty on this. I'd love being able to play Cave Story within RetroArch in widescreen and with the remastered soundtrack. :D
To complete the bounty:
- NXEngine-Evo ported to libretro
- Support for different resolutions, including widescreen
- Remastered and New soundtracks from Cave Story+ usable from the system folder
Controller force feedback support
- Easiest way to test is by taking damage in-game
I would like to add 40 buck for this bounty, how i should do ?
I would like to add 40 buck for this bounty, how i should do ?
Ty sadly my paypal is stucked :/, I will look if there is possibility to make virement. Edit : Done I hope this 50 $ tip will give courage to dev :)
denim2x set a goal of $170 we are on 65/170
Need more backers or dev :)
Added an additional $15 bounty. Any chance you can add the Bountysource committer tools to this repo so the title is automatically updated with the current bounty?
nxengine-evo maintainer doesn't want to bother with libretro. Rather, he sounded pretty angry when I asked him about libretro support.
If someone wants to port nxengine-evo, don't expect any upstream support. Without upstream support, it can be tough. Unless the upstream maintainers are asking for libretro support, don't expect any support from upstream.
Improving an already working nxengine core is a viable option if at least one programmer is interested in spending time on it regularly.
I think we should focus on bug fixes because the return on investment from enhancements seems questionable. To make a competent programmer work on nxengine-evo libretro port, I guess that the bounty should be above 30,000 US dollars. After fixing a few remaining input bugs, nxengine core should be pretty enjoyable.
If you want to play the original japanese version right now, there is PSP port of Cave Story Engine 2. There are a few widescreen bugs, but it is playable. While nxengine-evo is the cutting edge, playing Cave Story without retroarch zfast-crt shader is dificult on my eyes.
nxengine-evo maintainer doesn't want to bother with libretro. Rather, he sounded pretty angry when I asked him about libretro support.
If someone wants to port nxengine-evo, don't expect any upstream support. Without upstream support, it can be tough. Unless the upstream maintainers are asking for libretro support, don't expect any support from upstream.
Improving an already working nxengine core is a viable option if at least one programmer is interested in spending time on it regularly.
I think we should focus on bug fixes because the return on investment from enhancements seems questionable. To make a competent programmer work on nxengine-evo libretro port, I guess that the bounty should be above 30,000 US dollars. After fixing a few remaining input bugs, nxengine core should be pretty enjoyable.
- Widescreen support will introduce bugs because the original version wasn't designed for widescreen. Widescreen support already introduced bugs in PSP port of Cave Story Engine 2.
- Unless someone wants to add vibration support for fun, the return on investment is abysmal. The original game is pretty enjoyable without vibration.
- The original soundtrack is perfectly fine. The return on investment for newer soundtrack is questionable without someone willing to support it for fun.
- However, translation support is desirable as nxengine core supports only the english translation. It doesn't support the original japanese version.
If you want to play the original japanese version right now, there is PSP port of Cave Story Engine 2. There are a few widescreen bugs, but it is playable. While nxengine-evo is the cutting edge, playing Cave Story without retroarch zfast-crt shader is dificult on my eyes.
If this project is ported in libretro it'll be a very good start point to fork the core, and improvement here will be added to the core easily by anydev in charge of the repo, what you're pretending here look childish. And the dev have no obligation to make a libretro core : I'm surprised you had ask him directly, it's obvious he already know this issue. What the point of complaining about here, ou should'nt bother the dev and any one involved here will look at you as a salty troll.
You should read again your message and respect the work done on nxengine-evo, stop arguing and post pollution on this topic. By the way If you want to add a tip to the bounty you're welcome.
I didn't ask the maintainer to port nxengine-evo to libretro. I merely asked him a question about a difference between nxengine-evo and nxengine-libretro. I thought he would be at least interested in a small difference between similar projects, but he responded in anger.
Comparing nxengine-libretro and nxengine-evo is a fun activity for me, so I assumed he would be interested, too. I'm driven by curiosity.
The attitude of the upstream maintainers should be a factor in considering a libretro core. If the upstream is indifferent or hostile, then there needs to be a hard fork which is going to be harder. This is a factor. If someone wants to do it for fun, it can be done for free or at a cheap price.
After fixing jump and textbox overflow, at least from my perspective, nxengine-libretro can compete with nxengine-evo. From my perspective, nxengine-libretro is almost there. I am going to settle with nxengine-libretro which also happens to be its own upstream after the upstream became inactive.
the dev have no obligation to make a libretro core
This is why an already working core is a better option if it can be fixed cheaply. Making a new core from scratch is difficult. Nobody can be expected to do it except for fun or a large enough sum of money. I've already fixed most input bugs in nxengine-libretro. After fixing jump, I think there will be no obvious input bugs, and nxengine-libretro is going to be slightly better than nxengine-evo and cave story engine 2 in terms of input because nxengine-evo and cave story engine 2 activate machine gun if I exit inventory, options, or map system by pressing fire.
That said, if you want to see nxengine-evo libretro core, the real currency is not money but attention. If there is at least one programmer who wants to pay attention to nxengine-evo libretro core, then some bounty can go a long way. Without such a person, you are going to need to make a person interested or put up a large sum of money as the bounty that catches a random programmer's attention.
difference between nxengine-evo and nxengine-libretro
nxengine-evo is a much improved port than nxengine-libretro. The differences are listed on the README file: https://github.com/nxengine/nxengine-evo#differences-from-the-original-version-of-nxengine
The attitude of the upstream maintainers should be a factor in considering a libretro core.
If someone takes on the libretro port, it can live outside of the nxengine-evo repository/project. Being an open source maintainer is a lot of work, and can be extremely stressful. NXEngine-Evo has a goal of just running on SDL2, so porting to another platform like libretro can be a challenge, along with the ask to maintain it down the line. A hard fork wouldn't be harder, it would actually be the same amount of lots of work.
If someone wants to do it for fun, it can be done for free or at a cheap price.
If by free or cheap price, you mean hours and hours of research and implementation, then yes :wink:
nxengine-libretro can compete with nxengine-evo
I'd argue that nxengine-evo is MUCH more improved than where nxengine-libretro is, or ever could be. Isage and crew have done marvels on refactoring and cleaning it. I wouldn't say "compete", but live along-side.
In terms of how a port could work, I see two options...
Both methods would be a good amount of refactoring, cleaning up, and testing.
I feel like porting SDL2 would be the better option, as it would make it easier to maintain the fork in the future if upstream changes any of their SDL-related code; and it could also help with development of other libretro ports. Super Mario War, anyone?
rtype started this years ago but I don't think it really went anywhere: https://github.com/r-type/sdl2-libretro
I think the sdl1.2 version is actually mostly functional.
I'd argue that nxengine-evo is MUCH more improved than where nxengine-libretro is, or ever could be. Isage and crew have done marvels on refactoring and cleaning it. I wouldn't say "compete", but live along-side.
I was referring to 20/80 rule. If you apply 20/80 rule to itself, you get 4/64 rule and 1/51 rule. After twinaphex merges my jump fix into nxengine-libretro, I may not experience obvious bugs on nxengine-libretro. Just being able to play nxengine-libretro without bugs gives me 50~80% of nxengine-evo. That's good enough for me. You get most of the results with just the basics.
nxengine-evo still hasn't tackled a few things like a clean resource editor that people can use easily. isage admittedly hates https://github.com/nxengine/sifedit because sprites.sif still isn't human-readable and sifedit is fragile. Editing sprites.sif incurs horror in people's minds because they can't scrutinize change to a binary file. I say nxengine/sprites.json or nxengine/sprites.txt in retroarch systems folder is going to be better than sprites.sif. Once either nxengine-evo or nxengine-libretro gets human-readable resource files (in retroarch systems folders), progress will be insane because anyone will be able to edit plain text resource files with a text editor. Somebody just needs to properly document how to edit plain text resource files.
With easy-to-edit plain text resource files in retroarch systems folder, getting widescreen support and Cave Story+ resource files is going to be relatively straightforward.
Adding controller force feedback support would be easy. You would just have to see where nxengine-evo codebase activates vibration and make nxengine-libretro vibrate in similar places. Any mediocre programmer can do it. But, I am pretty much satisfied without vibration.
Anyway, if anyone wants to work on nxengine-evo libretro core, good luck.
I found a better way to run nxengine-evo on retroarch. It is to port vita3k(playstation vita) or yuzu(nintendo switch) to libretro. nxengine-evo has been ported to playstation vita and nintendo switch. By playing nxengine-evo on vita3k-libretro or yuzu-libretro, you get states and rewind for free.
Porting nxengine-evo to PSP seems like the cheapest option because ppsspp libretro port works well.
I found a better way to run nxengine-evo on retroarch. It is to port vita3k(playstation vita) or yuzu(nintendo switch) to libretro.
Bruh.
hello so without evo we can't use the translated version? because i try to run cave story (it) or (pr) and games crash after a few second of intro...
@naxil I recommend trying out https://github.com/andwn/cave-story-md on a libretro genesis core. It supports multiple languages.
There are a few features that we could take advantage of if we use https://github.com/isage/nxengine-evo .
It's based on SDL2, so we could benefit from doing more work on the non-existent SDL2-libretro bridge.