devkitPro

I have always used subversion to get access to devkitpro-libogc.tar.gz and the latest libogc changes as required to complile WIIMC.
I last did this on March 6 and got libogc 4903.

I now need 4915 to compile WIIMC 1.2.6 but that link to sourceforge returns a 404 and I can find no other path to those files. Can you help me?

Thanks.

The subversion repository has been replaced with git repositories. SVN revision numbers are no longer relevant nor should they have ever been used instead of stable releases.

The latest changes are now in stable release 1.8.11

WinterMute wrote:The subversion repository has been replaced with git repositories. SVN revision numbers are no longer relevant nor should they have ever been used instead of stable releases.

With due respect, several of the "stable releases" have had major bugs such as broken support for multiple wiimotes (libogc 1.8.5) and more recently broken network support if wc24 was disabled (libogc 1.8.9). The latest libogc release (1.8.11) also doesn't work properly with most of my own apps due to the scaled PAL video mode being changed from 574 lines to 576, which doesn't work well with GX_AdjustForOverscan().
If you're going to promote the use of these "stable" releases over the current code from the repositories (or "revision 1234" which is known to work with a particular app) then I suggest a bit more effort be made to ensure they are actually stable!

Stable releases aren't bug free, merely as bug free as can be determined at the time of release. Obviously it's really difficult to ensure that there aren't problems with every release until it gets wider use which won't happen until an actual release is made.

1.8.9 was replaced with 1.8.10 within a matter of hours of the wc24 problem being reported and I don't yet see an actual bug report for your particular issue with 1,8.11. Perhaps you might consider looking at the issue and submitting a patch rather than jumping on the internet to criticise - any help you can offer would be greatly appreciated.

Ultimately these tools are a group effort with many contributions from users over the years. Sadly the people who have helped the most tend to drop out and go work on something less public due to unconstructive criticism that can be very difficult to not take personally.

You're asking me to post a patch to revert an insufficiently tested change that broke something? I think I've discovered the real reason why people decide to invest their time elsewhere.

tueidj wrote:You're asking me to post a patch to revert an insufficiently tested change that broke something? I think I've discovered the real reason why people decide to invest their time elsewhere.

unconstructive criticism just like this. yes we are asking you to post a patch. if you are not part of the solution, you are part of the problem.

You're seriously asking for a patch to revert a previous commit?
Here's the commitdiff that broke stuff: http://devkitpro.git.sourceforge.net/gi ... e730294944
Apply it with -R (except for the typo fix to mode TVEurgb60Hz480IntAa which snuck into the same commit) and there you go.
All this just because of 2 lines which aren't even visible on most TVs...

Reverting said commit isn't a fix.

Standard PAL resolution has 576 active lines ( barring PAL M and PAL I which have 480 and 582 respectively). 576p support has been requested by several people so I'd rather fix whatever your issue is properly than revert this.

At the very least can you show a small test case which illustrates your problem so we can look to see what's going wrong and where. Looking at GX_AdjustForOverscan I don't see anything obvious there which would cause problems. I'd suspect the appropriate entry in the video_timing array in video.c just needs tweaked for the updated mode.

Yes, I didn't necessarily mean a patch to revert the change that broke what you have. Obviously the change was made to fix something else or as an enhancement. We should be working toward fixing your problem while still supporting the new functionality, not just simply reverting it. You didn't even say what the problem was, just that there is a problem. If it's some kind of issue that occurs with your TV, there's no way we could test all different brands and types of TVs for this kind of change. But we don't even know what the issue is that you're talking about.