search

mupen64plus / mupen64plus-core

Core module of the Mupen64Plus project
1.25k stars 254 forks source link

Release Planning #353

Open rlabrecque opened 6 years ago

rlabrecque commented 6 years ago

2.5 was released on Apr 26, 2015 and is 446 commits old at this point.

What all needs to happen for 2.6+? Is Richard still around to do this?

What are the blocking issues and outstanding pull requests that need to be resolved/merged before this could happen?

What kind of promo/marketing/etc material is needed? Does anyone want to do some kind of progress report? (I'd be willing to do some of the writing, but only if others can make a list (with references) of some milestones that have happened over the last 2 years.)

bsmiles32 commented 6 years ago

Indeed a new release would be good as 2.5 is pretty old and many improvements have been made. Especially with the recent works of loganmc which increased compatibility. On the non user visible side of things, a lot of refactorings happened (and I still have a lot to do). Before the release, I'd like to finish merging currently opened PR, especially those that improve compatibility. My memory refactoring PR should not be blocking the release as it is purely internal and therefore can wait if it's not ready. It would be good to have the tpak/gb frontend part ironed out also. Then testing and ensuring everything is as smooth as possible (especially new_dynarec which I have broke repeatedly during the last 2 years).

I can help with the list of milestones since 2.5

loganmc10 commented 6 years ago

I would some to see some kind of "audit" of the CountPerOp/CountPerScaline settings in the ini file. It's frustrating that the emulator relies on those settings, but it does affect compatibility (recent examples are Resident Evil 2 and Episode I racer audio)

This would be a good task that someone without any programming knowledge could contribute to. Just a thought. That might be a "2.7" task though, probably better to just wrap up what's pending for 2.6

loganmc10 commented 6 years ago

Another major item (I think):

Previous releases haven't officially bundled a GUI. I think this is a mistake and reduces the audience that finds interest in mupen64plus. Others might disagree, but I think it would be worthwhile to officially bundled a GUI frontend with the release

rlabrecque commented 6 years ago

I'm going to disagree with the frontend, that seems like months worth of effort. This release that should happen soon just so that regular users stop downloading a version that is some 2 years old. Even if it were 'blindly' released today it would still likely be better than 2.5 in that regard.

loganmc10 commented 6 years ago

I didn't mean write one from scratch, but fair enough, getting a release out as soon as possible is a good goal.

AmbientMalice commented 6 years ago

Most users are not interested in using an emulator without a GUI, and the decision to release versions of mupen64plus that didn't have a GUI was a terrible one. Mupen64plus needs an official GUI that meets some basic functionality standards, and also needs an easy to understand website with stable and current builds. At least in my opinion.

bentley commented 6 years ago

Be that as it may, that’s no reason to delay a new release.

AmbientMalice commented 6 years ago

I suppose so.

rlabrecque commented 6 years ago

Indeed, I would absolutely love to see a GUI, but one thing at a time! This post actually stemmed from a friend not being able to use M64+ without compiling the latest release for his distro... We (you guys!) definitely should work to get to get a regular release of M64+ to be at least as good as GLupeN64 was; but if someone wants to use M64+ today they shouldn't have to compile it themselves. Most people download the official release binaries and outside of those using libretro they aren't even using any of the improvements any of you have made over the last 2 years! I know for my own work it hurts knowing that people are using something even just a few commits out of date, it's not representative of the project in it's current state.

I guess @richard42 is probably the blocker here, any thoughts? Anything that you'd like to see happen before you'd do this? Do other mupen64plus org members have the authority/ability to do this if Richard were MIA for a significant period of time?

bsmiles32 commented 6 years ago

Edit : see updated list in following comments

Looking briefly at the commit logs, the main changes in the core are :

Also the HLE rsp got several audio ucode fixes and supports the bilinear resize used in Resident Evil 2.

And several bugfixes as usual.

richard42 commented 6 years ago

Hi guys. I'm not really MIA; just lurking. I see every comment made here in our github projects, and in fact they're filling up my inbox at home. I just don't have the time to respond much or work on development tasks.

Regarding the necessary steps to take before making a release, I like to see the following:

I would like to at least go through all of the PRs in my inbox and merge any stragglers that look good enough to include in the release, then allow for a week or two of testing to make sure there's no major problems. I'll try to get this done by the end of August.

AmbientMalice commented 6 years ago

I would some to see some kind of "audit" of the CountPerOp/CountPerScaline settings in the ini file. It's frustrating that the emulator relies on those settings, but it does affect compatibility (recent examples are Resident Evil 2 and Episode I racer audio)

The lazy option would be to just imitate PJ64's settings. But that's unwise. I will do a bit of testing and cross-reference with PJ64. A few games come to mind, including Rayman 2, which on PJ64 uses Counter Factor 1 to fix a game breaking physics bug with a certain boss. But I don't know whether mupen64plus needs this. And testing this would take a long time without a save state from that boss.

loganmc10 commented 6 years ago

mupen64plus can load PJ64 save states if you have one.

I have noticed differences between the 2 emulators in this department, but mostly I think the CountPerOp settings already match (I think someone did something like that a while ago).

AmbientMalice commented 6 years ago

mupen64plus can load PJ64 save states if you have one.

I'm trying to load a PJ64 Rayman 2 save into mupen64plus, but it freezes immediately.

loganmc10 commented 6 years ago

Yeah I should have mentioned, it's pretty hit and miss. Is there a regular game that gets you close? I wouldn't mind playing through it sometime

AmbientMalice commented 6 years ago

Is there a regular game that gets you close?

You mean regular save file? No, it's around 50% through the game, and I haven't played Rayman 2 properly in several years. What is CF=0, BTW? What value does that translate to, because m64p seems to use it by default and as far as I know that isn't valid.

loganmc10 commented 6 years ago

It means "take the default". Which is 2 unless there is something in the INI file saying otherwise. If you set CountPerOp to something other than 0, it will override the INI setting

Papermanzero commented 6 years ago

Full SDL2 support would be also great. The rumble feature for windows is for example not implemented, although it would be possible with sdl2. In generell, I would resolve the audio API and input API. Means, integrate the audio and input plugin into the core. It makes more sense, to reduce the interfaces and to focus on existing solutions. Concerning UI, I actually thought m64py is recommended because it is part of the mupen64plus project space here on github. M64p is also a great UI, specially because it is upporting x64. However it is not so beatuiful as m64py. But it is getting better and better. In general, I would go for the mednafen approach. Keep the main emulator seperate from the UI. The UI can be bundled. Either M64p od M64py.

rlabrecque commented 6 years ago

@Papermanzero Unfortunately all of those things are out of the scope for what's possible this release.

bentley commented 6 years ago

Are we any closer to finishing @richard42’s action items?

What’s the current status?

bsmiles32 commented 6 years ago

Here is my latest attempt at summarizing the current changelog (6/6/2018) :

Infrastructure - All projects :
- Travis MXE support
- use trusty Travis image
- AppVeyor support
- Build Badges

Plateforms:
- OSX fixes, proper file locations
- BSD fixes
- Raspberry Pi: use new vendor library names
- SDL fixes
- Add x64 configuration to VisualStudio
- support libopcode >= 2.29

Tools:
- Add a program to model N64 joystick controller physical limits

API/Backends:
- Add VidExt_GL_GetDefaultFramebuffer function to video extension API
- Add M64CMD_SET_MEDIA_LOADER command
- Allow GFX plugin to know about RDRAM size and SP_STATUS_REG
- Add ConfigExternalGetParameter function to config API
- Add more flexibility to Joystick Mapping command strings, add some missing Joystick mappings
- Introduce several backends interface (audio_output, clock, controller_input, joybus, rumble, storage)

Cleanings:
- update project,wiki URLs
- many warnings fixed (gcc, clang)
- code indentation
- magic constant replacements
- source reoganization (device, backends, ...) to improve components containment
- allow usage of C struct offsets from asm files
- removal of most global variables usage from emulation code
- regroup mips instruction definition inside a single file
- use NASM for x86/x86_64 plateforms
- memory refactoring
- r4300 module refactoring, table based instruction decoder
- removed some undefined behavior

Optimizations:
- use xxHash instead of adler32
- allocate all memory in a single block
- input polling done before SDL_Delay
- Speed limiter logic rewrite
- new_dynarec: recompiled code optimizations

Emulation :
- open bus reads / writes
- Cart ROM write fixes
- partial RDRAM emulation - RDRAM detection hack removed
- reset logic refactorings (might still need some work)
- fixes for FBInfo support
- TLB fixes
- CP0 registers fixes (ERROREPC, RANDOM)
- CP1 rounding fix
- CP1 FPR shuffling logic fixes
- DP/SP scheduling reworked - WDC, PD (LLE), ...
- AI DMA reworked - Fixes No sound in Twisted Edge
- SI DMA reworked - DelaySI Hack removed, SI DMA duration is now configurable per game
- PI DMA reworked
- PI/SI DMA timing randomization
- VI interrupt scheduling reworked - remove AlternateVI timing Hack (Pokemon Puzzle League)
- PIF/Joybus devices rewrite
- preliminary support for different Flashram types (still need some work to allow effective selection)
- better SRAM support
- Transfer Pak and several GB mappers support (MBC1,2,3,5, full pocket cam support)
- Pak switching logic reworked
- PIF Boot ROM rewrite
- CIC 5101, 5167 support
- AF-RTC rewrite
- Paper Mario (U) duplicated saves fix
- GoldenEye TLB speed hack removed in main r4300 emu (not new dynarec though)
- N64 Mouse preliminary implementation (not yet exposed)
- new_dynarec: fix Dance Dance revolution, Bomberman, WDC, Indiana Jones, Castlevania
- new_dynarec: TLB exceptions reworked
- new_dynarec: fix MULT64 instruction
and many more bug fixes
- preliminary 64DD support (no save, no disk swap yet)
- preliminary biopak support (constant heartbeat for now)
- clear DP_CLOCK_REG when requested
- fix memory debugging functions

DB fixes :
- save type, compatible paks fixing
- Add (B) games
- Add 64DD conversion games
- CountPerOp fixes
- OoT subscreen hack removed
- 007 - Goldfinger
- 40 winks
- Army men : Sarge's Heroes
- Bokujou Monogatari 2
- BattleTanx: Global Assault
- Conker Bad Fur Day
- Custom Robo V2
- Densha de Go!
- Donkey Kong 64 - Bone displacement hack removal
- Gantlet Legends
- Kirby 64 - Save size
- Mario Kart - Timing fixes
- Mischief Makers
- Resident Evil 2
- Star Wars Episode I Racer
- Star Wars Rogue Squadron
- Twisted Edge
- Yakouchuu II - Satsujin Kouro
- Vigilante games

SDL-audio:
- major refactoring to extract SDL backend into its own module
- Allow audio/video sync to be configured

SDL-input:
- many new gamepad auto-configurations
- model joystick physical limitations (disabled for now)
- fix pumpEvents before processing inputs

RSP-cxd4:
- Update to upstream version b03a098b857a36d4c26161d8923fa29c2435ad6f (11 June 2017)

RSP-HLE:
- Resident Evil 2 ucodes implementations (bilinear resize, video frame decoding)
- Allow LLE RSP fallback
- Allow GFX plugin to modify SP_STATUS_REG
- Don't set MI_INTR_SP if task is not finished yet (useful for WDC,StuntRacer)
- audio list bugfixes backported from pj64
- hard-coded LLE mode have been removed

UI-Console:
- Add support for transfer pak / gameboy cartridge selection
- Add support for DD IPL/Disk loading
- Add support for basic debugging

Glide64:
- minor compilation fixes

Glide64Mk2:
- Raspberry fixes
- Backport F3DEX2MM from GlideN64
- Subscreen delay fix for OoT
- Warning fixes

Rice:
- Big refactoring

Video-Z64:
- warning fixes

This may not be exhaustive, but should contains the most important changes since 2.5. Also note that last year was one of the busiest year of this project (~630 new commits in the core since v2.5) with several new active contributors which is really great ! Hope that next year will be as exciting as the last one :)

