[ scummvm-Bugs-1971285 ] Nintendo Wii port

SourceForge.net noreply at sourceforge.net
Sat May 24 15:27:44 CEST 2008


Bugs item #1971285, was opened at 2008-05-24 15:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418820&aid=1971285&group_id=37116

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andre Heider (dhewg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nintendo Wii port

Initial Comment:
attached you will find a diff for a wii port against svn trunk

this is the very same code i used to build the binary posted today on http://hbc.hackmii.com/download/

current build requirements:
- devkitppc cvs
- libogc cvs
- libfat cvs

compared to the first binaries i made public i did not have to use any patches, all requirements have been commited to the official devkitppc cvs. svpe fixed libfat to be thread safe on the last minute (thanks buddy!) and eg. monkey island 3 is playable now.

additional notes:
- all crashes (known to me) on prior binaries i made available have been fixed in devkitpro/libogc/libfat
- wiimote code has been added, i consider the relevant libraries stable by now
- libogc currently lacks IR pointer smoothing. i added a small function (coded by marcan) to do so, this should be replaced once the functionality is in libogc
- sd reading is slow, because libfat currently requests each cluster (512 bytes) with a single sd command. this results in sound stutter and dropped frames on some sequences in various games
- libfat has been ported to the gamecube as well (using a sd gecko adapter).  wiimote support is the only wii specific feature used, thus a gamecube port is easily possible. i already added defines to wii specific code parts, but did not try to compile a gamecube version (lack of time)
- the current approach to draw a frame is not optimal (buffers are copied)

i'm sorry it took so long to post this diff. i had the honour of working with very talented people on "the homebrew channel" project for the wii, which alone took much of my free time. we found and reported/fixed problems within devkitppc and libogc, and scummvm gained features as well as stability from those fixes. i hope this was worth the wait.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418820&aid=1971285&group_id=37116




More information about the Scummvm-tracker mailing list