Homebrew DOP-Mii v16 BETA by Arikado

[Shano56]

A new version of devkitPPC and libogc was released a few days ago. According to the changelog it fixed bugs that Daco and I bitched about relentlessly which broke DOP-Mii and priiloader. This resulted in a lot of rewriting on both our parts (probably for the better though to be honest) to comply with the newer libogc. Unfortunately, DOP-Mii was still not perfect for everyone. I probably get at least one or two messages a week from someone reporting a crash and I usually can't distinguish if it's a rare case not being refused to be handled that exposes a libogc bug which I don't check for or if it's someone incorrectly using DOP-Mii.

Anyways, I'm really overtired so I'll stop blathering. If you can, please try out the BETA .dol linked to at the end of this post. Let me know if it fixes stuff for you, gives you new problems, or if nothing changes for you. Assuming that this fixes stuff (syscheck no longer crashes on my end) for everyone I can probably get rid of most if not all of the code I wrote in to not load certain IOSs with certain patches and then try another beta release ... and if that works then do an official release and then finally get back to adding features to DOP-Mii instead of fixing existing stuff.

As always thanks for your patience on this and for all of the support. I would've given up on this project a long time ago if it weren't for all the awesome people out there.

Download: http://dop-mii.googlecode.com/files/boot.dol
Source: http://arikadosblog.blogspot.com/2011/07/d...i-v16-beta.html

 

[tueidj]

It's funny how people who don't know what they're doing blame all their problems on libogc, when they can't even pinpoint the bugs.

 

[OArikadoO]

It's funny how people who don't know what they're doing blame all their problems on libogc, when they can't even pinpoint the bugs.

That's a tad uncalled for. When a program works perfectly when compiled under an older revision of libogc but crashes upon doing something as rudimentary as an loading an IOS under a newer libogc revision than even a non-coder could tell you what's causing the problem. I've been busy with school so I apologize for doing little more than sending Daco some stack traces I ran. If I have anymore issues with the new release I'll be sure to work to more descriptively pinpoint the source of the problem and contact you directly if necessary since I actually have some free time on my hands now. Thank you very much to you and the other libogc developers for fixing the problems within the SDK. I really do appreciate it.

 

[tueidj]

That's a tad uncalled for. When a program works perfectly when compiled under an older revision of libogc but crashes upon doing something as rudimentary as an loading an IOS under a newer libogc revision than even a non-coder could tell you what's causing the problem. I've been busy with school so I apologize for doing little more than sending Daco some stack traces I ran.

That demonstrates exactly what I'm talking about:
- Loading a new IOS in the middle of execution is not rudimentary. It never happens in non-homebrew (only at the beginning or end of execution) and overwrites a large chunk of MEM2. If you've malloc'd any memory at all (framebuffer? IOS subsystem heaps?) there's a chance it will get trashed.
- Unless you've debugged a problem, you shouldn't be placing the blame on anything. Problems like stack overflows or overwriting read-only memory can go undiscovered for months and then suddenly appear out of nowhere when you recompile.
- Several times I've heard people blame libogc for being buggy but examination of their code reveals mistakes like polling pads in the vsync callback or returning a pointer to stack memory from a function.

Good programmers find bugs and submit patches, bad programmers point fingers and lay blame. Experience has left me with little patience for the latter.