DOP-Mii v16 BETA by Arikado

Discussion in 'Wii - Emulation and Homebrew' started by Shano56, Jul 7, 2011.

  1. Shano56
    OP

    Shano56 noobie

    Member
    877
    99
    Apr 29, 2010
    United States
    Download: http://dop-mii.googlecode.com/files/boot.dol
    Source: http://arikadosblog.blogspot.com/2011/07/d...i-v16-beta.html
     
  2. tueidj

    tueidj I R Expert

    Member
    2,569
    820
    Jan 8, 2009
    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.
     
  3. OArikadoO

    OArikadoO GBAtemp Regular

    Member
    214
    3
    Dec 30, 2009
    United States
    USA
    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.
     
  4. tueidj

    tueidj I R Expert

    Member
    2,569
    820
    Jan 8, 2009
    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.