@richard42 : I'm not sure what's still blocking the release. Maybe we could switch into "release" mode now and only accept bugfixes for the coming weeks (2 weeks ?) and do the release then. Also what's the status about VS2015 migration ? I know it is blocked by the audio plugin because on Windows the internal sample format is F32 (and we only support S16). Do we wait for after the release to tackle this ?

Happy new year for all !

loganmc10 commented 6 years ago

The audio plugin issue is actually related to SDL2, not VS2015. I think the main thing blocking VS2015 is the Boost libraries used by glide64, they need to be rebuilt

bsmiles32 commented 6 years ago

@loganmc10 Thanks for the clarification. So should we delay the vs2015 migration after the release ? or do the boost rebuild and upgrade to vs2015. That could be interesting if vs2015 does a more performant compilation than vs2013.

loganmc10 commented 6 years ago

I personally wasn't planning on working on the vs2015 migration. I think having proper SDL2 support would be more important, you need newer versions of SDL to support new gamepads for instance, so if we released a Visual Studio version, it would currently be bundled with SDL1, and there are probably a good number of gamepads that wouldn't work with it.

I think glide64 and rice also had issues with SDL2 (along with audio-sdl), @richard42 I think knows about that, something about how the GL functions are linked.

richard42 commented 6 years ago

