Difference between revisions of "Talk:Stppwii"

From WiiBrew
Jump to: navigation, search
(Cursor control)
(Cursor control)
Line 19: Line 19:
 
What a great addition to Wii homebrew! That said, could I make a couple quick suggestions? I spent about 5 minutes trying to figure out how to start a game because I was holding the Wiimote sideways like an NES controller (the cursor moves, but pressing A or 2 does nothing). Could you update the button-press handler(s) to register a button press wherever the cursor is displayed, rather than wherever the Wiimote is pointing? Thanks again for porting this to the Wii! -- [[User:goodsoup|goodsoup]] <span style="font-size: smaller;" class="autosigned">—Preceding undated comment added 20:29, 18 March 2010 (UTC).</span><!--Template:Undated-->
 
What a great addition to Wii homebrew! That said, could I make a couple quick suggestions? I spent about 5 minutes trying to figure out how to start a game because I was holding the Wiimote sideways like an NES controller (the cursor moves, but pressing A or 2 does nothing). Could you update the button-press handler(s) to register a button press wherever the cursor is displayed, rather than wherever the Wiimote is pointing? Thanks again for porting this to the Wii! -- [[User:goodsoup|goodsoup]] <span style="font-size: smaller;" class="autosigned">—Preceding undated comment added 20:29, 18 March 2010 (UTC).</span><!--Template:Undated-->
 
: I just thought I would add that if you're pointing the Wiimote at the screen and obstruct the line-of-sight between the Wiimote and Sensor Bar, then pressing A, B, 1, or 2 on the Wiimote does nothing (as one might expect) but the cursor is still displayed on the screen where it was last pointing before line-of-sight was obstructed. I looked at the source code, and I wonder if this is due to the way the cursor is kept in the bounds of the screen or game in the constrain_mouse function in sdl.c (since the cursor/"mouse"'s position is reset when out of bounds). I'd love to help with this, but I've never programmed for the Wii or used SDL before, so I'm still trying to get on my feet. [[User:Goodsoup|Goodsoup]] 21:50, 21 March 2010 (UTC)
 
: I just thought I would add that if you're pointing the Wiimote at the screen and obstruct the line-of-sight between the Wiimote and Sensor Bar, then pressing A, B, 1, or 2 on the Wiimote does nothing (as one might expect) but the cursor is still displayed on the screen where it was last pointing before line-of-sight was obstructed. I looked at the source code, and I wonder if this is due to the way the cursor is kept in the bounds of the screen or game in the constrain_mouse function in sdl.c (since the cursor/"mouse"'s position is reset when out of bounds). I'd love to help with this, but I've never programmed for the Wii or used SDL before, so I'm still trying to get on my feet. [[User:Goodsoup|Goodsoup]] 21:50, 21 March 2010 (UTC)
 +
:: Jeez, I should come here more often. Point (1) - the menu event code is somewhat messy. I think even if the mouse is hidden you can still 'move' it and have the menu react. This code was originally developed for a touch-screen device so it's not surprising that the mouse behaves as it does. I'll see if it's feasible to eliminate the mouse part of it. As for point (2), this seems to be more of a limitation of SDL-Wii, as I've heard this topic in other discussions before. I don't think SDL-Wii has any way of being made aware that the pointer no longer has line-of-sight, so it simply keeps the pointer at its last known location. [[User:Madmanguruman|Madmanguruman]] 23:59, 11 October 2010 (CEST)

Revision as of 23:59, 11 October 2010

Wikimedia software by default disables all file uploads and downloads, and the method in their instructions for enabling it only enables a limited subset of file types. 7-zip probably wasn't included in the list of default file types when they enabled it for wiibrew.org Applicant 255 22:48, 12 December 2009 (UTC)

It should be enabled:
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'tar', 'gz', 'rar', 'zip', 'mp3', 'ogg', 'flac','swf', 'doc',
                           'odt', 'odc', 'odp', 'odg', 'pdf', 'bz2', 'elf', 'dol', 'swf', 'svg', '7z' );
-- Bushing 04:58, 14 December 2009 (UTC)\

Every time I tried to upload a .7z archive, the website would complain about the file being corrupt. I was using a very old version, will try to upgrade and see if future builds can be uploaded. Madmanguruman 03:39, 17 December 2009 (UTC)

7-zip upload still doesn't work for me. :( Madmanguruman 04:10, 25 February 2010 (UTC)

*Portable*

Hehehe... *Portable* Puzzle. I mean, I'm pretty sure you did an excellent job at porting it. No doubt about it... it's just the *portable* thing that gets me... :) Izhido 18:48, 24 February 2010 (UTC)

Well, portable from a cross-compatibility perspective ... PC, Mac, GNOME, PalmOS, GP2X ... but yeah, the Wii ain't no DSi :) Madmanguruman 04:10, 25 February 2010 (UTC)

Cursor control

What a great addition to Wii homebrew! That said, could I make a couple quick suggestions? I spent about 5 minutes trying to figure out how to start a game because I was holding the Wiimote sideways like an NES controller (the cursor moves, but pressing A or 2 does nothing). Could you update the button-press handler(s) to register a button press wherever the cursor is displayed, rather than wherever the Wiimote is pointing? Thanks again for porting this to the Wii! -- goodsoup —Preceding undated comment added 20:29, 18 March 2010 (UTC).

I just thought I would add that if you're pointing the Wiimote at the screen and obstruct the line-of-sight between the Wiimote and Sensor Bar, then pressing A, B, 1, or 2 on the Wiimote does nothing (as one might expect) but the cursor is still displayed on the screen where it was last pointing before line-of-sight was obstructed. I looked at the source code, and I wonder if this is due to the way the cursor is kept in the bounds of the screen or game in the constrain_mouse function in sdl.c (since the cursor/"mouse"'s position is reset when out of bounds). I'd love to help with this, but I've never programmed for the Wii or used SDL before, so I'm still trying to get on my feet. Goodsoup 21:50, 21 March 2010 (UTC)
Jeez, I should come here more often. Point (1) - the menu event code is somewhat messy. I think even if the mouse is hidden you can still 'move' it and have the menu react. This code was originally developed for a touch-screen device so it's not surprising that the mouse behaves as it does. I'll see if it's feasible to eliminate the mouse part of it. As for point (2), this seems to be more of a limitation of SDL-Wii, as I've heard this topic in other discussions before. I don't think SDL-Wii has any way of being made aware that the pointer no longer has line-of-sight, so it simply keeps the pointer at its last known location. Madmanguruman 23:59, 11 October 2010 (CEST)