Next release discussion about mupen64plus-core HOT 25 CLOSED

What version it would be? 2.1? I say this so we could use the Milestone feature of github for tickets. :)

from mupen64plus-core.

I was thinking of tagging this as version 2.5, because it's been so long since the last release, and with all the core refactoring changes it might not be long before we have to go to 3.0 anyway.

As far as what needs to be done, I would mostly like to see only bug fixes being merged (no refactoring which doesn't fix anything) and lots of testing. When I get ready to do the actual tag and release, I'll probably make "smoke test" builds under win32/osx/linux to make sure everything builds and seems to run okay.

from mupen64plus-core.

It looks like 2.5 is going to be a "because we haven't released in a long time" release. Wouldn't it be more meaningful if it signaled phase 2 of the refactorings, where the new APIs are in place but still optional? It would be a "we're heading in this direction, be ready" update.

from mupen64plus-core.

Also I want to name the next release as 2.5 because I think 2.1 and 2.2 are too similar to 2.0; they are easily mistaken for each other. This might not be universal; it might just be me :)

from mupen64plus-core.

"because we haven't released in a long time" release

That may be true to some extent, but I went through the list of commits and since last public release (3 july 2013) we got some very good stuff which have user-visible impacts (non exhaustive list) :
[CORE]

• PIF challenge fix (Banjo Tooie)
• Timing fixes related to CounterPerOp setting (various games)
• EEPROM fixes (Donkey Kong saves)
• Perfect Dark freeze fix
• Notable performance improvement for the pure interpreter

[RSP]

• JPEG task dispatching fix (Bottom of the 9th)
• Musyx support in HLE (many games)
• POLEF audio command implementation (fix PilotWings intro)
• RESAMPLE_ZOH audio command implementation (fix 1080 audio test)
• RESAMPLE_GE audio command implementation (fix GoldenEye "missing" sounds)
• NAUDIO_14 audio command implementation (fix Conker Bad fur day sound effects)

Plus many non-user visible impact aka major refactorings and synchronization with m64p-ae.
But the best thing that happened since the last release is the constitution of a team of skilled and dedicated contributors.
So yeah I think we can bump the version number to 2.5 easily, we earned it :)

from mupen64plus-core.

I don't know who is responsive or the next release build. I don't know if there is a release tool chain or anything but I would humbly ask if it should be possible to compile my fix_gles branch on all platform for me? Like a real release.

I say this because as you maybe know, I removed the pgl prefix and it could create problem during cross plateform compilation. I know my branch build on Raspbian (Debian for RPi) and Linux x64 (my station) but I would like to at least point on which config my branch fail. I don't ask for a real release, just pass through every compiler. If everything goes smooth and we can have a rice build with my changes on every plateforms (even for experimental purpose) I would love to see users test it.

The pgl prefix is a problem on OpenGLES code (my fix_gles simply remove every pgl prefix in favor of gl). If I rice could do thing right that would be perfect.

Thanks in advance!

from mupen64plus-core.

I can make builds under OSX and Win32/MSVC2013 for you. Do you want me to test the plugin as well, or just make sure this branch builds? I don't think I have any 32-bit linux systems to test this platform.

from mupen64plus-core.

Thanks Richard!

If it build and you can test it would be awesome of course! I don't want to waste your time.

I just think if it build without trouble and work properly we could finally merge it with upstream.

from mupen64plus-core.

Narann, I got your rice video branch to build under Win32 by making some changes:

http://pastebin.com/29S3ickn

I tried to run it, but got a crash:

from mupen64plus-core.

Thanks a lot Richard!

From the pastebin you sent, I noticed you didn't use the fix_gles branch but the master one.

fix_gles does not rely on Rice extension function pointer but pure SDL (with #define GL_GLEXT_PROTOTYPES). It would have been interesting to test.

Anyway, I think I pointed your problem and just fixed in my master.

Hope it's fine!

PS: Notice I didn't add your pastebin modifications in both master and fix_gles branches yet. I will do this asap.

from mupen64plus-core.

Narann, that is strange because after I cloned your rice video fork, I did a 'git branch' to list the branches and see if I needed to switch to fix_gles. But it only listed the 'master' branch; there was no other. Did I clone the wrong repo? Or is there something special I need to do to tell it to get all of the branches?

from mupen64plus-core.

git branch -r

from mupen64plus-core.

or when you want all branches then

git branch -a

from mupen64plus-core.

Hi @richard42, does @conchurnavid command line (thanks!) fix your problem?

from mupen64plus-core.

I think it's more complicated than that, but I did a little research and learned about git's behavior with respect to branch checkout. By default it only retrieves the master branch from a remote repo when you do a clone. There are several different options that you have for getting a local copy of another branch, depending upon what you intend to do with it. Are you ready for me to test the fix_gles branch on win32 and osx?

from mupen64plus-core.

Yes if you don't mind. :)

The commit to use should be https://github.com/Narann/mupen64plus-video-rice/commit/6597ee565631aedde2dffd798182585b42a03489 (The latest of fix_gles branch actually).

from mupen64plus-core.

OK, I checked out this branch. It doesn't compile in MSVC2013 due to the dynamic local array definitions. Here is a fix:

http://pastebin.com/nwRTG3K8

Then the linker fails, because it cannot link against the GL functions:

http://pastebin.com/03WcVRDx

from mupen64plus-core.

Thanks Richard! I'm digging into this GL extension stuff right now and I think I start to get the point of all those function pointers. Documenting myself I realized there is no safe cross plateform way to load OpenGL function pointers without rely on external deps or do some hacks.

However, I think the way Rice was doing things originally was not the most cross platform one (because of the pgl prefix). I've just commit a redo of the function pointer.

I've asked @Nebuleon to confirm if this work on real GLES hardware.

Roughly, I define prototypes depending on the platform W32? GLES? etc... I didn't tried with OSX yet so any compiler errors about missing symbols would help me to categorize function declaration depending on platforms.

Anyone is welcome to test!

Also, if anyone could send me the gl.h of OSX and gl.h of Windows. I could use them to find which OS need which function.

from mupen64plus-core.

I can do a build later, but OSX will have everything in OpenGL 2.1

from mupen64plus-core.

Narann/mupen64plus-video-rice@62f6e7b504d05ebd72067c6e738bad55d42fdc8c still works on a Linux GLES2 device. Now, that commit's purpose is to build on Windows, so that will need tested too.

from mupen64plus-core.

Nebuleon just confirm me my commit is working on real GLES hardware.

At the current state, OSX function pointer gathering is supposed to be the same than Linux one.

from mupen64plus-core.

@Narann - Sorry I've been out of the loop, things have been hectic here. I just tested your fix_gles branch on Android and am able to build without issue :) I'll describe the runtime behavior at mupen64plus/mupen64plus-video-rice#31

from mupen64plus-core.

What's the status on this? I am planning a banjo kazooie tas and would like to get started on it, and i've been told since August this is being worked on with no real updates.

from mupen64plus-core.

Hello!
If by "on this" you mean the release, it's out!

from mupen64plus-core.

Lets close this, and create a fresh one to plan out the next release?

from mupen64plus-core.