Yes, I'll build the next release with VS2013 and SDL1. I'm not looking forward to rebuilding boost or dealing with the OpenGL extension issues. @bsmiles32, thanks for putting together the changelist. It is pretty huge. I agree with your plan to only accept bug fixes for the next few weeks, focus on testing, and then make a 2.6 release in February.

bsmiles32 commented 6 years ago

Great !

ortegoli2010 commented 6 years ago

@richard42 i wait for your update N64 is my favorite console and i want play n64 games but cant take that Tnx for everything .

bentley commented 6 years ago

It’s been four months since the planned February release. What’s the current status?

bsmiles32 commented 6 years ago

I've updated my previous release post (from 1/1/2018) with all the new contributions up to this month. Feel free talk if you think I've forgotten some contributions.

richard42 commented 6 years ago

yes, I've been thinking about this as well. Like Douglas Adams wrote, I love the "whoosh" sound that deadlines make as they fly by. The problem is that people keep making changes :) Lately I've been thinking about the audio speed limiter issue. Someone filed a windows 10 audio issue. I think I'll try and fix this stuff up before the release.

robalni commented 5 years ago

I don't think it's a problem if we release it right now because if there are any bugs we can always fix them and make a new release. 2.6 or whatever it will be called doesn't have to be perfect. We can make patch releases like 2.6.1.

(Also, maybe we should update the soname, because there have been some incompatible changes)

rlabrecque commented 5 years ago

Yeah, basically even if there were some pretty bad bugs today, they are still probably less bad than many of the issues present in 2.5 that have been fixed since.

dreua commented 4 years ago

The problem is that people keep making changes :)

@richard42 This is why many many projects / distributions have a feature freeze time to stabilize the code base before release. You can block or ask members to stop merging to master (I've seen this e.g. on pip) for a certain time until a release is done. Merging new features can continue on a dev branch or stop altogether until the release is done, that's up to you.

The thing is: Linux distributions really do need a released version to package and distribute this software to their users. Without releases a big part of the hard work going into this project is wasted because most users can't benefit from it.

Thank you all for your attention and the great work with this emulator. I'd be very happy if you would consider releasing a priority at least until one release is done.

richard42 commented 4 years ago

I did make the 2.5.9 release in 2019. Now it's been over a year, and lots has happened since then. Logan has put a lot of effort into the new netplay feature, which is something that has been frequently requested. Once this is merged I'll do a feature freeze and get into the mode to make a new 2.6 release.

Narann commented 4 years ago

@richard42 I've created a 2.6.0 milestone so you can tag tickets you want the discussion to move forward in order to merge. For now, only Network ticket is there: https://github.com/mupen64plus/mupen64plus-core/milestone/1

dreua commented 4 years ago

Oh, yes I saw 2.5.9 earlier but didn't have it in mind when writing this yesterday: It is described as a pre-/beta release on the releases page but if you think it is better suitable for packaging than 2.5 then I'll try to package it anyway for Fedora. It looks like some distributions have made this exact choice. (repology)

Would you recommend distributions to package 2.5.9 instead of 2.5?

richard42 commented 4 years ago

@richard42 I've created a 2.6.0 milestone so you can tag tickets you want the discussion to move forward in order to merge. For now, only Network ticket is there: https://github.com/mupen64plus/mupen64plus-core/milestone/1

Thanks for setting up the milestone.

richard42 commented 4 years ago

Would you recommend distributions to package 2.5.9 instead of 2.5?

Yes, I think 2.5.9 is in good shape and is much newer than 2.5, so I would recommend packaging 2.5.9 until we can get 2.6 out. It's kind of funny, I've had an item titled "Make 2.6 mupen64plus release" on my electronic "to-do list" for over a year. During that entire time I've just been moving it forward, one or two weeks at a time. :) It will happen... I run Gentoo at home and see that the only mupen64plus build in the portage tree is 2.5.9.

Papermanzero commented 2 months ago

Just wanted to bring up the integration of plugins again with the goal of eliminating the plugin system.

Dolphin did it, PCSX2 did it, PCSX started with it… as good as the idea beginning of 2000 with the plugin system was the result was that the community got fragmented. The optimizations within an integrated emulator are just easier and better to maintain.

Parallel from libretro did already a great job as LLE solution. Just wanted to bring up the idea.